권한 승인 프롬프트는 에이전트 보안 전략이 아닙니다

Docker는 지난주 AI 에이전트(AI agents)를 보안하는 방법에 대한 실용적인 가이드를 발표했습니다. 그리고 그 가이드에 담긴 문장 중 하나는 코딩 에이전트(coding agents)를 도입하는 모든 엔지니어링 팀의 스티커로 제작되어 붙어 있어야 할 정도입니다.

권한 승인 프롬프트(Permission prompts)는 보안 전략이 아닙니다.

물론 이것이 가이드의 전부는 아닙니다. Docker는 격리(isolation), 도구 액세스(tool access), 신원(identity), 자격 증명(credentials), 런타임 모니터링(runtime monitoring), MCP 출처(MCP provenance), 그리고 멀티 에이전트 신뢰 경계(multi-agent trust boundaries)에 대해 이야기합니다. 좋습니다. 그것들은 성숙한 주제들입니다.

하지만 권한 승인 프롬프트에 관한 문장은 제 머릿속에 계속 남았습니다. 왜냐하면 에이전트 제품과 내부 데모에서 계속해서 목격하게 되는 습관을 지적하고 있기 때문입니다.

기술적으로 인간이 루프 안에(in the loop) 있기 때문에 이것이 안전하다고 느껴집니다. 또한 개발자들이 이미 하루 종일 브라우저 권한, OAuth 범위(scopes), 패키지 설치, CI 재실행, 배포 버튼, 클라우드 콘솔 경고, 그리고 가끔씩 마주하는 끔찍한 Terraform 계획(Terraform plan) 등을 승인하고 있기 때문에 익숙하게 느껴지기도 합니다.

문제는 프롬프트가 대개 경계(boundary)가 아니라 속도 제한턱(speed bump)에 불과하다는 점입니다.

프롬프트는 사람들에게 '예'를 클릭하도록 훈련시킵니다

지속적인 인간의 주의력에 의존하는 보안 제어(Security controls)는 결국 보여주기식 행위(theater)로 전락하는 경향이 있습니다.

개발자들이 부주의해서가 아닙니다. 워크플로(workflow) 자체가 승인이 곧 진행을 위한 대가라는 것을 가르치기 때문입니다.

만약 에이전트가 코딩 작업 중에 스무 번이나 권한을 요청한다면, 첫 번째 프롬프트는 정말 면밀히 검토될 것입니다. 두 번째는 여전히 훑어보겠죠. 열 번째쯤 되면 개발자는 해당 동작이 작업과 대략적으로 일치하는지만 확인합니다. 스무 번째가 되면 개발자는 승인을 클릭하게 됩니다. 왜냐하면 그 대안은 시간을 아껴주기로 되어 있는 기계를 일일이 감시(babysitting)하는 것이기 때문입니다.

이것은 성격 결함이 아닙니다. 인터페이스 디자인(interface design)의 문제입니다.

에이전트는 이 상황을 악화시키는데, 그 이유는 시퀀스(sequence)가 동적(dynamic)이기 때문입니다. 코딩 에이전트는 파일을 검사하고, 패키지를 설치하고, 테스트를 실행하고, 마이그레이션(migrations)을 생성하고, MCP 서버를 호출하고, 문서를 열고, 실패 후 재시도해야 할 수도 있습니다. 각 단계는 개별적으로는 합리적일 수 있습니다. 위험한 것은 그 사슬(chain)입니다.

한 번에 하나의 명령을 승인한다고 해서 전체 워크플로 (workflow)가 안전하다는 의미는 아닙니다. 그것은 단지 위험이 충분히 작은 조각으로 잘게 쪼개져서, 각 조각이 수용 가능한 것처럼 보일 뿐입니다.

에이전트에게 필요한 것은 보호자가 아니라 샌드박스 (sandbox)입니다

더 나은 모델은 에이전트에게 일회성 경계 (disposable boundary) 내부에서의 자율성을 부여하는 것입니다.

그 경계는 컨테이너 (container), 마이크로 VM (microVM), 원격 개발 환경 (remote development environment), 또는 다른 종류의 샌드박스 (sandbox)가 될 수 있습니다. 구현 방식도 중요하지만, 그 형태가 더 중요합니다. 에이전트가 유용한 작업을 수행할 수 있는 충분한 공간을 확보하면서도, 호스트 머신 (host machine)이 폭발 반경 (blast radius)의 일부가 되지 않도록 해야 합니다.

이것이 제가 에이전트를 위한 프레임워크로 컨테이너 (container) 방식을 선호하는 이유입니다. 컨테이너가 마법 같은 보안 가루이기 때문이 아닙니다. 그렇지 않습니다. 하지만 컨테이너는 더 나은 질문을 강제하기 때문입니다. 에이전트가 어떤 파일 시스템 (filesystem)을 볼 수 있는지, 어떤 네트워크 (network)에 접속할 수 있는지, 어떤 자격 증명 (credentials)이 존재하는지, 그리고 환경이 파괴되었을 때 어떤 일이 발생하는지 말입니다.

프롬프트 (prompt)는 지친 인간에게 국지적인 판단을 내리도록 요구합니다. 반면 샌드박스 (sandbox)는 위험한 기본 설정 (default)을 불가능하게 만들거나, 적어도 그 위험을 격리합니다.

에이전트가 테스트를 실행하거나 패키지를 설치해야 한다면 좋습니다. 하지만 에이전트가 아무렇지 않게 ~/.ssh를 읽거나, 관련 없는 리포지토리 (repository)를 긁어모으거나, 임의의 도메인으로 홈을 호출(phone home)하거나, 혹은 쉘 (shell)에 우연히 남아 있던 토큰 때문에 개발자의 전체 클라우드 ID (cloud identity)를 상속받을 수 없는 환경에서 수행해야 합니다.

이것이 위험한 프로세스를 감독하는 것과, 위험한 프로세스가 파괴할 수 있는 범위를 줄이도록 시스템을 설계하는 것의 차이입니다.

도구 접근 (tool access)이 진정한 권한 시스템입니다

다음 약점은 도구 접근 (tool access)입니다.

대부분의 에이전트 데모는 도구를 '기능적인 사탕'처럼 취급합니다. GitHub, Slack, Jira, 문서, 데이터베이스, 배포 시스템, 브라우저, 그리고 누군가 지난달에 작성한 내부 MCP 서버를 추가합니다. 그러면 에이전트는 더 유용해지고, 데모는 더 좋아지며, 신뢰 경계 (trust boundary)는 조용히 확장됩니다.

이 지점이 권한 프롬프트 (permission prompts)가 특히 오해를 불러일으키는 부분입니다.

중요한 질문은 에이전트가 도구를 사용하기 전에 요청했느냐가 아닙니다. 그 도구가 이 작업에 애초에 사용 가능했어야 했느냐 하는 것입니다.

프론트엔드 리팩토링 에이전트 (frontend refactor agent)에게 프로덕션 데이터베이스 (production database) 접근 권한이 필요하지는 않습니다. 의존성 업데이트 에이전트 (dependency update agent)에게 고객 상담 기록 (customer transcripts)이 필요하지는 않습니다. 문서 요약기 (docs summarizer)에게 배포 권한 (deploy permissions)이 필요하지는 않습니다. 로컬 코딩 어시스턴트 (local coding assistant)는 아마도 프라이빗 코드 (private code)를 읽는 동안 임의의 인터넷 접근 권한 (arbitrary internet access)이 필요하지 않을 것입니다.

팀들이 도구 (tools)를 연결하는 방식을 살펴보면 이것이 당연하게 들리다가도 의구심이 생깁니다. 가장 쉬운 통합 모델은 "에이전트에게 모든 것을 주고 모델이 현명하게 선택하도록 맡기는 것"입니다. 그것은 권한 모델 (permission model)이 아닙니다. 그것은 JSON 스키마 (JSON schemas)를 이용한 희망 사항일 뿐입니다.

도구 접근 권한은 작업 (task), 환경 (environment), 저장소 (repository), 데이터 분류 (data classification), 그리고 신원 (identity)에 따라 범위가 지정되어야 (scoped) 합니다. 이상적으로는, 모든 에이전트 런타임 (agent runtime)이 각자 규칙을 만들어내도록 방치하는 대신, 게이트웨이 (gateway)가 해당 정책을 일관되게 강제해야 합니다.

MCP는 이를 완화하는 것이 아니라 더욱 시급하게 만듭니다. MCP는 에이전트가 도구에 연결하는 방식을 표준화하며, 이는 도구 설명 (tool descriptions), 서버 출처 (server provenance), 그리고 도구 동작 (tool behavior)이 보안 표면 (security surface)의 일부가 된다는 것을 의미합니다. 악의적이거나 부주의한 도구는 단순히 나쁜 코드가 아닙니다. 그것은 에이전트가 신뢰할 수 있는 명령 소스 (instruction source)입니다.

만약 당신이 프로덕션 조직 전체에 출처를 알 수 없는 GitHub 앱 (GitHub App)을 설치하지 않겠다면, 그와 맞먹는 MCP 서버를 모든 코딩 에이전트에게 아무렇지 않게 넘겨주지 마십시오.

에이전트에게는 고유한 신원이 필요합니다

에이전트 보안을 관리 불가능하게 만드는 가장 빠른 방법 중 하나는 에이전트를 개발자의 권한으로 실행하는 것입니다. 이는 편리합니다. 하지만 감사 (audit) 측면에서는 최악의 결과를 초래합니다.

만약 에이전트가 나의 토큰 (token)을 사용한다면, 모든 작업은 내가 수행한 것처럼 보입니다. 에이전트가 브랜치 (branch)를 푸시하거나, API를 호출하거나, 문서를 읽거나, 티켓 (ticket)을 생성하거나, 인프라 (infrastructure)를 건드린다면, 시스템은 Paulo가 이 작업을 수행했다고 기록합니다. 내가 에이전트에게 요청했을 수도 있습니다. 프롬프트 인젝션 (prompt injection)이 에이전트를 유도했을 수도 있습니다. 도구 설명 (tool description)이 오염되었을 수도 있습니다. 로그는 이를 알 수 없습니다.

서비스 계정 (Service accounts)이 존재하는 이유는 우리가 이미 이 교훈을 배웠기 때문입니다. 자동화된 시스템에는 범위가 지정되고, 감사가 가능하며, 취소가 가능하고, 이해할 수 있는 신원 (identities)이 필요합니다. 에이전트는 자동화된 시스템입니다. 에이전트 또한 자신만의 고유한 신원을 가져야 합니다.

모든 권한을 가진 단 하나의 보편적인 "ai-agent" 계정을 사용하는 것이 아닙니다. 목적이 분명한 실제 신원 (identities)이 필요합니다: 이 리포지토리 마이그레이션 에이전트, 이 인시던트 분류 (incident triage) 에이전트, 이 문서화 에이전트와 같이 말입니다. 각 에이전트는 해당 작업을 수행하는 데 필요한 최소한의 유용한 액세스 권한 (minimum useful access)만을 가져야 하며, 명확한 소유자가 있어야 합니다.

수명이 짧은 자격 증명 (short-lived credentials)이 도움이 됩니다. 런타임 비밀값 주입 (runtime secret injection)도 도움이 됩니다. 인간의 요청, 에이전트 신원, 도구 호출 (tool call), 그리고 결과를 연결하는 로그는 훨씬 더 큰 도움이 됩니다.

핵심은 책임 (accountability)에서 인간을 배제하는 것이 아닙니다. 핵심은 기계 행위자 (machine actor)를 충분히 가시화하여 책임이라는 것이 의미를 갖게 만드는 것입니다.

내가 실제로 할 일

만약 한 팀이 코딩 에이전트 (coding agents) 보안을 어떻게 시작해야 할지 묻는다면, 저는 거대한 AI 거버넌스 위원회부터 만들라고 하지 않을 것입니다. 대신 네 가지 기본 원칙 (defaults)부터 시작할 것입니다.

첫째, 에이전트는 일회용 환경 (disposable environments)에서 실행됩니다. 특별한 이유가 없는 한 호스트에 직접 접근할 수 없습니다. 로컬 비밀값 (local secrets)이 실수로 상속되는 일도 없어야 합니다.

둘째, 네트워크 액세스는 기본적으로 거부되며, 작업별로 허용 목록 (allowlist)에 등록됩니다. 패키지 레지스트리, 문서, 그리고 내부 API는 명시적이어야 합니다.

셋째, 도구는 워크플로 (workflow)별로 부여됩니다. 언젠가 유용할지도 모른다는 이유로 모든 MCP 서버를 미리 로드해 두지 마십시오. "언젠가 유용할 것"이라는 생각이 바로 액세스 확산 (access sprawl)이 정상적인 현상이 되는 방식입니다.

넷째, 주의 깊게 살펴볼 가치가 있는 모든 에이전트 작업은 나중에 설명할 수 있을 만큼 충분한 컨텍스트 (context)와 함께 로그로 기록됩니다: 도구, 파라미터 (parameters), 신원, 정책 (policy), 결과. 이는 감사관 (auditors)들이 즐거워서가 아니라, 운영 시스템 (production systems)은 증거를 가질 자격이 있기 때문입니다. 프롬프트 (prompts)는 사고 발생 후 그런 기억을 제공해 줄 수 없습니다.

권한 승인 프롬프트 (permission prompts)는 여전히 존재할 수 있습니다. 때로는 유용합니다. 파일을 삭제하기 전의 프롬프트는 괜찮습니다. 돈을 쓰기 전의 프롬프트도 괜찮습니다. 브랜치를 푸시 (push)하기 전의 프롬프트도 괜찮습니다.

하지만 프롬프트는 비정상적인 행동에 대한 마지막 단계의 확인 (last-mile confirmation)이어야 하며, 에이전트와 나머지 환경 사이를 가로막는 주요 벽이 되어서는 안 됩니다.

결론 (the punchline)

에이전트가 유용해지고 있는 이유는 모든 사소한 단계마다 우리에게 묻지 않고 행동할 수 있기 때문입니다.

그것이 바로 "그냥 인간에게 물어보세요"가 매우 취약한 보안 모델인 이유이기도 합니다.

만약 에이전트가 모든 행동마다 보호자(chaperone)를 필요로 한다면, 그것은 워크플로(workflow)를 수행할 만큼 충분히 자율적이지 않은 것입니다. 만약 에이전트가 자율적으로 행동할 수 있다면, 보안 모델은 환경 내에 존재해야 합니다: 샌드박싱 (sandboxing), 범위가 제한된 도구 (scoped tools), 전용 ID (dedicated identities), 네트워크 정책 (network policy), 자격 증명 위생 (credential hygiene), 그리고 로그 (logs)와 같은 것들 말입니다.

업계는 오래된 시스템의 교훈을 천천히 재발견하고 있습니다. 모든 운영자가 중단 상황 속에서도 완벽한 결정을 내리기를 기대함으로써 위험한 작업을 보호할 수는 없습니다. 작업이 일어나는 공간(the room)을 형성함으로써 작업을 보호해야 합니다.

그러니 네, 이상한 명령에 대해서는 프롬프트를 유지하세요.

하지만 경계(boundary)를 먼저 구축하십시오.

references

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.