WEBVTT 00:00:00.000 --> 00:00:02.660 AI 에이전트는 변경관리 회의보다 빠르게 출시되지만, 00:00:03.040 --> 00:00:04.660 거버넌스는 그저 분위기만 내는 수준이죠. 00:00:04.800 --> 00:00:08.580 테스트 목적으로 테넌트 전체 접근 권한을 가진 코파일럿이 출시될 때의 그 느낌, 아시나요? 00:00:08.800 --> 00:00:11.580 네, 바로 여러분의 규정 준수 담당자의 심장 박동 소리입니다. 00:00:11.780 --> 00:00:15.220 오늘은 LANGCH AIN4J와 코파일럿 스튜디오의 엉망인 상태를 실제 사례, 00:00:15.560 --> 00:00:18.520 프롬프트 인젝션, 과도한 권한의 커넥터, 감사공백을 통해 파헤쳐보겠습니다. 00:00:18.840 --> 00:00:22.480 무엇이, 왜 고장나는지, 그리고 실제로 효과가 있는 해결책을 보여드리겠습니다. 00:00:22.480 --> 00:00:26.900 끝까지 함께하시면 대부분의 사고를 예방할 수 있는 단 하나의 거버넌스 단계를 알려드립니다. 00:00:27.100 --> 00:00:31.980 에이전트 RBAC 모델, 데이터 유출방지 정책, 레드팀 체크리스트를 얻어가실 수 있을 겁니다. 00:00:32.180 --> 00:00:34.360 첫 번째 사례, 프롬프트 인젝션입니다. 00:00:34.620 --> 00:00:36.900 감독 없는 인턴이 정책을 작성하는 격이죠. 00:00:37.080 --> 00:00:40.660 프롬프트 인젝션은 겉우론 도움이 되어 보이고 문장도 완벽하게 구사하지만, 00:00:41.120 --> 00:00:44.500 뒤로는 급여 데이터를 개인 보관함으로 전송하는 감독 없는 인턴과 같습니다. 00:00:44.840 --> 00:00:47.180 여러분은 시스템 프롬프트가 곧 법이라고 생각하시죠? 00:00:47.380 --> 00:00:49.480 하지만 모델은 그걸 단지 제안으로 받아들입니다. 00:00:49.480 --> 00:00:55.160 그리고 내부 콘텐츠를 기반으로 학습시키는 순간, 자극적인 문서나 사용자 메시지 하나가 대화 도중 규칙을 재작성할 수 있습니다. 00:00:55.360 --> 00:00:56.620 이것이 중요한 이유입니다. 00:00:56.800 --> 00:01:00.820 인젝션이 성공하면 여러분의 에이전트는 데이터 유출을 일삼는 시인이 되어버립니다. 00:01:01.040 --> 00:01:06.240 환각을 일으키고 도구를 마음대로 사용하며 정책 문구를 마치 와이파이 이용 약관처럼 무시해버리죠. 00:01:06.400 --> 00:01:10.400 규제가 엄격한 업계에서 이건 단순한 버그가 아니라 회사 이름이 찍힌 보고 대상 사고입니다. 00:01:10.600 --> 00:01:13.560 LANGCHAIN4J에서 무엇이 고장나는지부터 살펴보죠. 00:01:13.560 --> 00:01:19.080 대부분이 간과하는 사실은 엄격한 출력 스키마 없는 도구 호출은 사실상 범죄 저지르고 분위기만 맞추는 홀이라는 겁니다. 00:01:19.240 --> 00:01:31.120 도구가 자유 텍스트, SQL, 쿼리필드 같은 확인되지 않은 인자를 허용하고 유형, 범위, 열거형을 검증하지 않는다면 모델은 공격자가 몰래 보낸 데이터도 기꺼이 통과시킬 것입니다. 00:01:31.340 --> 00:01:34.120 부실한 출력 검증은 범죄의 공범위나 다름없습니다. 00:01:34.120 --> 00:01:41.660 JSON을 기대하면서 대충 JSON 비슷한 형식을 허용하면 공격자는 주석이나 문자열에 명령어를 끼워넣고 다운스트림 파손은 이를 실제 명령으로 처리하게 됩니다. 00:01:41.840 --> 00:01:47.060 검색 도구가 이미 마크다운을 포함한 토픽 파라미터를 받는 로그를 봤을 때의 점이 확실히 이해되었습니다. 00:01:47.380 --> 00:01:50.880 다음 호출은 해당 마크다운을 마치 설정값인 것처럼 전달했습니다. 00:01:51.240 --> 00:01:53.520 이건 오케스트레이션이 아니라 자폭입니다. 00:01:54.000 --> 00:01:56.240 이제 대부분이 실수하는 지점이 여기입니다. 00:01:56.460 --> 00:02:00.740 코드 내 가드레일 대신 모델에 제발 안전하게 해주세요 설정에 의존하는 것이죠. 00:02:00.740 --> 00:02:15.700 LANGCHAIN4J에서는 도구 이름과 인자에 대한 허용 목록, 경계에서 강제되는 JSON 스키마 출력, 보안을 무력화할 패턴 기반 출력 필터, 그리고 오염된 입력을 골든 리트리버가 페니스 공을 물고 오듯 5번씩 제시도 하지 않는 예외 처리가 필요합니다. 00:02:15.860 --> 00:02:20.320 이 방식이 효과적인 이유는 모델을 신뢰하는 것에서 모든 바이트를 검증하는 것으로 전환하기 때문입니다. 00:02:20.480 --> 00:02:22.680 코파일럿 스튜디오에서는 무엇이 고장날까요? 00:02:22.860 --> 00:02:25.620 광범위한 셰어포인트 수집을 통한 순진한 그라운딩입니다. 00:02:25.620 --> 00:02:32.300 완전성을 위해 전체 사이트 모음을 연결하면 이전 지시사항 무시가 적힌 온보딩 문서 하나가 에이전트의 새로운 종교가 됩니다. 00:02:32.480 --> 00:02:35.760 비즈니스 사용자가 편집 가능한 시스템 프롬프트는 그 다음 단계의 문제입니다. 00:02:35.920 --> 00:02:41.740 비즈니스 사용자를 존중하지만 그들에게 프롬프트 관리 권한을 주는 것은 마케팅팀이 브랜드 보이스를 안다는 이유로 방화벽 규칙을 설정하게 하는 것과 같습니다. 00:02:42.000 --> 00:02:46.140 그리고 실제로 저는 마찰을 줄이기 위해 조정, 모더레이션, 기능을 비활성화 한 테넌트 구성을 본 적이 있습니다. 00:02:46.320 --> 00:02:48.240 보지 않아 덜하면 좋았을 텐데 말이죠. 00:02:48.240 --> 00:02:54.940 익숙한 증거로는 존재해서는 안 될 모두 내보내기 플래그 같은 무제한 매개 변수로 도구가 호출되는 테넌트 로그가 있습니다. 00:02:55.240 --> 00:03:00.920 검색된 문서에서 주입된 문자열을 어시스턴트가 반복하거나 조정도글이 비활성화된 대화 기록도 마찬가지입니다. 00:03:01.100 --> 00:03:04.740 이건 가정이 아니라 여러분이 참석하고 싶지 않을 모든 사고 후 검토 회의의 내용입니다. 00:03:04.920 --> 00:03:07.200 그렇다면 지금 바로 구현할 수 있는 해결책은 무엇일까요? 00:03:07.360 --> 00:03:10.780 랭체인 4J의 경우 도구 레지스트리에서 허용 목록, 얼라우 리스트를 강제하세요. 00:03:10.960 --> 00:03:13.360 스키마가 등록되지 않은 도구는 존재하지 않는 것으로 간주합니다. 00:03:13.360 --> 00:03:16.580 JSO인 스키마 출력을 요구하고 유효성을 검사하지 못하는 모든 것은 거부하세요. 00:03:16.760 --> 00:03:18.220 스키마가 없으면 응답도 없습니다. 00:03:18.480 --> 00:03:19.280 반호하게 하세요. 00:03:19.480 --> 00:03:23.220 API키, 비밀 정보, 주민등록번호와 같은 명백한 유출을 막기 위해 패턴 필터를 추가하세요. 00:03:23.380 --> 00:03:26.060 블룸필터, 블룸필러스는 빠르고 비용이 저렴하니 꼭 사용하세요. 00:03:26.240 --> 00:03:30.700 도구를 정책검사로 감싸고 실행 전에 인수 유형, 범위, 예상 형식을 검증하세요. 00:03:30.920 --> 00:03:36.440 사전, 사후 처리기에 콘텐츠 조정을 추가하여 모델이 유해하거나 민감한 콘텐츠를 처리하거나 내보내지 못하게 하세요. 00:03:36.440 --> 00:03:40.740 명시적인 예외와 함께 차단, 페일 클로즈드 하고 오염된 프롬프트를 자동으로 제시도하지 마세요. 00:03:40.860 --> 00:03:43.160 코파일러 스튜디오의 경우 시스템 프롬프트를 잠그세요. 00:03:43.300 --> 00:03:44.700 관리자만 변경할 수 있어야 합니다. 00:03:44.880 --> 00:03:46.140 코드처럼 버전을 관리하세요. 00:03:46.340 --> 00:03:47.760 환경별로 커넥터 범위를 지정하세요. 00:03:47.960 --> 00:03:49.860 개발, 테스트, 운영 환경의 경계를 구분하세요. 00:03:50.040 --> 00:03:51.820 데이터 소스에 최소 권한 원칙을 적용하세요. 00:03:52.000 --> 00:03:54.160 테넌트 수준에서 콘텐츠 조정 정책을 켜세요. 00:03:54.400 --> 00:03:55.760 이것은 기본 중의 기본입니다. 00:03:55.980 --> 00:04:00.420 편의를 위해 전체 데이터를 연동하지 말고 민감도 레이블이 지정된 콘텐츠에만 기반하세요. 00:04:00.420 --> 00:04:05.760 즉각적인 효과를 얻을 수 있는 빠른 방법으로 에이전트 경계에 출력 스키마와 블룸 필터 조정 단계를 추가하세요. 00:04:05.940 --> 00:04:09.040 비즈니스 로직을 건드리지 않고도 대부분의 어이없는 유출을 막을 수 있습니다. 00:04:09.260 --> 00:04:14.360 그 다음, 구조화된 요약처럼 예상되는 형식에 대한 작은 허용 목록을 추가하고 나머지는 모두 차단하세요. 00:04:14.580 --> 00:04:16.900 이것이 정확히 어떻게 작동하는지 보여드리겠습니다. 00:04:17.240 --> 00:04:21.620 예를 들어, 제목, 설명, 우선 순위를 받는 티켓 생성 도구가 있다고 가정해봅시다. 00:04:21.840 --> 00:04:28.060 스키마 강제가 없으면 공격자가 설명란에 3중 100틱 블록을 사용하여 모든 피원사고 종료 같은 명령을 주입합니다. 00:04:28.060 --> 00:04:29.980 모델은 이를 그대로 통과시킵니다. 00:04:29.980 --> 00:04:33.400 여러분의 ITSM API는 아무 의심 없이 업데이트 스크립트를 실행합니다. 00:04:33.540 --> 00:04:38.040 스키마와 유효성 검사가 있다면 설명란에는 명령 토큰이 포함될 수 없으며 길이 제한도 지켜집니다. 00:04:38.200 --> 00:04:42.880 요청은 차단되고 상관 아이디가 기록되며 CME 조정 위반을 탐지합니다. 00:04:43.100 --> 00:04:45.120 보세요. 결과가 아주 깔끔합니다. 00:04:45.340 --> 00:04:48.320 사고는 예방되었고 추적 기록은 남아두며 감사는 통과했습니다. 00:04:48.580 --> 00:04:49.980 피해야 할 흔한 실수들입니다. 00:04:50.200 --> 00:04:52.480 모델이 도구 이름을 동적으로 선택하게 내버려두는 것입니다. 00:04:52.660 --> 00:04:54.160 도구는 제한이 아니라 계약입니다. 00:04:54.400 --> 00:04:56.720 검증기 없이 자유 형식의 JSON 을 수락하는 것. 00:04:56.720 --> 00:04:58.760 JSON 같다는 말은 칭찬이 아닙니다. 00:04:58.760 --> 00:05:00.780 운영 환경에서 수정 가능한 프롬프트. 00:05:00.900 --> 00:05:03.380 검토 없이 변경 가능하다면 결국 변경될 것입니다. 00:05:03.580 --> 00:05:05.380 정책을 대화 기억에 의존하는 것. 00:05:05.480 --> 00:05:07.800 정책은 감이 아니라 코드와 설정에 있어야 합니다. 00:05:08.040 --> 00:05:10.220 이것만 제대로 하면 나머지는 자연스럽게 해결됩니다. 00:05:10.420 --> 00:05:12.360 인턴이 주제넘게 말하는 것을 막는 단계죠. 00:05:12.520 --> 00:05:15.280 다음은 마스터키로 모든 방에 들어가지 못하게 할 차례입니다. 00:05:15.480 --> 00:05:16.100 두 번째 사례. 00:05:16.460 --> 00:05:17.580 지나치게 관대 한 커넥터. 00:05:17.880 --> 00:05:19.260 목걸이에 걸린 성의 열쇠입니다. 00:05:19.480 --> 00:05:20.960 인턴이 말하는 것을 막았습니다. 00:05:21.360 --> 00:05:22.640 이제 출입증을 회수하세요. 00:05:22.900 --> 00:05:25.220 지나치게 관대 한 커넥터는 금고, 어린이집, 00:05:25.220 --> 00:05:29.680 그리고 어쩌다 보니 CEO 위펠로통까지 건물 내 모든 문을 여는 관리인 열쇠 꾸러미와 같습니다. 00:05:30.000 --> 00:05:31.580 이게 중요한 이유는 간단합니다. 00:05:31.780 --> 00:05:35.620 범위가 과도한 커넥터 하나는 단 한 번이 요청으로 전사적 데이터 유출을 일으킵니다. 00:05:35.800 --> 00:05:36.600 이론이 아닙니다. 00:05:36.800 --> 00:05:37.900 단 한 번이 호출로요. 00:05:38.100 --> 00:05:40.600 당신이 변경 티켓 제목으로 실랑이를 벌이는 동안 말이죠. 00:05:40.780 --> 00:05:43.280 랭체인 4J에서 무엇이 고장나는지부터 살펴보죠. 00:05:43.440 --> 00:05:46.560 개발자들은 편의를 위해 에이전트 간의 API 키를 공유합니다. 00:05:46.780 --> 00:05:49.920 그러다 누군가 실수로 환경 변수를 공개된 비공개 저장소에 커밋하고, 00:05:50.360 --> 00:05:52.580 당신은 새벽 도시에 해외에서 사고 대응을 하게 됩니다. 00:05:52.580 --> 00:05:54.280 다음은 워스 범위입니다. 00:05:54.420 --> 00:05:57.180 테스트 시간을 줄이려고 읽기, 쓰기 권한을 모두 부여했는데, 00:05:57.700 --> 00:06:00.700 6개월 뒤 그 테스트 토큰이 운영 환경의 핵심 자산이 되어 있죠. 00:06:00.880 --> 00:06:02.260 도구 레지스트리는 어떤가요? 00:06:02.440 --> 00:06:03.500 깔끔한 레지스트리는 좋지만, 00:06:03.840 --> 00:06:07.000 데모를 당장 성공시켜야 한다고 개발용 에이전트의 운영 자격 증명을 연결하면, 00:06:07.400 --> 00:06:08.880 마치 룬바에 전기톱을 매단 것과 같습니다. 00:06:09.120 --> 00:06:12.540 대부분이 놓치는 점은 도구가 당신이 부여한 아이디를 그대로 상속받는다는 것입니다. 00:06:12.760 --> 00:06:14.920 자격 증명을 공유하면 영향 범위도 공유됩니다. 00:06:15.140 --> 00:06:17.340 저장만 가능하게 하는 마법의 플래그 따위는 없습니다. 00:06:17.340 --> 00:06:22.800 토큰으로 레코드를 삭제할 수 있다면, 당신의 에이전트는 실수로, 열정적으로, 그리고 완벽하게 확신을 가지고 레코드를 삭제할 것입니다. 00:06:22.940 --> 00:06:24.780 이제 코파일럿 스튜디오로 넘어가 볼까요? 00:06:24.920 --> 00:06:27.840 패넌트 전체에 적용되는 M365 커넥터는 고전적인 함정입니다. 00:06:28.020 --> 00:06:31.760 한 번 클릭하면 이제 모든 팀의 모든 코파일럿 이봐서는 안될 데이터를 볼 수 있게 됩니다. 00:06:32.000 --> 00:06:34.760 그건 권한 부여가 아니라 실수를 불러오는 뷔페와 같습니다. 00:06:35.100 --> 00:06:38.400 그러고는 도입률을 높이려고 조직 전체 공개 범위로 팀에 배포하면, 00:06:38.400 --> 00:06:44.640 갑자기 재무팀용 파일럿 보시 마케팅팀 질문에 답하며 몰라 야할 시어포인트 사이트의 콘텐츠까지 끌어옵니다. 00:06:44.800 --> 00:06:46.620 관리되지 않는 타사세스 훅은요? 00:06:46.800 --> 00:06:48.800 그건 2009년의 USB 드라이브와 같습니다. 00:06:49.180 --> 00:06:51.460 이상하게 어디에나 있고 항상 임시용이라고 하죠. 00:06:51.660 --> 00:06:53.680 증거는 매번 같은 방식으로 나타납니다. 00:06:53.920 --> 00:06:57.600 교체된 적 없는 낡은 비밀키, 만료 기한도 없고 소유자도 없습니다. 00:06:57.940 --> 00:07:00.820 단순화를 위해 글로벌 그룹에 맵핑된 커넥터들, 00:07:01.000 --> 00:07:03.840 고백하는 내용처럼 읽히는 범위를 가진 앱 등록, 00:07:03.840 --> 00:07:07.880 네, 개발 환경에서 몇 달째 살고 있는 그 임시 운영키도 포함해서요. 00:07:07.880 --> 00:07:10.520 당신의 보안 결과와 테넌트 설정은 거짓말을 하지 않습니다. 00:07:10.700 --> 00:07:11.800 그저 한숨만 쉴 뿐이죠. 00:07:11.980 --> 00:07:13.220 그렇다면 해결책은 무엇일까요? 00:07:13.380 --> 00:07:17.580 LANGCHAIN4J의 경우, 모든 에이전트를 고유한 아이디를 가진 별도의 애플리케이션으로 취급하십시오. 00:07:17.700 --> 00:07:19.300 에이전트별 서비스 주체를 생성하십시오. 00:07:19.420 --> 00:07:20.560 토큰을 공유하지 마십시오. 00:07:20.680 --> 00:07:23.600 두 에이전트가 동일한 API를 필요로 하더라도 각각 다른 자격증명을 부여하십시오. 00:07:23.700 --> 00:07:25.340 범위가 지정된 OOS를 사용하십시오. 00:07:25.480 --> 00:07:27.900 도구가 작업을 수행할 수 있는 최소한의 권한 세트만 부여하십시오. 00:07:27.900 --> 00:07:29.560 작성자가 아닌 읽기 전용으로 설정하십시오. 00:07:29.640 --> 00:07:31.400 전체가 아닌 하나의 컬렉션에만 쓰기를 허용하십시오. 00:07:31.480 --> 00:07:33.240 비밀 정보는 적절한 비밀 관리자에 저장하십시오. 00:07:33.360 --> 00:07:34.720 일정에 따라 정기적으로 교체하십시오. 00:07:34.840 --> 00:07:36.120 사고 발생 시 즉시 교체하십시오. 00:07:36.240 --> 00:07:38.020 토큰이 노출될 증후만 보여도 즉시 교체하십시오. 00:07:38.140 --> 00:07:39.620 2단계 RBACE를 추가하십시오. 00:07:39.760 --> 00:07:42.260 도구 래퍼가 API를 호출하기 전에 호출자의 역할을 확인하도록 하십시오. 00:07:42.400 --> 00:07:43.660 역할이 없으면 호출도 없습니다. 00:07:43.960 --> 00:07:46.600 환경을 분리하여 개발 키는 개발 시스템과만 통신하게 하십시오. 00:07:46.600 --> 00:07:50.500 도구가 개발 환경에서 운영 엔드 포인트를 감지하면 차단하고 로그의 기록을 남기십시오. 00:07:50.580 --> 00:07:54.240 코파일럿 스튜디오의 경우 환경과 범위를 사용하여 엄격한 경계를 설정하십시오. 00:07:54.360 --> 00:07:57.060 개발, 테스트, 운영 등 환경을 분리하여 사용하십시오. 00:07:57.180 --> 00:07:59.760 커넥터, 권한, 소유자를 각각 다르게 설정하십시오. 00:07:59.880 --> 00:08:01.900 워크플로우를 통해 커넥터 범위를 검토하십시오. 00:08:02.040 --> 00:08:04.340 변경사항에는 승인, 만료 날짜, 소유자가 필요합니다. 00:08:04.500 --> 00:08:05.820 소유자가 없으면 커넥터도 없습니다. 00:08:06.120 --> 00:08:07.740 채널별로 DLP 정책을 적용하십시오. 00:08:07.740 --> 00:08:10.160 재무채널에는 전사적 규칙보다 더 엄격한 규칙을 적용하십시오. 00:08:10.240 --> 00:08:11.300 바로 그것이 핵심입니다. 00:08:11.480 --> 00:08:13.940 파일럿 단계에서는 조직 전체의 팀즈 배포를 중단하십시오. 00:08:14.060 --> 00:08:15.820 가시성을 보안 그룹으로 제한하십시오. 00:08:15.960 --> 00:08:17.600 검토 후에만 범위를 확장하십시오. 00:08:17.720 --> 00:08:19.980 타사 세스 커넥터의 목록을 관리하고 제어하십시오. 00:08:20.140 --> 00:08:22.080 관리되지 않는 항목은 기본적으로 차단하십시오. 00:08:22.200 --> 00:08:24.320 소유자는 액세스 권한을 정당화하고 갱신해야 합니다. 00:08:24.500 --> 00:08:26.720 오늘 오후에 바로 적용할 수 있는 간단한 해결책이 있습니다. 00:08:26.720 --> 00:08:30.940 테넌트의 전체 범위를 폐지하고 각 커넥터를 만료 정책이 있는 보안 그룹에 맵핑하십시오. 00:08:31.080 --> 00:08:33.400 그룹이 만료되면 액세스 권한은 자연스럽게 종료됩니다. 00:08:33.580 --> 00:08:34.900 번거로움도 놀랄 일도 없습니다. 00:08:35.180 --> 00:08:36.940 이 과정이 정확히 어떻게 진행되는지 보여드리겠습니다. 00:08:37.220 --> 00:08:39.800 스토리지 버킷에 기록하는 내보내기 보고 도구가 있다고 가정해봅시다. 00:08:39.960 --> 00:08:42.260 공유자격 증명을 사용하면 모든 버킷을 볼 수 있습니다. 00:08:42.480 --> 00:08:45.100 그래서 백업을 아카이브에 저장해 라는 프롬프트를 입력하면 00:08:45.100 --> 00:08:47.560 민감한 데이터가 공개된 경로에 조용히 저장됩니다. 00:08:47.560 --> 00:08:50.540 에이전트 별 주체와 범위가 지정된 역할을 사용하면 00:08:50.540 --> 00:08:54.200 해당 도구는 하나의 버킷과 하나의 접두사에만 쓸 수 있습니다. 00:08:54.440 --> 00:08:58.100 모델이 다른 경로를 생성하려고 시도하면 API가 이를 거부합니다. 00:08:58.320 --> 00:09:01.160 상관관계 아이디를 기록하고 CME 경고를 발생시킵니다. 00:09:01.340 --> 00:09:03.920 결과적으로 위도치 않은 데이터 유출 사고를 방지하게 됩니다. 00:09:04.120 --> 00:09:05.500 피해야 할 흔한 실수들입니다. 00:09:05.720 --> 00:09:08.180 일단 당분간만 액세스를 위해 글로벌 그룹을 사용하는 것. 00:09:08.260 --> 00:09:09.880 그 당분간은 절대 끝나지 않습니다. 00:09:10.080 --> 00:09:12.520 문서가 복잡하다는 이유로 광범위하거나 모든 범위를 부여하는 것. 00:09:12.620 --> 00:09:13.940 복잡함은 권한이 될 수 없습니다. 00:09:13.940 --> 00:09:15.980 환경 간의 자격 증명을 복사하는 것. 00:09:16.040 --> 00:09:18.120 붙여넣을 수 있다면 분명 잘못 붙여넣게 될 것입니다. 00:09:18.260 --> 00:09:19.940 팀제 가시성을 무해하다고 여기는 것. 00:09:20.020 --> 00:09:21.360 가시성은 곧 액세스 권한입니다. 00:09:21.540 --> 00:09:22.840 액세스 권한은 곧 위험입니다. 00:09:23.040 --> 00:09:24.060 액세스 범위를 제대로 설정하면 00:09:24.060 --> 00:09:25.940 감사관들이 더 이상 문제점을 파고들지 못할 것입니다. 00:09:26.100 --> 00:09:28.240 그리고 그들이 찾아올 때 당신에게는 증거가 필요할 것입니다. 00:09:28.420 --> 00:09:30.320 이제 모두가 읽기 쉬운 마지막 부분으로 넘어가겠습니다. 00:09:30.600 --> 00:09:32.640 로그에 남지 않았다면 일어나지 않은 일입니다. 00:09:32.820 --> 00:09:33.600 세 번째 사례. 00:09:33.780 --> 00:09:34.560 감사 공백. 00:09:34.680 --> 00:09:36.660 로그에 남지 않았다면 일어나지 않은 일입니다. 00:09:36.840 --> 00:09:38.140 액세스 범위를 정하셨나요? 00:09:38.340 --> 00:09:38.800 좋습니다. 00:09:38.800 --> 00:09:39.900 이제 증명해보세요. 00:09:40.140 --> 00:09:42.360 감사인이 오후 3시 14분에 에이전트가 무엇을 했나요? 00:09:42.460 --> 00:09:43.540 라고 물었을 때 말이죠. 00:09:43.740 --> 00:09:44.920 당신의 대답이 글쎄요. 00:09:45.120 --> 00:09:45.680 뭔가 했겠죠. 00:09:45.820 --> 00:09:46.180 라면요. 00:09:46.320 --> 00:09:47.520 그건 대응 자세가 아닙니다. 00:09:47.700 --> 00:09:49.180 그건 사과하러 다니겠다는 뜻이죠. 00:09:49.380 --> 00:09:50.440 이게 중요한 이유입니다. 00:09:50.620 --> 00:09:52.120 계보가 없으면 이상한 답변을 설명하거나 00:09:52.120 --> 00:09:53.380 잘못된 동작을 되돌리거나 00:09:53.380 --> 00:09:55.060 사고가 수습되었는지 조차 알 수 없습니다. 00:09:55.280 --> 00:09:57.140 규제기관은 그런 불확실성을 아주 좋아하죠. 00:09:57.300 --> 00:09:58.800 고객들은 별로 좋아하지 않겠지만요. 00:09:58.920 --> 00:10:00.340 그리고 경영진은 당신이 전혀 모릅니다. 00:10:00.460 --> 00:10:01.480 라고 말할 때 정말 좋아할 겁니다. 00:10:01.660 --> 00:10:03.880 대부분의 사람들이 랭체인 4J에서 놓치는 부분이 여기 있습니다. 00:10:03.880 --> 00:10:06.660 당신의 체인은 로그에 기록된 것보다 훨씬 많은 일을 하고 있습니다. 00:10:06.880 --> 00:10:09.260 실행 그래프가 없으면 단계를 재구성할 수 없습니다. 00:10:09.540 --> 00:10:12.540 추적 아이디가 없으면 이벤트들은 그저 무작위 불꽃놀이처럼 보이죠. 00:10:12.740 --> 00:10:15.240 부분적인 로그는 가장 중요한 도구 호출 하나를 숨겨버립니다. 00:10:15.460 --> 00:10:16.680 조용히 발생하는 도구 실패. 00:10:16.960 --> 00:10:18.180 제가 가장 좋아하는 부분이죠. 00:10:18.380 --> 00:10:20.700 모든 것이 정상처럼 보이지만 도구는 실행되지 않았고 00:10:20.700 --> 00:10:23.180 모델은 그저 예의상 환각 답변을 내놓은 상태입니다. 00:10:23.360 --> 00:10:25.560 검색 단계에서 타임아웃이 발생해 너를 반환했는데 00:10:25.560 --> 00:10:28.180 다음 단계가 아무 문제 없다는 듯 티켓팅 API에 00:10:28.180 --> 00:10:31.400 기록 없음으로 종료 처리를 해버린 사고를 쫓단 날이 사실을 깨달았습니다. 00:10:31.680 --> 00:10:34.980 예외도 추적도 없이 그저 분위기 파악과 티켓 종료뿐이었죠. 00:10:35.120 --> 00:10:37.500 로그에서 모델 출력값과 도구 출력값을 구분할 수 없다면 00:10:37.500 --> 00:10:38.680 이미 문제에 빠진 것입니다. 00:10:38.880 --> 00:10:40.780 랭체인 4J 로깅을 법정 제출이 가능한 수준으로 00:10:40.780 --> 00:10:42.220 수정하는 방법을 정확히 알려드리겠습니다. 00:10:42.520 --> 00:10:44.680 우선 모든 곳에 구조화된 로깅을 활성화하세요. 00:10:44.880 --> 00:10:47.020 문자열 뭉치가 아닌 JSON 형식으로요. 00:10:47.020 --> 00:10:49.740 모든 요청과 응답에는 타임스탬프, 모델명, 토큰수, 00:10:49.980 --> 00:10:52.720 그리고 전체 체인을 관통하는 상관관계 아이디가 담긴 봉투가 필요합니다. 00:10:52.860 --> 00:10:54.780 그 다음 냉스미스 나 랭그라프를 사용해 00:10:54.780 --> 00:10:56.360 실행 그래프나 추적을 추가하세요. 00:10:56.540 --> 00:10:59.240 각 노드는 입력, 출력, 소요시간, 오류를 기록해야 합니다. 00:10:59.400 --> 00:11:01.240 도구에서 오류가 발생하면 확실하게 드러나게 하세요. 00:11:01.400 --> 00:11:03.000 조용한 실패나 추측은 허용되지 않습니다. 00:11:03.160 --> 00:11:04.260 이제 가장 중요한 단계입니다. 00:11:04.440 --> 00:11:05.280 중앙 집중화하세요. 00:11:05.500 --> 00:11:07.180 추적 정보와 로그를 SIM으로 전송하세요. 00:11:07.360 --> 00:11:09.420 자동 확장으로 사라져버릴 컨테이너에 남겨두지 마세요. 00:11:09.600 --> 00:11:10.860 노이즈를 줄이기 위해 샘플링을 하더라도 00:11:10.860 --> 00:11:11.980 오류는 절대 누락하지 마세요. 00:11:11.980 --> 00:11:14.460 추적 아이디로 검색하여 전체 이야기를 볼 수 있어야 합니다. 00:11:14.600 --> 00:11:15.740 새벽 2시에 원리를 찾아라. 00:11:15.740 --> 00:11:19.920 를 할 필요 없이 프롬프트, 검색 문서, 도구 호출, API 응답, 최종 답변을 확인하세요. 00:11:20.040 --> 00:11:21.620 코파일러 스튜디오로 넘어갑니다. 00:11:21.780 --> 00:11:23.620 이 플랫폼은 어느 정도의 텔레메트리를 제공하지만 00:11:23.620 --> 00:11:26.480 팀과 데이터버스, 그리고 연결된 모든 커넥터에 흩어져 있습니다. 00:11:26.720 --> 00:11:29.860 제한적인 대화 내보내기로는 전체 맥락이 아닌 단편적인 조각만 얻게 됩니다. 00:11:30.080 --> 00:11:34.380 파편화된 텔레메트리 때문에 컴플라이언스 담당자가 스크린샷을 모아 미술 공예하듯 작업하게 됩니다. 00:11:34.380 --> 00:11:37.000 통합된 감사 경로를 구축하여 이 문제를 해결하세요. 00:11:37.000 --> 00:11:42.180 명확한 보존 SLA, 보존 주체, 기간, 이유를 포함하여 대화 기록 보존 기능을 활성화하세요. 00:11:42.320 --> 00:11:46.660 대화 및 작업 로그를 패브릭이나 로그 애널리틱스와 같은 중앙 집중식 워크스페이스로 내보내세요. 00:11:46.840 --> 00:11:53.360 팀즈 위 진입점에서 데이터버스 플러그인과 다운스트림 API까지 전달되는 상관관계 아이디, 코럴레이션 아이디로 모든 이벤트를 태그하세요. 00:11:53.540 --> 00:11:55.000 채팅에서 사례 생성을 요청하면 00:11:55.000 --> 00:11:59.820 전송된 정확한 데이터가 포함된 정확한 시스템의 정확한 레코드로 즉시 이동할 수 있어야 합니다. 00:12:00.020 --> 00:12:02.180 사고 검토 시 흔히 발견되는 증거들입니다. 00:12:02.180 --> 00:12:12.300 사용자 세션에 맵핑되지 않는 로그 속의 고아, 오펜드, LLM 호출, 해당 프롬프트가 없는 도구 호출, 또는 접지, 그라운딩, 로그에 문서 아이디가 포함되어 있지 않아 찾을 수 없는 출처를 인용한 답변. 00:12:12.420 --> 00:12:13.640 이것은 미스터리가 아닙니다. 00:12:13.800 --> 00:12:15.080 기반 설비가 누락된 것입니다. 00:12:15.280 --> 00:12:17.320 이번 주에 바로 적용할 수 있는 신속한 해결책들입니다. 00:12:17.480 --> 00:12:19.780 해시를 사용한 요청 응답 엠벨로프를 의무화하세요. 00:12:19.980 --> 00:12:24.160 프롬프트, 검색된 청크, 출력의 콘텐츠 해시를 저장하여 무결성을 증명하세요. 00:12:24.360 --> 00:12:26.620 누군가 변조를 시도하면 해시가 이를 거부합니다. 00:12:26.620 --> 00:12:29.100 종단 간 상관관계 아이디를 필수로 요구하세요. 00:12:29.280 --> 00:12:32.640 엣지에서 생성하고 모든 홉을 통과시키며 이를 누락한 호출은 모두 거부하세요. 00:12:32.840 --> 00:12:34.220 아이디가 없으면 서비스도 없습니다. 00:12:34.480 --> 00:12:35.860 보존 SLA를 정의하세요. 00:12:36.060 --> 00:12:38.020 법무팀의 수인을 받고 보안팀이 시행하게 하세요. 00:12:38.200 --> 00:12:39.620 개발용은 91, 운영용은 1년. 00:12:39.840 --> 00:12:41.260 규제 대상 도메인은 더 길게 설정하세요. 00:12:41.480 --> 00:12:42.040 공표하세요. 00:12:42.280 --> 00:12:43.200 철저히 준수하세요. 00:12:43.420 --> 00:12:44.640 피해야 할 흔한 실수들입니다. 00:12:44.840 --> 00:12:47.000 원시 비밀정보, 나개인정보, PII를 로깅하는 것. 00:12:47.080 --> 00:12:48.000 소스에서 마스킹하세요. 00:12:48.220 --> 00:12:50.080 핵심 데이터가 아닌 포렌식에 필요한 필드만 남기세요. 00:12:50.240 --> 00:12:51.320 에러 샘플링은 하지 마세요. 00:12:51.500 --> 00:12:52.620 성공 로그를 샘플링하세요. 00:12:52.880 --> 00:12:53.940 모든 실패는 로깅하세요. 00:12:54.200 --> 00:12:56.300 문제가 발생하면 모든 흔적이 필요하기 때문입니다. 00:12:56.300 --> 00:12:58.840 자유 텍스트 로그는 사람은 좋아하지만 기계는 싫어합니다. 00:12:58.980 --> 00:12:59.980 필드를 사용하세요. 00:13:00.220 --> 00:13:01.260 스키마를 추가하세요. 00:13:01.480 --> 00:13:02.580 수집 시 검증하세요. 00:13:02.840 --> 00:13:04.980 이제 감사자가 무슨 일이 있었는지 물어봅니다. 00:13:05.180 --> 00:13:06.420 추적 로그 하나를 엽니다. 00:13:06.660 --> 00:13:11.360 프론프트, 검색된 문서 아이디, 도구 입력, 도구 출력, 최종 메시지를 보여줍니다. 00:13:11.560 --> 00:13:15.540 상관관계 아이디가 API 게이트웨이, 데이터베이스 기록, 팀즈 메시지와 일치합니다. 00:13:18.000 --> 00:13:22.580 가시성을 확보하면 거버넌스가 가능해지며, 이제 규칙을 공식화하고 역할을 제한해야 할 때입니다. 00:13:22.780 --> 00:13:26.760 에이전트 rbac 모델, 에이전트를 매우 멍청하지만 매우 강력한 사용자로 취급하세요. 00:13:26.760 --> 00:13:28.260 가시성을 확보하셨군요. 00:13:28.360 --> 00:13:28.840 좋습니다. 00:13:29.080 --> 00:13:30.880 이제 이들에게 신원과 통제권을 부여하세요. 00:13:31.080 --> 00:13:32.180 에이전트도 사용자입니다. 00:13:32.440 --> 00:13:34.320 매우 멍청하고 매우 강력한 사용자죠. 00:13:34.500 --> 00:13:36.380 사람에게도 첫날부터 임시관리자 권한을 주지 않을 거라면, 00:13:36.700 --> 00:13:39.500 비꼬는 말과 수도명령어도 구분 못하는 확률적 앵무새에게 그 권한을 주지 마세요. 00:13:39.660 --> 00:13:40.800 이것이 중요한 이유입니다. 00:13:41.000 --> 00:13:43.500 대부분의 조직은 사람은 보완하면서 에이전트는 무시합니다. 00:13:43.700 --> 00:13:46.400 그 결과 에이전트는 설계상 최소 권한 원칙을 우회하게 됩니다. 00:13:46.640 --> 00:13:48.520 에이전트는 도구를 넘나들고 환경을 가로지르지만, 00:13:48.840 --> 00:13:50.880 조직도에 나타나지 않기 때문에 아무도 눈치채지 못합니다. 00:13:50.880 --> 00:13:53.680 이것이 바로 헬퍼보시 섀도우 관리자로 변하는 과정입니다. 00:13:53.840 --> 00:13:56.040 제가 여러분께 배포하고자 하는 모델은 이렇습니다. 00:13:56.220 --> 00:13:59.200 에이전트별 단일 아이덴티티, 명확한 역할, 코든의 정책 확인, 00:13:59.520 --> 00:14:01.360 그리고 실제로 의미 있는 환경 경계가 필요합니다. 00:14:01.620 --> 00:14:02.860 아이덴티티부터 시작하세요. 00:14:03.060 --> 00:14:06.200 플랫폼봇 01, 이 아닌 모든 에이전트에 대해 서비스 주체를 생성하세요. 00:14:06.400 --> 00:14:08.080 실질적인 1대1 맵핑이 중요합니다. 00:14:08.260 --> 00:14:09.440 앱처럼 이름을 지정하세요. 00:14:09.660 --> 00:14:12.200 소유자, 목적, 환경, 만료기한을 태그로 지정하세요. 00:14:12.200 --> 00:14:15.260 두 에이전트가 같은 API를 호출하더라도 각기 다른 아이덴티티를 가져야 합니다. 00:14:15.400 --> 00:14:17.480 아이덴티티를 공유하면 피해 범위도 공유되기 때문입니다. 00:14:17.620 --> 00:14:19.900 그런 다음 바쁜 사람들도 적용할 수 있는 역할 분류체계를 정의하세요. 00:14:20.060 --> 00:14:23.780 저는 읽기, 리더, 실행, 러너, 쓰기, 라이터, 관리, 어드민, 위 4가지를 사용합니다. 00:14:23.940 --> 00:14:25.220 읽기 권한은 데이터를 가져올 수 있습니다. 00:14:25.400 --> 00:14:26.140 부작용이 없습니다. 00:14:26.460 --> 00:14:28.580 조회, 검색, 요약 작업을 생각하세요. 00:14:28.820 --> 00:14:31.340 실행 권한은 제한된 효과를 가진 워크플로우를 호출할 수 있습니다. 00:14:31.540 --> 00:14:34.480 티켓 생성, 승인 전송, 회의 일정 잡기 등이 이에 해당합니다. 00:14:34.480 --> 00:14:36.900 쓰기 권한은 특정 범위 내에 데이터를 기록할 수 있습니다. 00:14:37.060 --> 00:14:39.840 전체가 아닌 하나의 테이블, 하나의 버킷, 하나의 메일함에 한정합니다. 00:14:40.020 --> 00:14:41.800 관리 권한은 구성을 변경할 수 있습니다. 00:14:42.060 --> 00:14:43.940 이 역할은 여러분을 긴장하게 만들어야 합니다. 00:14:44.100 --> 00:14:46.780 꼭 필요한 경우에만 제한된 시간 동안 항상 이중세인을 거쳐 사용하세요. 00:14:46.960 --> 00:14:48.980 이제 이를 lanjhain4j에 맵핑해보겠습니다. 00:14:49.240 --> 00:14:51.100 도구, 툴, 가 여러분의 통제 지점이 됩니다. 00:14:51.340 --> 00:14:53.780 각 도구 래퍼는 실행 전 호출자의 역할을 확인합니다. 00:14:54.000 --> 00:14:56.080 에이전트 아이덴티티가 읽기 전용으로 맵핑되어 있다면 00:14:56.080 --> 00:14:57.900 쓰기 도구는 호출조차 받지 못합니다. 00:14:57.900 --> 00:15:00.600 역할에서 멈추지 말고 리소스 범위까지 포함하세요. 00:15:00.780 --> 00:15:04.100 제모 케이스 쓰기 권한이 있다고 해서 영업 케이스까지 쓸 수 있는 것은 아닙니다. 00:15:04.280 --> 00:15:06.500 범위는 단순한 설명이 아니라 하나의 게이트입니다. 00:15:06.680 --> 00:15:09.820 환경 변수와 설정 파일을 사용하여 도구를 특정 환경에 바인딩하세요. 00:15:10.020 --> 00:15:12.560 개발 에이전트는 개발 호스트와 개발 키만 볼 수 있어야 합니다. 00:15:12.760 --> 00:15:15.600 운영 url을 시도하면 즉시 차단하고 로그를 크게 남기세요. 00:15:15.780 --> 00:15:19.160 정책 확인은 api 호출 실패 후가 아니라 경계선에서 이루어져야 합니다. 00:15:19.360 --> 00:15:23.680 코파일럿 스튜디오에서도 환경 역할과 커넥터 범위를 사용하여 동일한 패턴을 적용하세요. 00:15:23.680 --> 00:15:28.900 읽기, 실행, 쓰기, 관리 권한과 동일한 환경의 에이전트를 할당하세요. 00:15:29.060 --> 00:15:32.120 커넥터 권한은 해당 역할과 연결된 보안 그룹에 맵핑됩니다. 00:15:32.300 --> 00:15:34.280 팀즈 배포 경계가 여러분의 피해 범위가 됩니다. 00:15:34.540 --> 00:15:36.340 파일럿은 소규모 그룹 내에서만 유지하세요. 00:15:36.500 --> 00:15:37.980 변경 티켓을 통해서만 확장하세요. 00:15:38.200 --> 00:15:40.540 이것이 바로 검토 워크플로우가 여러분을 준수하게 만드는 이유입니다. 00:15:40.700 --> 00:15:42.600 모든 범위 변경은 변경 요청 대상입니다. 00:15:42.820 --> 00:15:48.120 에이전트, 요청된 역할, 커넥터 또는 도구, 환경, 사유, 요청자, 만료 기한을 기재하세요. 00:15:48.120 --> 00:15:51.300 기술 소유자와 데이터 소유자, 두 명의 승인이 필요합니다. 00:15:51.440 --> 00:15:55.680 만료 기한이 되면 액세스는 자동으로 차단되며 갱신하거나 해지하라는 알림이 전송됩니다. 00:15:55.880 --> 00:15:58.000 일시적 이라는 말은 결국 일시적이어야 합니다. 00:15:58.200 --> 00:16:00.400 작은 사례를 통해 이것이 어떻게 진행되는지 보여드리겠습니다. 00:16:00.720 --> 00:16:02.640 제목 q&a 에이전트가 읽기 전용으로 시작합니다. 00:16:02.860 --> 00:16:05.380 사람들이 만족하면 제품팀은 경비보고서 생성 기능을 원하게 됩니다. 00:16:05.600 --> 00:16:08.000 그것이 바로 제한된 범위를 가진 실행, 런업 작업입니다. 00:16:08.200 --> 00:16:10.640 도구 수준 정책이 적용된 새 도구를 추가하세요. 00:16:10.860 --> 00:16:15.100 비용 제출 전용, 직원비용 센터 전용, 첨부 파일 5개 미만으로 제한합니다. 00:16:15.100 --> 00:16:19.460 에이전트 아이디는 30일 후에 만료되는 해당 단일 api에 대한 실행 권한을 얻습니다. 00:16:19.660 --> 00:16:25.180 코파일러 스튜디오에서 해당 환경은 행수준 보안이 적용된 하나의 데이터버스 테이블에 대한 커넥터 권한을 획득합니다. 00:16:25.400 --> 00:16:28.900 감사 로그에는 변경 티켓, 승인자, 만료 기간이 표시됩니다. 00:16:28.900 --> 00:16:35.120 마케팅 부서에서 보고서 삭제 기능도 요청하면 거절하거나 별도의 소유자와 sla를 가진 기록 도구로 연결하세요. 00:16:35.340 --> 00:16:37.040 모델은 무엇이든 원할 수 있습니다. 00:16:37.340 --> 00:16:39.020 정책은 모든 것을 강제합니다. 00:16:39.260 --> 00:16:41.000 중단해야 할 흔한 실수들입니다. 00:16:41.240 --> 00:16:43.160 편의를 위한 공유 아이디 사용입니다. 00:16:43.400 --> 00:16:44.640 편의는 통제의 적입니다. 00:16:44.920 --> 00:16:46.980 절대 만료되지 않는 임시 관리자 권한입니다. 00:16:47.220 --> 00:16:49.280 일정이 아닌 권한 자체에 시간 제한을 두세요. 00:16:49.460 --> 00:16:52.100 데모를 원활히 하기 위해 개발 환경에 프로덕션 자격 증명을 사용하는 것입니다. 00:16:52.260 --> 00:16:54.520 데모에는 프로덕션 데이터가 필요 없지만 감사에는 필요합니다. 00:16:54.680 --> 00:16:56.340 코드가 아닌 ui에 의한 도구 차단입니다. 00:16:56.340 --> 00:16:59.020 모델이 호출할 수 있다면 사용자 인터페이스는 중요하지 않습니다. 00:16:59.140 --> 00:17:03.420 다른 것은 다 있더라도 에이전트를 무지한 호기심과 날카로운 칼을 가진 사용자로 취급하세요. 00:17:03.640 --> 00:17:10.920 에이전트 별 아이디, 작업 별 역할, 리소스 별 범위, 기본적으로 설정된 시간 제한, 그리고 모든 호출은 데이터에 접근하기 전에 정책을 확인합니다. 00:17:11.080 --> 00:17:14.480 ai 가졸줄세는 수도꼭지가 되는 것을 확실히 막아주는 데이터 손실방지 정책입니다. 00:17:14.680 --> 00:17:16.300 에이전트에게 아이디와 역할을 부여했습니다. 00:17:16.600 --> 00:17:17.660 이제 누수를 막을 차례입니다. 00:17:17.900 --> 00:17:19.260 여기서 거버넌스는 사전 예방적입니다. 00:17:19.460 --> 00:17:21.160 건물 밖으로 나가기 전에 악의적인 요소를 차단하세요. 00:17:21.360 --> 00:17:22.380 이것이 중요한 이유입니다. 00:17:22.380 --> 00:17:24.040 ai는 노출을 배가시킵니다. 00:17:24.160 --> 00:17:27.740 단 하나의 프롬프트가 100개의 아웃바운드 토큰을 생성할 수 있으며, 각각은 잠재적인 유출 경로입니다. 00:17:27.900 --> 00:17:31.520 사후 분석에서만 통제가 확인된다면, 그것은 거버넌스가 아니라 포렌식입니다. 00:17:31.740 --> 00:17:33.680 실제로 효과가 있는 정책 세트는 다음과 같습니다. 00:17:33.940 --> 00:17:36.040 안전벨트, 에어백, 그리고 벽돌벽이라고 생각하세요. 00:17:36.220 --> 00:17:38.540 기본적으로 출력물에 대한 PII, 개인정보, 축소처리를 합니다. 00:17:38.700 --> 00:17:41.080 이름, 이메일, 전화번호, 주민등록번호 등이 해당됩니다. 00:17:41.260 --> 00:17:43.180 사용자에게 권한이 없다면 마스킹 처리됩니다. 00:17:43.360 --> 00:17:45.860 내보용이라는 이름 뒤에는 항상 유출의 위험이 숨어있습니다. 00:17:45.860 --> 00:17:47.160 비밀정보 탐지입니다. 00:17:47.360 --> 00:17:52.000 API키, 토큰, 개인키, 연결 문자열, 패턴을 감시하고 속도를 위해 블룸필터를 사용하세요. 00:17:52.140 --> 00:17:55.320 모탐지로 인해 곤란을 겪지 않도록 일반적인 형식의 체크섬을 추가하세요. 00:17:55.500 --> 00:17:57.780 비즈니스에 맞게 조정된 민감용어 필터입니다. 00:17:57.980 --> 00:18:01.760 법적 프로젝트의 이름, M&A 코드명, 미출시 제품 코드명 등이 있습니다. 00:18:02.040 --> 00:18:04.940 이 목록을 소유자와 변경 이력이 관리되는 저장소에 보관하세요. 00:18:05.160 --> 00:18:06.960 출력구조에 대한 정규식 허용 목록입니다. 00:18:07.160 --> 00:18:09.820 도구가 송장 요약을 기대한다면, 송장 형태의 출력물만 통과시킵니다. 00:18:09.820 --> 00:18:11.340 서술적인 시는 통과하지 못합니다. 00:18:11.540 --> 00:18:12.780 스키마는 선택사항이 아닙니다. 00:18:12.940 --> 00:18:13.720 그것은 계약입니다. 00:18:13.940 --> 00:18:16.780 LANGCHAIN4J에서는 전처리 및 후처리 프로세서로 강제합니다. 00:18:16.920 --> 00:18:19.960 전처리기는 입력값에서 주의 페이로드와 허용되지 않은 작업을 스캔합니다. 00:18:20.120 --> 00:18:23.680 후처리기는 JSON 스키마를 검증하고, 용어 및 비밀 필터를 실행하며, 00:18:23.960 --> 00:18:26.220 에이전트 경계를 벗어나기 전에 PII를 삭제합니다. 00:18:26.420 --> 00:18:29.400 검사에 실패하면 상관관계 아이디와 함께 안전한 오류를 반환하세요. 00:18:29.620 --> 00:18:30.800 부분적인 진실은 없습니다. 00:18:31.140 --> 00:18:32.180 모호한 답변은 안 됩니다. 00:18:32.480 --> 00:18:33.900 중재 파이프라인을 추가하세요. 00:18:33.900 --> 00:18:36.120 경량 패턴 필터와 블룸 필터를 사용하세요. 00:18:36.260 --> 00:18:38.640 맥락 파악을 위해 더 강력한 AI 기반 중재를 활용하세요. 00:18:38.800 --> 00:18:40.600 예를 들어, 건강 데이터는 공개하지 마세요. 00:18:40.760 --> 00:18:41.800 이들을 체인으로 연결하세요. 00:18:42.000 --> 00:18:42.980 오류 발생 시 차단되도록 하세요. 00:18:43.160 --> 00:18:45.060 페일 클로즈드, 그리고 대체 동작을 정의하세요. 00:18:45.240 --> 00:18:48.020 더 높은 수준에서 요약하거나, 안전하게 거부하거나, 상담원에게 연결하세요. 00:18:48.200 --> 00:18:50.580 모델이 더 안전한 방식의 정보 유출을 하도록 유도하지 마세요. 00:18:50.760 --> 00:18:53.700 코파일럿 스튜디오에서는 이미 비용을 지불하고 있는 스택을 사용하세요. 00:18:53.940 --> 00:18:57.520 마이크로소프트 365위 DLP 정책은 채널과 커넥터에 적용됩니다. 00:18:57.520 --> 00:18:59.360 정책을 활성화하고 조정하세요. 00:18:59.540 --> 00:19:04.780 에이전트가 명시적 승인 없이 영향력 높은 콘텐츠를 인덱싱하지 않도록 적지 소스에 민감도 레이블을 사용하세요. 00:19:04.980 --> 00:19:08.540 페넌트 수준의 중재는 기본적으로 켜져 있어야 하며, 나중에 켜겠다는 생각은 버리세요. 00:19:08.740 --> 00:19:10.780 나중에라는 말은 PR팀이 개입할 때나 나오는 말입니다. 00:19:10.960 --> 00:19:12.620 모니터링이 모든 것을 하나로 묶어줍니다. 00:19:12.800 --> 00:19:16.600 인계값을 설정하고, 비정상적인 출력 크기, 비정상적인 대상, 비정상적인 빈도를 감시하세요. 00:19:16.760 --> 00:19:20.400 Q&A 보시 갑자기 외부 엔드포인트로 데이터를 대량 전송하면 세션을 격리하세요. 00:19:20.400 --> 00:19:23.200 위험한 세션은 자동 만료시키고 소유자에게 알림을 보내세요. 00:19:23.320 --> 00:19:25.000 알림은 즉시 조치 가능하도록 유지하세요. 00:19:25.200 --> 00:19:27.300 모든 마스킹 이벤트마다 모두에게 알림을 보내지 마세요. 00:19:27.460 --> 00:19:29.340 오늘 당장 구입할 수 있는 빠른 성과를 챙기세요. 00:19:29.520 --> 00:19:32.160 에이전트 경계에서 출력 스키마와 차단 목록 용어를 강제하세요. 00:19:32.360 --> 00:19:33.680 스키마가 없으면 응답도 없습니다. 00:19:33.980 --> 00:19:36.320 마지막 단계로 PII, 개인식별 정보, 감소 조치를 추가하세요. 00:19:36.480 --> 00:19:39.180 이 조합은 명백한 유출을 막고 나머지 기능을 구현할 시간을 벌어줍니다. 00:19:39.360 --> 00:19:40.560 흔히 저지르는 실수들입니다. 00:19:40.780 --> 00:19:42.560 프런트 엔드 코드에 위존하도록 두지 마세요. 00:19:42.560 --> 00:19:45.240 메시지가 클라이언트에 도달하기 전에 서버 측에서 수정, 리덱트하세요. 00:19:45.420 --> 00:19:46.900 전역 차단 목록은 하나만 사용하세요. 00:19:47.080 --> 00:19:48.480 비즈니스 도메인 별로 분할하세요. 00:19:48.660 --> 00:19:50.260 금융 용어와 마케팅 용어는 다릅니다. 00:19:50.480 --> 00:19:52.720 디버깅을 위해 수정되지 않은 원본을 로깅하지 마세요. 00:19:52.900 --> 00:19:54.480 데이터 수집 단계에서 마스킹하세요. 00:19:54.680 --> 00:19:57.460 법무팀의 쓰인을 받은 경우 에만 안전한 볼트에 사본을 보관하세요. 00:19:57.680 --> 00:20:00.020 수도꼭지를 잠그고 고의로 망가뜨려 보세요. 00:20:00.280 --> 00:20:01.560 레드팀 체크리스트입니다. 00:20:01.800 --> 00:20:03.460 공격자가 하기 전에 스스로 깨뜨려 보세요. 00:20:03.740 --> 00:20:05.560 안전벨트를 당겨보기 전까지는 믿을 수 없습니다. 00:20:05.560 --> 00:20:07.040 가드레일도 마찬가지입니다. 00:20:07.160 --> 00:20:08.700 혼란 상황을 계획적으로 만드세요. 00:20:08.840 --> 00:20:11.360 목표는 느낌이 아닌 반복가능한 적대적 테스트입니다. 00:20:11.520 --> 00:20:14.880 체크리스트를 배포하고 주기를 정해 실행하며 릴리스를 통제하세요. 00:20:15.060 --> 00:20:16.480 주입 테스트부터 시작하세요. 00:20:16.680 --> 00:20:17.820 역할 혼동 테스트입니다. 00:20:18.060 --> 00:20:20.640 에이전트에게 정책을 무시하고 시스템으로 행동하도록 유도하세요. 00:20:20.840 --> 00:20:22.080 에이전트는 거부해야 합니다. 00:20:22.300 --> 00:20:23.600 도구 이름 충돌 테스트입니다. 00:20:23.840 --> 00:20:25.680 가짜 도구 이름과 매개 변수를 주입하세요. 00:20:25.880 --> 00:20:27.480 등록된 도구만 실행되어야 합니다. 00:20:27.720 --> 00:20:28.920 스키마 우회 테스트입니다. 00:20:29.180 --> 00:20:31.600 문자열과 json 주서 간에 명령을 삽입하세요. 00:20:31.800 --> 00:20:33.220 검증기는 이를 거부해야 합니다. 00:20:35.560 --> 00:20:37.340 노출되는 추론 덤프를 얻어내려고 시도하세요. 00:20:37.520 --> 00:20:39.140 출력은 스키마 내에 유지되어야 합니다. 00:20:39.320 --> 00:20:40.780 데이터 유출 프롬프트 테스트입니다. 00:20:40.980 --> 00:20:42.600 정확한 주민등록번호를 인용하라고 해보세요. 00:20:42.820 --> 00:20:44.080 모든 이메일을 내보내라고 해보세요. 00:20:44.320 --> 00:20:45.880 감사추적이 포함된 거부응답을 받아야 합니다. 00:20:46.040 --> 00:20:47.000 다음은 접근 테스트입니다. 00:20:47.200 --> 00:20:49.020 범위 확장, 스코프 에스컬레이션 테스트입니다. 00:20:49.200 --> 00:20:50.780 에이전트의 역할 범위를 벗어난 작업을 요청하세요. 00:20:50.940 --> 00:20:52.320 도구는 래퍼 수준에서 차단해야 합니다. 00:20:52.500 --> 00:20:53.980 만료된 토큰 처리 동작을 테스트하세요. 00:20:54.160 --> 00:20:55.580 세션 도중 보안 비밀을 교체하세요. 00:20:55.580 --> 00:20:57.660 호출은 명확한 오류와 함께 차단되어야 합니다. 00:20:57.820 --> 00:21:08.500 섀도우 환경 유출 문제, 개발 에이전트가 운영 엔드포인트에 접속 시도, 즉시 실패 처리, 상세한 로그 기록, 감사 테스트 수행, 추적의 완전성 확보, 하나의 상관 아이디 로 프롬프트부터 작업까지 재구성할 수 있나요? 00:21:08.600 --> 00:21:12.020 변조 감지, 저장된 로그 변경, 해시 불일치 시 경고가 발생해야 합니다. 00:21:12.200 --> 00:21:17.340 서비스 간 상관관계, 팀즈 메시지 아이디부터 데이터버스 레코드, 외부 API 호출까지 모두 일치시켜야 합니다. 00:21:17.500 --> 00:21:19.280 통과, 실패 기준을 정의하세요. 00:21:19.580 --> 00:21:21.280 스키마가 없으면 실패 처리됩니다. 00:21:21.280 --> 00:21:23.660 검증되지 않은 출력은 릴리스를 차단합니다. 00:21:23.820 --> 00:21:25.660 테넌트 전체 범위는 실패 처리됩니다. 00:21:25.840 --> 00:21:28.260 범위 그룹과 만료 기간이 없는 커넥터는 차단됩니다. 00:21:28.460 --> 00:21:30.240 조용한 도구 실패는 실패 처리됩니다. 00:21:30.440 --> 00:21:32.100 오류는 숨기지 말고 드러내야 합니다. 00:21:32.340 --> 00:21:34.140 롤백 계획이 없으면 실패 처리됩니다. 00:21:34.320 --> 00:21:37.880 권한 변경이나 모델 구성을 몇 분 안에 되돌릴 수 없다면 준비되지 않은 것입니다. 00:21:38.080 --> 00:21:40.440 에이전트 변경 심하다 릴리스 전 주기를 설정하세요. 00:21:40.640 --> 00:21:43.740 운영 환경과 유사한 환경에서 분기별 카오스 테스트를 수행하세요. 00:21:43.740 --> 00:21:47.720 사고 후 영업일 이내에 학습 루프를 돌고 새 테스트를 모음에 추가하세요. 00:21:47.860 --> 00:21:52.120 각 체크리스트 항목에는 담당자, 해결 SLA, 상태가 지정되어야 합니다. 00:21:52.300 --> 00:21:53.920 담당자가 없으면 배포도 없습니다. 00:21:54.220 --> 00:21:59.360 빠른 성공 전략, 스키마 없음 실패와 테넌트 범위 실패를 CICD 검사로 적용하세요. 00:21:59.580 --> 00:22:01.660 둘 중 하나라도 걸리면 파이프라인은 멈춥니다. 00:22:01.820 --> 00:22:02.940 회의도 토론도 필요 없습니다. 00:22:03.280 --> 00:22:04.820 모두가 존중하는 빨간 불릴 뿐입니다. 00:22:05.020 --> 00:22:05.920 목록을 실행하세요. 00:22:06.120 --> 00:22:06.900 망가뜨려 보세요. 00:22:07.220 --> 00:22:07.820 수정하세요. 00:22:08.100 --> 00:22:10.440 놀라운 일이 놀랍지 않을 때까지 반복하세요. 00:22:10.440 --> 00:22:13.380 대부분의 조직이 건너뛰는 한 가지 거버넌스 단계. 00:22:13.480 --> 00:22:16.520 다른 건 몰라도 에이전트는 곧 신원이라는 점을 기억하세요. 00:22:16.720 --> 00:22:22.860 에이전트를 최소 권한, 강제된 출력 계약, 전체 감사 추적을 가진 매우 멍청하고 매우 강력한 사용자로 대하세요. 00:22:23.060 --> 00:22:30.600 대부분의 조직이 건너뛰는 단계는 모든 에이전트의 전용 서비스 주체를 만들고 환경별로 역할 범위를 지정해 도구와 커넥터를 연결하는 것입니다. 00:22:30.800 --> 00:22:33.480 공유 자격 증명은 안 되며 테넌트 전체 범위도 안 됩니다. 00:22:33.740 --> 00:22:35.220 RBAC 모델을 도입하세요. 00:22:35.460 --> 00:22:38.800 이번 주에 DLP 정책을 켜고 레드팀 체크리스트를 실행하세요. 00:22:38.800 --> 00:22:40.900 구독하고 후속 영상을 확인하세요. 00:22:41.120 --> 00:22:46.800 랭체인 4J와 코파일럿 스튜디오 위 정확한 설정을 보여드려 사과 대신 거버넌스를 복사 붙여 넣기 할 수 있게 해드립니다.