스크립트
00:00:00여러분 안녕하세요, 잘 지내고 계신가요? 이제 마무리 단계에 접어들었네요. 제 이름은 사라입니다. 포스트호그에서 컨텍스트
00:00:23엔지니어로 일하고 있으며, 매일 우리가 사랑하는 위저드(Wizard)를 개발하는 즐거움을 누리고 있습니다.
00:00:30자, 위저드란 무엇일까요? 위저드는 여러분을 위해 포스트호그를 설정해 주는 도구입니다. 에이전틱 CLI 도구로서
00:00:39여러분의 코드베이스를 읽고, 프로젝트에 알맞은 SDK를 설치하며, 이벤트 추적을
00:00:44구현하고, 대시보드까지 설정해 줍니다. 예전에는 설정하는 데만 한두 시간
00:00:52걸리던 작업을 약 5~6분 만에 실행해 줍니다. 게다가 추론 비용도 무료이므로
00:00:57포스트호그를 아주 기분 좋게 시작하실 수 있습니다. 꽤 멋진 기능이죠. 사람들도
00:01:03매우 좋아합니다. 하지만 몇 달 전에 우리는 감히 이런 상상을 해봤습니다. 만약 이것이 프로젝트에 포스트호그를 설치하는 권장 또는 기본
00:01:10 방법이 된다면 어떨까 하고요. 그러자 제 안의 보안 경보 벨이 울리기 시작했습니다.
00:01:17이것이 얼마나 안전한지 의문이 들기 시작했죠. 악성코드처럼 생겼다는 생각이 들었거든요.
00:01:25그리고 그 의문을 품는 과정에서 정말 많은 것을 배웠습니다. 그래서 오늘은 제가 배운 교훈들과,
00:01:31이걸 만드는 동안 밤잠을 설치게 했던 일들, 그리고 그로 인해 결국 만들게 된 결과물에 대해 이야기하려 합니다.
00:01:37지루한 보안 이야기에 들어가기 전에, 즉 여러분이 오후 2시에 졸음을 참아야 하는 시간 전에, 위저드가 실제로 실행되는 모습을 보여드리고 싶습니다.
00:01:49화면을 보시면 반복 재생되고 있습니다. 이것은 포스트호그 위저드를 npx로 실행하는 모든 사용자가
00:01:56터미널에서 겪는 정확히 그 경험입니다. 말씀드렸다시피 이건 에이전트입니다. 프로젝트에 알맞은 SDK를 파악하고, 자동으로 설치하며, 이벤트 추적을 구현하고, 대시보드를 구축해 줍니다.
00:02:10저는 이걸 터미널 안의 아주 작은 구현 엔지니어라고 부릅니다. 가끔 사람들에게 이걸 보여주면 왜 하필 에이전트냐고 묻습니다. 사용자에게 좋은 프롬프트를 주면 되지 않냐고, 사용자 자신의 도구에서 호출할 수 있는 스킬을 주면 되지 않냐고 하죠.
00:02:23물론 그런 기능들도 제공하지만, 그에 대한 대답은 이러한 개발자 경험과 위저드의 역량이 바로 핵심이기 때문입니다. 그것 자체가 온전한 제품입니다.
00:02:34에이전트 루프에 온전히 참여할 수 있는 CLI 도구를 만들었으며, 그것을 처음 경험해 보는 것은 정말 강력한 일이기 때문입니다.
00:02:43하지만 위저드 같은 도구는, 그 도구를 좀 미심쩍게 보이게 만드는 요소들을 함께 담아내지 않고는 출시할 수 없습니다.
00:02:50자, 한번 해체해 봅시다. 위저드의 구조를 살펴보죠. 위협 모델은 대개 에이전트의 구조 그 자체에서 자연스럽게 도출되니까요.
00:03:01위저드는 여러분 중 많은 분이 에이전트를 만들 때 구성하는 형태와 비슷합니다.
00:03:07특정 작업용으로 선택한 모델들이 있고, 그것을 유도하는 프롬프트가 있으며, 작업을 완수하기 위해 에이전트에 쥐어준 일련의 도구들이 있습니다.
00:03:17하지만 우리에게 아주 특화된 몇 가지 구성 요소도 있습니다. 제 팀이 자체 사내 기술로 완전히 구축한 컨텍스트 엔진이 있죠.
00:03:25이것 덕분에 에이전트가 훌륭한 업무를 수행하고 실행할 때마다 일관된 결과를 낼 수 있습니다.
00:03:30저는 이걸 위저드의 두뇌라고 부르기도 합니다. 가끔은 '트렌치코트를 입은 마크다운'이라고도 부르죠.
00:03:35하지만 이는 당사의 사내 컨텍스트 엔진입니다. 또한 잉크(Ink)를 사용해 직접 구축한 터미널 UI도 있습니다.
00:03:43그리고 이제는 '워록(Warlock)'이라는 보안 스캐너도 존재합니다. 이 도구는 제가 프로덕션 환경에 에이전트를 배포하면서 주변을 살피고 끔찍한 보안 공포들을 마주했을 때 직접 만든 것입니다.
00:03:55명령어를 실행할 수 있는 에이전트의 구조를 살펴보면, 기본적으로 제가 '악성코드 스타터 팩'이라고 부르는 형태와 같습니다.
00:04:03여러분이 마음이 아주 후하거나 혼돈의 악 성향이 아니라면 악성코드에 쥐어줄 법한 바로 그 구성과 거의 똑같기 때문입니다.
00:04:11다행히도 이것은 최악의 시나리오이자 악몽 같은 이야기일 뿐, 제 자백이 아니라 여러분 모두를 위한 경고입니다.
00:04:19만약 손발이 달린 에이전트, 즉 명령어를 실행할 수 있는 에이전트를 배포하고 싶다면 이런 식으로 만들지 않도록 반드시 주의해야 하기 때문입니다.
00:04:28위저드의 V0 버전이 탄생하게 된 계기는, 우리 그로스 팀의 조시 스나이더(Josh Snyder)가 커서(Cursor)가 포스트호그 설정을 그야말로 최악의 방식으로 엉망진창으로 환각해 내는 것을 지켜보았기 때문입니다.
00:04:41그리고 그는 더 나은 작업을 수행할 수 있는 에이전트를 만들면 어떨까 생각했죠.
00:04:46그렇게 제 팀은 커서의 환각보다 훨씬 더 일을 잘한다는 것을 검증하면서 그 위에 개발을 쌓아 올리기 시작했습니다.
00:04:52그리고 생각했습니다. 누구나 포스트호그에 온보딩할 수 있게 만드는 도구면 어떨까 하고요.
00:04:58사용자가 프레임워크가 무엇이든, 스택이 무엇이든 상관없이, 사용자가 손가락 하나 까딱하지 않고도 모든 이벤트를 추적할 수 있도록 말입니다.
00:05:04그러다 감히 상상했습니다. 이것이 포스트호그를 설치하는 기본 방식이 된다면 어떨까 하고요.
00:05:09우리는 매주 수천 명의 개발자가 이를 실행하는 꿈을 꾸었고, 어제 드디어 매주 8,000명이 이를 실행하는 기록을 달성했습니다.
00:05:16그래서 우리의 꿈이 이루어졌죠.
00:05:18하지만 그런 꿈을 꾸던 그 시절, 우리는 보안 태세를 현미경으로 들여다보듯 면밀히 검토하고 무슨 일이 일어나고 있는지 살펴봐야 했습니다.
00:05:26그래서 제가 그 책임을 맡아 자리에 앉아 우리의 현재 위치를 평가했습니다.
00:05:31초창기에는, 그러니까 1년에서 9개월 전쯤에는 제가 '레이어 0'이라고 부르는 단계가 있었습니다. 왜냐하면 그것은 말 그대로 보안이 아니었기 때문입니다.
00:05:41그저 에이전트가 무엇을 해야 할지 제안하고 유도하는 프롬프트일 뿐이었고, 프롬프트는 보안이 아니니까요.
00:05:48그래서 그때 저는 걱정이 많았습니다.
00:05:51레이어 1은 허용 목록(allow list)이었습니다.
00:05:53이 허용 목록을 파기 시작했을 때, 꽤 엄격하게 제한되어 있었기 때문에 마음이 조금 편해지기 시작했습니다.
00:05:59하지만 여전히 우려되는 점이 많았습니다.
00:06:01그리고 제가 앞서 말씀드린 그 컨텍스트 엔진 때문에 패닉에 빠지기 시작했죠.
00:06:05우리는 런타임에 에이전트로 정말 많은 컨텍스트를 주입하고 있었습니다.
00:06:09그래서 위저드로 들어가는 위협 형태의 데이터와 위저드에서 나오는 위협 형태의 데이터를 탐지하기 위해 정말 허술한 정규식 스캐너를 만들었습니다.
00:06:20그리고 인정하건대 그것은 극도로 엉성했습니다.
00:06:23하지만 이 이야기를 여러분 모두에게 아주 솔직하게 털어놓는 이유는, 우리 모두 극도로 실험적인 무언가를 만들고 있고 엄청나게 빠른 속도로 개발을 진행하고 있기 때문입니다.
00:06:33그리고 우리 모두가 보안 전문가인 것은 아니라는 점도 잘 알고 있습니다.
00:06:38저처럼 부딪히며 현장에서 배우는 사람들도 있고요.
00:06:43하지만 이런 형태의 시스템을 만들 때라면 반드시 고민해 봐야 하는 문제입니다.
00:06:50이것이 우리의 보안 태세였습니다.
00:06:53하지만 저는 질문을 던졌습니다. 우리 끝난 걸까요?
00:06:56다행히도, 생각했던 것보다는 덜 망해 있었습니다.
00:06:59앞서 언급했던 그 허용 목록이 꽤나 단단하게 묶여 있었기 때문입니다.
00:07:03Bash는 기본적으로 거부(deny by default)하도록 설정되어 있었습니다.
00:07:06우리가 사전에 검증한 신뢰할 수 있는 패키지만 설치할 수 있었습니다.
00:07:09빌드는 할 수 있었습니다.
00:07:10타입 검사도 가능했습니다.
00:07:11린트 검사도 할 수 있었고요.
00:07:12그 외에는 거의 아무것도 할 수 없었습니다.
00:07:13임의의 쉘 명령어를 실행할 수 없었죠.
00:07:16그리고 환경 변수에도 접근할 수 없었습니다.
00:07:20에이전트가 여러분의 .env 파일을 읽지 못하도록 원천 차단했고, 비밀 정보는 볼트(vault)를 통해 안전하게 라우팅하고 있었습니다.
00:07:28그래서 저는 안도의 한숨을 쉬며 우리가 생각보다 더 나은 상태에 있다는 것을 깨달았습니다.
00:07:34하지만 보안에는 언제나 틈이 존재하기 때문에, 구멍이 어디에 있는지 정확히 알고 싶었습니다.
00:07:39그래서 우리 모두가 마땅히 해야 할 일을 했습니다.
00:07:41보안 팀에 연락해서 “이 시스템을 감사(audit)하고 취약점을 찾아줄 수 있나요?”라고 부탁했습니다.
00:07:48그리고 그들은 몇 가지 문제점을 찾아냈습니다.
00:07:51몇 가지 허점을 발견했죠.
00:07:52흥미로운 점은 그들이 발견한 구체적인 결함이나 버그 자체가 아니라, 그것들의 형태였습니다.
00:07:58그 문제들 중 명백하게 악의적인 것은 거의 없었기 때문입니다.
00:08:01모두 지극히 무해하고 선의를 가진 두 가지 요소가 서로 악수를 나누며 구멍을 열어주는 형태였습니다.
00:08:07그래서 제가 배운 교훈은 공격은 조합(compose)되지만 코드 리뷰는 그렇지 않다는 점이었습니다. 개발자들인 우리 모두는 변경 사항(diff)을 하나씩만 살펴보니까요.
00:08:20하지만 공격자들은 시스템 전체를 바라보며 서로 악수를 나누고 문을 열어주는 그 두 가지 요소를 찾아냅니다.
00:08:25하지만 저를 밤잠 설치게 만든 요인이 한 가지 더 있었습니다.
00:08:29다시 그 컨텍스트 엔진으로 돌아가서 생각해보니, 우리가 만든 에이전트에서 가장 무서운 부분은 우리 사례의 경우 명령어가 아니라는 점을 깨달았습니다.
00:08:37그것은 바로 우리가 에이전트의 두뇌에 주입하고 있던, 겉보기엔 유용해 보이는 데이터들이었습니다.
00:08:43아, 제가 반대 방향으로 간 것 같네요.
00:08:46맞습니다.
00:08:47컨텍스트 밀(Context Mill)입니다.
00:08:48이것이 바로 우리의 컨텍스트 엔진, 즉 위저드의 두뇌입니다.
00:08:51위저드가 무엇이든 알고 있으며 실제로 일을 잘 해내는 이유가 바로 여기에 있죠.
00:08:56우리 문서에서 데이터를 끌어옵니다.
00:08:58개발 과정에서 배운 함정(gotcha)들과 교훈들이 담긴 직접 작성한 프롬프트들을 가지고 있습니다.
00:09:02그리고 에이전트가 패턴을 매칭하여 여러분을 위해 아주 훌륭한 방식으로 포스트호그를 설치할 수 있도록 돕는 실제 작동하는 엔드투엔드 예제 앱들도 포함되어 있죠.
00:09:11이 모든 것을 MCP 서버를 통해 위저드로 전송되는 스킬 번들로 패키징하여 런타임에 에이전트의 컨텍스트로 직접 로드합니다.
00:09:22자, 이 점을 잠시 곱씹어 보세요.
00:09:24이 시스템은 콘텐츠를 가져와서 명령어 실행이 가능한 에이전트에 주입하는 것이 전적인 임무인 기계입니다.
00:09:31만약 여러분이 공격자라면 이렇게 생각할지도 모릅니다. “콘텐츠만 오염시키면 어떨까?”라고요.
00:09:36사용자의 코드베이스가 아니라, 에이전트 자체가 아니라, 바로 그 실제 콘텐츠를 말입니다.
00:09:41포스트호그에서는 모든 것을 오픈소스로 개발하기 때문에 누군가 우리의 오픈소스 저장소 중 하나에 풀 리퀘스트를 열고,
00:09:48마크다운 파일이나 겉보기엔 무해한 코드 주석 속에 무언가를 주입한다고 해봅시다.
00:09:55그리고 LLM 기반의 코드 리뷰가 이를 검토하면서 “보기 좋네요(Looks good to me)”라며 그냥 넘어가 버릴 수도 있습니다.
00:10:04우리는 우리 자신이 서명한 프롬프트 주입 페이로드를, 샌드박스 환경이긴 하지만 수천 명의 개발자 기기에서 실행 중인 에이전트에 그대로 배포해 버렸을지도 모릅니다.
00:10:14바로 이것이 보안과 위저드에 대한 저의 생각을 완전히 뒤바꿔 놓은 위협이었습니다. 우리에게 위험한 입력은 정말로 우리의 자체 공급망으로부터 올 수 있으니까요.
00:10:25그래서 제가 결국 하게 된 일은 이 파이프라인의 양쪽 끝에서 콘텐츠를 스캔하는 것이었습니다.
00:10:30첫째는 스킬이 빌드되고 출시될 때이고, 둘째는 위저드가 실제로 그 스킬을 사용할 때입니다.
00:10:36제 방법론은 소스 단계에서 잡아내고, 소스가 뚫렸다고 가정하며, 사용 시점에 다시 한번 잡아내는 것입니다.
00:10:43자, 이제 여러분께 워록(Warlock)을 소개하겠습니다.
00:10:48워록을 만드는 것은 반드시 피해를 수습하기 위한 것은 아니었습니다.
00:10:52앞서 말씀드렸듯이 우리에게는 다른 방어 수단들도 있었으니까요.
00:10:55하지만 제가 워록을 만든 이유는 사람들에게 “음, 이 시스템은 대충 꽤 단단하게 잠겨 있어요”라고 말하기 싫었기 때문입니다.
00:11:01그건 확장성이 없습니다.
00:11:02프로덕션에 배포하고 싶은 그런 방식이 아니죠.
00:11:04수천 명의 개발자가 매일같이 실행하게 만들고 싶은 그런 방식도 아닙니다.
00:11:08그런 규모로 무언가를 배포할 때면, 위저드의 기능이 확장됨에 따라 훨씬 더 넓은 공격 표면, 훨씬 더 많은 사용자, 훨씬 더 많은 콘텐츠가 유입되기 때문입니다.
00:11:19그리고 아마 우리는 괜찮을 겁니다.
00:11:21다만 그것만으로는 더 이상 충분하지 않게 될 뿐입니다.
00:11:23그래서 저는 그곳에 대충 처박아 두었던 허술한 정규식 스캐너를 꺼내어 위저드에서 분리한 뒤 독립적인 도구로 만들었습니다.
00:11:30위저드 형태를 띤 모든 것에는 경호원이 필요하기 때문에 그 이름을 워록이라고 지었습니다.
00:11:35그리고 이 도구는 단 하나의 일만 수행합니다.
00:11:38여러분 문자열 하나를 건네주면,
00:11:40탐지된 결과 목록을 돌려줍니다.
00:11:42그 각각의 결과에는 카테고리, 심각도, 그리고 권장 조치가 포함되어 있으며, 거기서 역할을 마칩니다.
00:11:48여기서 '권장 사항'에 주목해 주셨으면 합니다.
00:11:51워록은 탐지만 할 뿐 행동하지 않기 때문입니다.
00:11:54워록은 이렇게 알려줄 겁니다. “이건 유출 같네요.
00:11:57심각합니다.
00:11:58차단하는 걸 추천합니다.”
00:11:59하지만 그 진단 결과로 실제로 무엇을 할지는 전적으로 여러분의 몫입니다.
00:12:04문제를 감지하는 것과 그 문제에 대해 어떻게 대처할지 결정하는 것은 완전히 별개의 일이기 때문입니다.
00:12:10이 모든 것을 이해하기 쉽게 유지하는 유일한 방법은 그 두 가지를 분리하는 것입니다.
00:12:15따라서 워록의 내부 구조를 보면, 직접 작성한 정규식 대신 야라(Yara)를 기반으로 규칙이 실행됩니다. 야라란 맬웨어 연구원들이 15년 이상 동안 사용해 온 패턴 엔진입니다.
00:12:27완전히 결정론적이죠.
00:12:28매번 똑같은 입력에 똑같은 출력이 나옵니다.
00:12:31의도적으로 지루하게 만들었습니다.
00:12:33그리고 보안 분야에서 지루하다는 것은 곧 기능입니다.
00:12:39그렇다면 워록은 현재 실제 운영 환경에서 실제로 무엇을 잡아내고 있을까요?
00:12:42여러 가지가 있지만, 그중 두 가지는 정말 영혼을 지치게 만드는 골칫거리입니다.
00:12:48첫 번째는 사실 규칙 형태의 문제가 아닙니다.
00:12:52하위 에이전트의 동작으로 인해 발생한 문제로, 하위 에이전트들이 무엇을 하느냐에 따라 우리에게 취약점이 노출되었음을 워록이 플래그를 통해 알려준 경우였습니다.
00:13:03기본적으로 우리는 대규모 작업을 수행하기 위해 에이전트를 실행하고 있었습니다.
00:13:07그 에이전트들이 하위 에이전트를 생성했고요.
00:13:08그 하위 에이전트들은 위중에 구현해 둔 가드레일을 우회하려고 시도했고, 시크릿 정보를 멋대로 만들어내려고 했습니다.
00:13:16코드베이스 내의 말 그대로 어디에서나 시크릿 정보를 빼내려고 시도했던 것이죠.
00:13:20그래서 우리는 그것을 차단했습니다.
00:13:21“하위 에이전트는 이제 그만”이라고 말했죠.
00:13:23그리고 워록 덕분에 우리는 그것을 잡아낼 수 있었습니다.
00:13:26로봇의 입장이 되어 공감해 볼 수도 있습니다.
00:13:28로봇에게는 수행해야 할 작업이 있었고, 최적화하여 우리를 기쁘게 해주려고 애썼던 것입니다.
00:13:32하지만 그렇다고 이걸 그냥 둘 수는 없습니다.
00:13:35또한 포스트호그에서 우리에게 정말 중요한 또 다른 것은 바로 개인정보(PII)입니다.
00:13:39에이전트는 명시적인 규칙을 만들어주지 않으면 데이터를 노출하는 것에 대해 진심으로 아무런 신경을 쓰지 않습니다.
00:13:46그냥 내버려 두면, 이메일이나 전화번호를 이벤트에 곧바로 덤프해 버리는 것을 보았습니다. 에이전트 입장에서는 수집하기에 지극히 정상적인 일처럼 보이기 때문입니다.
00:13:57다행히도 특히 프롬프트 인젝션과 관련해서는 (여기 나무를 톡톡 두드리며 말하는데요) 실제 운영 환경에서 악의적인 프롬프트 인젝션을 실제로 당해본 적이 거의 없습니다.
00:14:08하지만 가짜 양성(False Positive)은 엄청나게 많이 잡아냅니다. 데모 로그인 화면, 예제 앱의 문구, 문서에 있는 내용 같은 것들이죠.
00:14:17이로 인해 저는 애플리케이션을 구축하는 방식과 문서를 작성하는 방식을 다시 생각하게 되었습니다. 위협처럼 보이는 것은 그 무엇도 배포하고 싶지 않기 때문입니다.
00:14:27하지만 이 가짜 양성들은 솔직히 이 모든 과정에서 가장 지저분하고 흥미로운 부분을 위한 완벽한 준비 단계입니다.
00:14:36그래서 이 부분이 제가 고민했던 지점입니다.
00:14:39이 강연 내내 여러분에게 결정론적인 방식을 설파해 놓고서는, 막상 가짜 양성을 분류하고 소음을 줄이는 데 도움을 주고자 LLM 레이어를 추가했으니까요.
00:14:50저는 이를 트리아지(Triage)라고 부릅니다.
00:14:51이 트리아지 레이어를 구축할 때 저는 선택을 내려야 했습니다.
00:14:56이 레이어를 문지기로 만들어야 할까요, 아니면 조언자로 만들어야 할까요?
00:15:01가장 쉬운 선택은 아마 LLM을 문지기로 만드는 것이었을 겁니다.
00:15:06명령어를 보여주고, 이게 공격인지 물어본 뒤 차단하거나 허용하고, 그냥 모델이 시키는 대로 하는 것이죠.
00:15:13그게 더 쉬워 보여서 유혹적이긴 하지만, 모델이 컨디션이 안 좋거나 무슨 일이 생겨서 어제와는 다르게 행동한다는 이유만으로 동전 던지기에 제 보안 모델을 걸 수는 없습니다.
00:15:26그래서 문지기 대신, 모델이 조언자 역할을 하도록 설계했습니다.
00:15:32이것이 제가 찾아낸 명확한 경계선이며, 지금도 계속 탐구하고 있고 여러분께 남기고 싶은 메시지입니다.
00:15:38첫째, 우리에게 탐지와 집행은 여전히 결정론적이고 기계적으로 이루어집니다.
00:15:43규칙이 일치하면 문이 잠기고 세션이 종료되며, 그 경로 상에는 모델이 전혀 개입하지 않습니다.
00:15:49차단은 LLM의 의견을 묻기도 전에 일어납니다.
00:15:54LLM은 뭔가를 차단하지 않은 경우에만 그 후에 의견을 낼 수 있습니다.
00:15:58소음을 제거하도록 설계된 것이지,
00:16:00무언가를 통과시키도록 설계된 것이 아닙니다.
00:16:03그리고 모델이 오작동하여 실패할 경우(Fail-closed), 즉 모델의 컨디션이 나쁘다면 모든 위저드 실행이 종료됩니다. 죄송하지만, 이는 여러분을 보호하기 위해서입니다.
00:16:14집행은 전 재산을 걸어야 하는 부분이므로 반드시 결정론적이어야 합니다.
00:16:20하지만 판단은 뉘앙스를 더하는 부분이므로, 확률적인 요소를 넣을 수 있는 유일한 곳은 오직 그뿐입니다.
00:16:27그렇다면 에이전트를 위한 실제 규칙은 어떻게 만들어야 할까요?
00:16:34이것이 우리 워록 규칙 중 하나의 해부도이며, 모든 워록 규칙에는 네 가지 부품이 있습니다.
00:16:41첫 번째 부품은 메타데이터입니다.
00:16:43알기 쉬운 영어 설명, 심각도, 카테고리, 조치, 방향을 뜻합니다.
00:16:50첫 번째, 이것이 에이전트로 유입되는가?
00:16:52이것이 에이전트가 작성하고 있는 내용인가?
00:16:57그런 다음 문자열이 있습니다. 즉, 찾고자 하는 실제 패턴들입니다.
00:17:03그리고 세 번째는 조건입니다.
00:17:05즉, 규칙이 실제로 실행되도록 허용되는 시점입니다.
00:17:10이 예시를 하나씩 짚어보며 머릿속으로 작성하고 있다고 가정해 보겠습니다.
00:17:15프롬프트 인젝션은 마치 '이전 지시사항을 모두 무시하라' 같은 전형적인 예시입니다.
00:17:20여기서 여러분의 첫 번째 본능은 아마 '무시하다(ignore)'라는 단어를 차단하는 것이겠지만, 에이전트는 온종일 코드를 읽습니다.
00:17:27그리고 '무시하다'라는 표현은 코드 주석이나 예제에 언제든지 나타날 수 있죠.
00:17:31따라서 동사 단독으로 매칭하면 안 됩니다.
00:17:33동사에 지시사항 성격을 띤 명사를 조합하여 매칭해야 합니다.
00:17:38조건 부분에서는 해당 패턴 중 어느 하나라도 일치하면 실행하라고 지정합니다.
00:17:42그리고 메타데이터에서는 이것이 치명적인지, 카테고리가 무엇인지, 조치가 무엇인지 결정합니다.
00:17:50이 경우 조치는 차단이고, 방향은 에이전트로 유입되는 입력입니다.
00:17:56하지만 소음을 줄이는 좋은 규칙을 작성하려면 규칙과 함께 테스트도 함께 배포해야 합니다.
00:18:02즉, '이러한 패턴들은 매칭되어야 한다'는 테스트를 작성해야 합니다.
00:18:06그리고 '이러한 패턴들은 매칭되면 안 된다'는 테스트도요.
00:18:08그 네거티브 테스트가 가짜 양성에 대처하는 첫 번째 방어선입니다.
00:18:13하지만 규칙의 심각도를 결정할 때 명심해야 할 점이 있습니다.
00:18:19얼마나 무서워 보이는지가 아니라 실제 세계에 미치는 영향을 추적해야 한다는 것입니다.
00:18:24'RM -RF'는 무섭지만, 우리 모두가 하루에 40번씩 노드 모듈을 지울 때 쓰는 방식이기도 합니다.
00:18:31여러분이 구축하고 있는 에이전트에 대해 실제 세상에 미치는 영향이 무엇인지 직접 결정하세요.
00:18:37빌드 폴더를 정리하려고 시도할 때마다 충돌이 나는 보안 도구란
00:18:42결국 꺼버리게 되고 아무것도 잡아내지 못하는 도구일 뿐이니까요.
00:18:47그래서 자신 있게 말씀드리지만, 이것이 바로 우리의 현재 보안 태세입니다.
00:18:51마침내 이 자리에 서서 우리에게 진정한 다층 방어가 갖추어졌다고 말씀드릴 수 있게 되었습니다.
00:18:56저의 모든 배움이 이 결과물로 집약되었습니다.
00:19:00여전히 레이어 구조이지만, 이제 각 레이어는 자신이 잘하는 일을 제대로 해내고 있습니다.
00:19:04여전히 프롬프트를 사용하지만, 이는 오직 방향 설정용으로만 씁니다.
00:19:07모든 것은 샌드박스 안에서 실행됩니다.
00:19:09기본적으로 모두 거부(Deny by default)합니다.
00:19:11볼트를 두어 시크릿 정보가 모델에 절대 닿지 않도록 합니다.
00:19:14워록을 통해 들어오는 콘텐츠를 스캔하고,
00:19:17에이전트가 작성하는 출력도 스캔합니다.
00:19:20또한 트리아지를 통해 소음을 줄이며,
00:19:23프로세스 전체에 텔레메트리를 심어두어
00:19:26모든 것을 모니터링합니다.
00:19:28이 중 어떤 레이어도 혼자서 독립적으로 서 있지 않습니다.
00:19:31여기 있는 단 그 어떤 것도 혼자서는 여러분을 구해주지 못합니다.
00:19:33다만 그저 지루하고 정직한 레이어들이 있을 뿐이며,
00:19:36각각이 자신이 잘하는 한 가지 일을 해내고 있을 뿐입니다.
00:19:40그러므로 만약 여러분이 손이 달린 에이전트를 구축하고 있다면,
00:19:45이 전체 강연의 내용은 세 줄로 요약할 수 있습니다.
00:19:47첫째, 결정론적으로 집행되지 않는다면,
00:19:50그것은 집행된 것이 아닙니다.
00:19:52프롬프트는 보안 규칙이 아닙니다.
00:19:54보안 규칙인 것처럼 행동하게 만들지 마세요.
00:19:57둘째, 위험한 입력은 사용자가 타이핑하는 내용만이 아닙니다.
00:20:02실행을 허용한 명령어들만이 전부가 아닙니다.
00:20:04모델로 유입되는 모든 것이 위험 요소입니다.
00:20:06여러분이 직접 작성한 콘텐츠까지 포함해서요.
00:20:09따라서 원천 소스 단계에서 그리고 에이전트가 호출할 때
00:20:12자신의 공급망을 스캔하십시오.
00:20:15셋째, 공격은 복합적으로 일어나지만 코드 리뷰는 그렇지 않습니다.
00:20:18감사(Audit) 과정에서 발견된 대부분의 취약점은 두 가지 무해한 행동에서 비롯되었습니다.
00:20:22즉, 악수를 하는 것과 문을 열어주는 것이었죠.
00:20:25위저드, 워록, 그리고 컨텍스트 밀은 모두 오픈소스입니다.
00:20:29그러니 아래층으로 찾아와 주십시오.
00:20:32전시장 우리 부스에 있습니다.
00:20:34오시면 안내해 드리고 우리가 무엇을 만들었는지 보여드리겠습니다.
00:20:37그리고 여러분은 어떻게 에이전트를 보호하고 계신지 이야기를 듣고 싶습니다.
00:20:41감사합니다.
00:20:59감사합니다.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기