에이전트의 제어 관문은 에이전트가 아닌 환경에 있어야 합니다
요약
AI 에이전트의 안전성을 확보하기 위해 에이전트의 판단이 아닌 환경(DOM, 쿠키 등)에 제어 관문을 두어야 한다는 제안입니다. 에이전트가 영향 범위를 스스로 판단하게 하는 대신, 민감한 데이터나 동작을 시스템 수준에서 사전에 차단하는 구조적 접근을 강조합니다.
핵심 포인트
- 에이전트의 판단력에 의존하지 말고 환경(DOM, 세션)에서 제어 관문을 설정해야 함
- 안전성 기준은 '되돌릴 수 있는가'가 아닌 '영향 범위(blast radius)가 어디까지인가'여야 함
- 민감한 정보(자격 증명 등)는 모델에 도달하기 전 시스템 단계에서 필터링해야 함
- 모델의 판단은 안전의 최소 기준(floor)일 뿐, 제어 수준을 낮추는 용도로 쓰여선 안 됨
현재 Product Hunt에서는 AI 에이전트가 어디에서 멈추고 사람에게 결정을 다시 넘겨주어야 하는지에 대한 논의가 진행 중입니다. 제 머릿속에 남은 프레임워크는 다음과 같습니다: "이것을 되돌릴 수 있는가?"라는 질문은 잘못된 관문(gate)입니다. 이 질문은 로그 라인(log line)을 작성하는 것과 같이 아무도 신경 쓰지 않는 일에는 과하게 반응하고, 실제로 피해를 줄 수 있는 일에는 제대로 반응하지 못합니다. 대량 이메일 발송이나, 다운타임(downtime)을 통해서만 롤백(roll back)할 수 있는 마이그레이션(migration) 같은 일 말입니다.
제안된 대체 기준은 영향 범위(reach)입니다. "이것이 안전한가"가 아니라 "내가 틀렸을 때 이 일이 어디까지 미치는가"입니다. 그리고 해당 스레드에서 가장 날카로운 지점은, 에이전트가 자신의 영향 범위를 판단하기에 최악의 심판이라는 점입니다. 왜냐하면 에이전트는 리스트에 50,000명의 사람이 있다는 사실을 알지 못하기 때문입니다.
저는 에이전트가 포함된 브라우저를 구축해 왔으며, 브라우저 사례는 터미널(terminal) 사례가 그렇지 못한 방식으로 이를 구체화합니다.
코딩 에이전트의 폭발 반경(blast radius)은 보통 한 사람, 즉 diff를 읽고 있는 당신입니다. 브라우저 에이전트는 거기서 시작하지 않습니다. 에이전트는 당신이 이미 로그인되어 있는 모든 세션을 상속받습니다. 클릭 한 번의 영향 범위는 에이전트 계획의 속성이 아니라, 에이전트가 들고 있는 쿠키 저장소(cookie jar)의 속성입니다. 똑같은 "파란 버튼을 클릭하세요"라는 단계라도 문서 사이트에서는 무해하지만, 결제 대시보드(payments dashboard)에서는 되돌릴 수 없으며, 에이전트 자체의 요약 내용 중 그 무엇도 이 둘을 구분하지 못합니다.
그래서 저는 에이전트가 위험을 분류하도록 만드는 시도를 중단했습니다. 대신 제가 하고 있는 방식은 다음과 같습니다. 다만 이것은 알파(alpha) 단계이며, 저 또한 이전에 틀린 적이 있다는 점을 유의하십시오.
어떤 것들은 모델에 절대 도달하지 않습니다. 에이전트가 페이지 스냅샷을 보기 전에 자격 증명(credential) 필드는 필터링되어 제거됩니다. 이는 비밀번호 입력창과 cc-number, cc-csc, cc-exp 또는 one-time-code 자동 완성 의미론(semantics)을 가진 모든 것을 의미합니다. 비밀번호 필드를 대상으로 하는 채우기(fill)는 즉시 거부됩니다. 에이전트는 자신에게 보여주지도 않은 컨트롤의 영향 범위를 잘못 판단할 수 없습니다. 그리고 이것은 판단을 올바르게 내리는 것에 의존하지 않기 때문에, 그 어떤 분류기(classifier)보다 더 강력한 보증이 됩니다.
모델의 판단은 바닥(floor)일 뿐, 결코 천장(ceiling)이 될 수 없습니다. 모델의 판단에 도달하는 모든 사항에 대해, 에이전트는 "이것은 승인이 필요합니다"라고 말할 수 있으며 그 말은 신뢰받을 수 있습니다. 하지만 에이전트가 "이것은 일상적인 작업입니다"라고 말했을 때 그것이 신뢰받을 수는 없습니다. 구조적으로 민감한 제어(control)는 모델이 해당 동작을 평범하다고 판단하더라도 여전히 네이티브 확인(native confirmation) 단계로 격상됩니다. 에이전트는 관문(gate)을 높일 수는 있지만, 낮출 수는 없습니다.
민감도(Sensitivity)는 계획(plan)이 아니라 DOM에서 읽어옵니다. 제어가 민감한지를 결정하는 것은 그 유형과 자동 완성(autocomplete) 의미론(semantics)이며, 이는 에이전트가 수행할 작업의 의미를 설명하는 방식이 아니라 페이지 자체에 존재하는 증거입니다.
타임아웃(timeout)은 대기가 아니라 거부(denial)입니다. 중단된 작업은 조용한 실패(silent failure)이지만, 거부된 작업은 명시적인 실패이며, 명시적인 실패는 수정됩니다.
제가 아직 해결하지 못한 부분은 '거부 후 재개 가능(denied-and-resumable)' 문제입니다. 작업을 폐기하는 것은 깔끔하지만 무용지물입니다. 왜냐하면 사람들은 20분 후에 다시 돌아와 작업을 계속하기를 원하기 때문입니다. 하지만 이는 질문이 던져졌을 당시의 상태로 세상을 저장해야 함을 의미하며, 그사이 세상은 변해버립니다. 특히 가혹한 환경인 브라우저에서는, 당신이 질문했던 DOM이 더 이상 존재하지 않을 수도 있습니다. 이에 대해 아직은 명확한 답을 가지고 있지 않습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기