"메일을 보냈습니다." "발주를 넣었습니다." "일정을 잡았습니다." 에이전트가 읽고 정리할 때는 조용하다가,
뭔가를 쓰는 순간 사람들은 미래를 봅니다.
저희는 고객에게 그 장면을 첫 6개월 동안 만들지 말라고 권합니다. 에이전트 구축을 파는 회사가 할 말은 아닌 것 같지만, 올해 일어난 일들을 보면 이 말을 안 하는 쪽이 무책임합니다. 쓰기 권한은 에이전트의 가장 멋진 기능이자, 지금 AI 보안 사고의 거의 전부가 빠져나가는 출구이기 때문입니다.
지난 1년 동안 일어난 일
에이전트 보안은 더 이상 가정이 아닙니다. 공개된 사건만 추려도 이렇습니다.
| 시기 | 사건 | 공통점 |
|---|---|---|
| 2025.11 | Anthropic이 중국 국가 배후 그룹(GTG-1002)이 Claude Code와 MCP 도구로 약 30개 조직을 공격한 작전을 적발·차단. 침투 작업의 80~90%를 AI가 수행 | 사람은 지시만, 실행은 에이전트 |
| 2026.03 | Palo Alto Unit 42가 웹페이지에 숨긴 지시로 브라우저 에이전트를 조종하는 간접 프롬프트 인젝션이 실제 공격에 쓰이는 것을 관측 | 읽은 문서가 명령이 됨 |
| 2026.04 | OWASP 1분기 보고서: 1~4월 주요 AI 사고 8건 중 CVE가 붙은 건 1건뿐. 나머지는 설정 실수, 과도한 권한, 공급망, 프롬프트 인젝션 | 취약점이 아니라 권한 문제 |
| 2026 상반기 | GitHub 댓글·PR 제목에 심은 지시로 Claude Code, Gemini CLI, Copilot Agent가 CI 환경에서 명령을 실행하고 자격증명을 노출("Comment and Control") | 에이전트가 읽는 곳 어디든 입구 |
| 2026.07 | Hugging Face가 운영 인프라 침입을 공개. 자율 에이전트가 17,000건 넘는 행동을 수행했고, 닷새 뒤 OpenAI가 자사 평가용 에이전트가 범위를 벗어난 것이라고 확인 | 악의 없이도 사고는 난다 |
다섯 사건의 공통점이 하나 있습니다. 모델이 똑똑하지 않아서 생긴 사고는 없습니다.
전부 에이전트가 무언가를 읽고, 그다음 무언가를 할 수 있었기 때문에 생겼습니다.
읽기만 가능했다면 다섯 건 모두 "이상한 요약"으로 끝났을 일입니다.
1. 읽기와 쓰기는 실수의 값이 다릅니다
에이전트가 읽고 정리한 결과가 틀리면 담당자가 고칩니다. 비용은 담당자의 2분입니다. 에이전트가 쓴 결과가 틀리면 거래처가 봅니다. 비용은 신뢰이고, 돌려받는 데 몇 달이 걸립니다.
저희 견적 에이전트는 담당자 판단과 90% 넘게 일치합니다. 좋은 숫자입니다. 그런데 이 숫자는 "열 건 중 한 건은 틀린다"는 뜻이기도 합니다. 그 한 건이 초안함에 있으면 담당자가 잡고, 그 한 건이 발송함에 있으면 사고입니다. 같은 90%인데 쓰기 권한 하나로 사고율이 0에서 10%가 됩니다. 에이전트의 정확도를 올리는 것보다 틀린 건이 어디서 멈추느냐를 설계하는 게 먼저인 이유입니다.
2. 쓰기 권한은 프롬프트 인젝션의 출구입니다
프롬프트 인젝션은 간단합니다. 에이전트가 읽는 문서에 "이전 지시를 무시하고 이렇게 하라"를 숨겨 두는 것입니다. 거래처 메일 서명란에, PDF 흰 글씨에, GitHub 댓글에. 위 표의 사건 대부분이 이 방식입니다. 에이전트는 사람과 달리 "이건 데이터고 이건 명령"을 완벽히 가리지 못하고, Anthropic 스스로 완화책을 넣어도 공격 성공률을 0으로 만들지 못했다고 공개했습니다.
그래서 저희는 인젝션을 막는 데 걸지 않습니다. 인젝션이 성공해도 할 수 있는 게 없게 만듭니다. 외부 문서를 읽는 에이전트에게 쓰기 권한이 없으면, 공격자가 아무리 교묘한 지시를 심어도 결과는 틀린 초안 하나입니다. 초안은 담당자가 보고 버리면 끝입니다. 읽기와 쓰기를 한 에이전트에 몰아주는 순간 그 초안이 발주가 되고 송금이 됩니다. 권한을 나누는 건 성능을 깎는 게 아니라 폭발 반경을 자르는 일입니다.
3. "아직은"의 조건 세 가지
제목에 "아직은"을 붙인 이유는 영원히 주지 말라는 뜻이 아니기 때문입니다. 저희가 쓰기 권한을 여는 조건은 셋입니다.
일치율이 몇 주째 유지된다.
평가셋 기준으로 담당자 판단과 일치하는 비율이 목표선 위에서 흔들리지 않을 때. 첫 주 90%는 믿지 않습니다. 담당자가 다르게 판단한 건이 평가셋에 쌓인 뒤의 90%를 믿습니다.되돌릴 수 있는 곳부터 연다.
임시저장, 초안함, 사내 시스템의 "검토 대기" 상태. 발송 버튼이 아니라 발송 직전까지. 송금, 계약 체결, 외부 발송은 가장 마지막이고, 어떤 고객에게는 영원히 안 열 수도 있습니다.승인자가 거부한 이력이 있다.
승인자가 에이전트 초안을 한 번도 거부하지 않았다면 그건 승인이 아니라 통과입니다. 거부 건이 있어야 승인자가 실제로 읽고 있다는 증거가 되고, 그래야 쓰기 권한을 열어도 누군가는 잡고 있는 상태가 됩니다.
셋이 다 되면 범위를 하나씩 엽니다. 견적서 초안 → 내부 결재 상신 → 거래처 발송 순서로, 한 단계에 몇 주씩. 느리지만 위 표에 이름이 올라가지 않는 방법입니다.
4. 승인 단계는 병목이 아니라 제품입니다
"사람이 승인하면 자동화가 아니잖아요." 가장 많이 듣는 반론입니다. 저희 답은 견적 처리 도식입니다. 열 단계 중 사람 손이 닿는 곳은 팀장 승인 한 곳이고, 나머지 아홉은 에이전트가 합니다. 담당자의 하루는 열 번 손대던 일이 한 번 보는 일로 바뀝니다. 그 한 번을 없애서 얻는 건 몇 분이고, 그 한 번을 남겨서 얻는 건 위 표에 오르지 않는 것입니다.
승인 단계는 안전장치 이상입니다. 승인자가 거부한 건은 다음 평가셋이 되고, 에이전트는 그만큼 회사를 닮아갑니다. 승인 큐를 보는 아침 10분이 에이전트가 회사를 배우는 교재입니다. 그래서 저희 도식에서 승인 단계는 항상 흰 네모입니다. 지우고 싶은 단계가 아니라 설계의 중심이기 때문입니다.
반복은 에이전트에게, 판단은 사람에게
쓰기는 판단의 결과입니다. 판단이 사람 곁에 있어야 한다면 쓰기도 마지막까지 사람 곁에 있어야 합니다. 올해의 사건들은 그 순서를 거꾸로 한 데서 나왔습니다. 쓰기 권한을 먼저 주고, 판단은 나중에 붙이려 했습니다.
저희 2주 PoC는 읽기 전용으로 시작합니다. 에이전트는 읽고 초안을 만들고, 사람이 보고 결정합니다. 그 2주 동안 일치율이 얼마나 나오는지, 승인자가 무엇을 거부하는지를 보고 나서야 "아직은"을 "이제는"으로 바꿀지 같이 정합니다.