현장에서 에이전트 PoC를 보면 처음에는 모두 프롬프트를 고친다. 답이 틀리면 지시문을 늘리고, 실행이 불안하면 모델을 바꾼다. 그러나 운영 직전의 진짜 질문은 따로 나온다. “이 에이전트가 어디까지 해도 되는가.” 이 질문에 답하지 못한 에이전트는 업무 보조가 아니라 권한이 열린 실행기다.
최근 12개월의 공식 문서도 같은 방향으로 움직인다. OpenAI는 2026년 Agents SDK에서 controlled workspace와 sandbox execution을 전면에 놓았다. Claude Code는 settings의 allow, ask, deny와 hooks를 통해 실행 전후 통제를 문서화했다. MCP 2025-11-25 authorization 규격은 HTTP 기반 연결에서 OAuth 2.1, scope, resource binding을 요구한다. 방향은 분명하다. 에이전트 설계의 중심은 더 똑똑한 답변이 아니라 더 좁고 명확한 권한이다.
퍼미션은 보안팀 문서가 아니라 제품 사양이다
에이전트는 UI가 아니다. 사용자의 말을 받아 시스템을 움직이는 실행 주체다. 그래서 “승인 화면을 하나 붙이자”는 식의 통제는 늦다. 승인 화면은 마지막 방어선이지 설계 원칙이 아니다.
퍼미션 경계는 제품 요구사항에 들어가야 한다. 어떤 업무 목적에서, 어떤 도구를, 어떤 데이터 범위로, 어떤 비용 한도 안에서, 누구의 책임으로 실행하는지 먼저 정한다. 그 다음에 모델과 프롬프트를 고른다.
에이전트의 자율성은 모델 능력이 아니라 사전에 잘라낸 권한의 모양으로 결정된다.
운영 실패는 대부분 여기서 갈린다. “조회만 하는 에이전트”라고 말하면서 실제로는 파일 다운로드, 외부 전송, 결재 초안 작성, 티켓 상태 변경 도구를 한꺼번에 열어둔다. 이름은 조회지만 권한은 실행이다. 시스템은 이름을 보지 않는다. 토큰과 API scope를 본다.
도구·데이터·예산을 따로 보면 경계가 샌다
권한표를 도구 목록으로만 만들면 사고가 난다. 같은 검색 도구라도 공개 문서만 읽는 경우와 고객 식별정보를 읽는 경우는 전혀 다르다. 같은 결제 도구라도 견적 조회와 구매 확정은 다른 행위다. 예산이 빠진 퍼미션은 구매·API 호출·토큰 사용량이 얽히는 순간 무너진다.
| 통제면 | 잘못된 설계 | 운영 설계 |
|---|---|---|
| 도구 | “CRM 사용 가능” | 고객 조회, 메모 작성, 상태 변경을 분리 |
| 데이터 | “권한 있는 사용자 데이터 사용” | 필드·기간·고객군·마스킹 기준을 명시 |
| 예산 | “필요 시 실행” | 호출 단가, 누적 한도, 초과 시 중단 규칙 설정 |
| 승인 | “중요하면 사람 확인” | 실행 전 ask, 실행 후 audit, 재시도 조건 분리 |
OpenAI Agents SDK의 function tool은 needsApproval, inputGuardrails, outputGuardrails, timeoutMs 같은 통제 지점을 제공한다. Claude Code settings는 permissions.allow, permissions.ask, permissions.deny로 민감 파일과 명령을 다룬다. Google의 AP2는 결제 맥락에서 Intent Mandate와 Cart Mandate로 “무엇을 찾는 권한”과 “무엇을 사는 권한”을 나눈다. 이 세 흐름의 공통점은 하나다. 실행 권한을 자연어 약속에 맡기지 않는다.
하네스가 없으면 프롬프트는 통제가 아니다
프롬프트에 “민감정보를 보지 마라”, “비용을 아껴라”, “승인 없이 실행하지 마라”라고 쓰는 조직을 자주 본다. 그 문장은 정책 설명이다. 통제 장치가 아니다.
운영 에이전트에는 하네스가 필요하다. 여기서 하네스는 모델 밖에서 도구 호출, 컨텍스트 주입, 메모리 접근, 예산 차감, 승인, 로그를 묶는 실행 구조다. Claude Code hooks가 PreToolUse, PostToolUse, SubagentStart 같은 이벤트를 제공하는 이유도 여기에 있다. MCP authorization이 scope challenge와 insufficient scope 처리를 다루는 이유도 같다. 실행 중 권한이 부족하면 모델이 우회하는 것이 아니라 시스템이 멈추고 재승인을 요구해야 한다.
AX Ops에서는 퍼미션 경계를 세 겹으로 둔다.
- 정적 경계: 역할별 tool allowlist, 데이터 denylist, 환경 격리.
- 동적 경계: 요청 내용, 고객 등급, 금액, 외부 전송 여부에 따른 ask.
- 사후 경계: tool call 로그, 비용 로그, 승인자, 결과물 해시를 남기는 audit.
이 구조가 있어야 에이전트가 실패해도 실패 반경이 작아진다. 실패 반경이 작아야 운영 배포가 가능하다.
참고
- OpenAI, “The next evolution of the Agents SDK”, 2026: https://openai.com/index/the-next-evolution-of-the-agents-sdk/
- OpenAI Agents SDK JS Tools Guide, 2026 문서 기준: https://openai.github.io/openai-agents-js/guides/tools/
- Anthropic Claude Code Settings, 2026 문서 기준: https://code.claude.com/docs/en/settings
- Anthropic Claude Code Hooks Reference, 2026 문서 기준: https://code.claude.com/docs/en/hooks
- Model Context Protocol Authorization, Version 2025-11-25: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
- Google Cloud, “Announcing Agent Payments Protocol”, 2025: https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol
권한표를 운영표로 바꿔야 한다
에이전트 퍼미션 설계의 목적은 에이전트를 묶어두는 것이 아니다. 반대로 안전하게 더 많은 일을 맡기기 위해 권한을 잘게 자르는 일이다. 도구, 데이터, 예산을 한 장의 운영표로 묶고, 실행 전 승인과 실행 후 감사를 같은 흐름에 넣어야 한다.
AX는 모델 사용량 확대가 아니다. 조직이 에이전트에게 일을 맡길 수 있는 운영 경계를 만드는 일이다. 그 경계 설계부터 시작하려면 AX Ops 방법론 →