기업 관리형 권한 부여(EMA)는 토대가 아닌 천장이다: 연결된 에이전트에게 작업별 권한 부여(Per-Action Authorization)가

요약 (TL;DR)

• 기업 관리형 권한 부여 (Enterprise-Managed Authorization, EMA)는 액세스 프로비저닝을 중앙 집중화하고 서버별 동의 프롬프트를 제거합니다. 이는 연결 시점의 거버넌스(connection-time governance)를 위한 올바른 솔루션입니다. 하지만 EMA는 각 개별 도구 호출(tool call)을 승인하도록 설계되지 않았으며, 그 기능 또한 수행하지 않습니다.
• AI 워크플로우는 프롬프트 인젝션 (prompt injection)의 피해 범위(blast radius)를 제한하기 위해 작업별 권한 부여 (per-action authorization)가 필요합니다. 공격은 "이 에이전트는 연결이 허용됨"과 "이 특정 작업이 지금 바로 실행되어야 함" 사이의 간극을 악용하기 때문입니다.
• 보안 권한 부여 계층은 작업이 실행되기 직전에 조직 정책, 사용자 위임 (user delegation), 그리고 에이전트 역량 경계 (agent capability boundaries)의 교차점을 반드시 평가해야 합니다.
• 프로덕션급 배포에서는 대규모 언어 모델 (Large Language Models, LLM)이 원시 인증 토큰 (raw authentication tokens)에 직접 접근하지 못하도록 보장하기 위해 실행 전 인터셉터 (pre-execution interceptor)와 자격 증명 격리 (credential isolation)를 사용합니다.
• 고위험 프로덕션 배포에는 EMA를 포함한 기존 기업 ID 인프라를 교체하지 않으면서, 자체 구축하거나 Arcade와 같은 작업 런타임 (action runtime)을 통해 구현된 작업 수준의 런타임 강제 적용 (action-level runtime enforcement)이 필요합니다.

기업 관리형 권한 부여 (EMA)가 MCP를 위해 해결하는 문제

기업 관리형 권한 부여 (Enterprise-Managed Authorization)가 이제 안정화되었습니다. Anthropic, Microsoft, Okta 및 점점 늘어나는 수의 MCP 서버들이 채택한 이 확장 기능은 기업의 MCP 도입을 늦췄던 서버별 OAuth 동의 비용 문제를 해결합니다.

EMA 이전에는 모든 직원이 모든 MCP 서버를 개별적으로 승인해야 했습니다. 보안 팀은 중앙 집중식 제어 권한이 없었습니다. 업무용 계정과 개인용 계정이 뒤섞였습니다. EMA는 조직의 ID 제공업체 (IdP)를 MCP 서버 액세스에 대한 권위 있는 결정권자로 만듦으로써 이 모든 문제를 제거합니다. 관리자는 정책을 한 번만 정의하면 됩니다. 사용자는 싱글 사인온 (Single Sign-On, SSO)을 통해 인증하며, 자신의 역할이 허용하는 모든 서버를 상속받습니다. 앱별 OAuth나 일회성 설정은 필요하지 않습니다.

내부적으로는 SSO 기반 권한 부여 흐름의 일부로서, 클라이언트는 신원 주장 (Identity Assertion)을 획득하고 이를 사용하여 Identity Assertion JWT Authorization Grant (ID-JAG)를 요청하며, 이를 각 MCP 서버의 권한 부여 서버로부터 액세스 토큰 (Access Tokens)으로 교환합니다. 여기에는 세 가지 특성이 따릅니다: 한 번의 권한 부여로 어디서든 상속, 액세스 결정에 대한 중앙 집중식 정책 및 감사, 그리고 개인/기업 계정 혼동의 제거입니다.

이는 가치 있는 인프라입니다. 하지만 설계상 이는 권한 부여 시점 (Grant-time)의 결정입니다. EMA의 IdP는 토큰이 발행될 때 정책을 평가하며 (갱신 시 재평가할 수 있음), 표준화된 권한 부여 가시성은 개별 도구 호출 (Tool Calls)까지 확장되지 않습니다. EMA는 _누가 무엇에 연결할 수 있는지_를 결정합니다. 토큰이 발행된 지 5분 후, 잠재적으로 침해된 에이전트가 제안한 특정 도구 호출이 실제로 실행되어야 하는지에 대해서는 아무런 의견을 낼 수 없습니다.

그 간극이 바로 실제 공격이 발생하는 지점입니다.

프롬프트 인젝션 (Prompt Injection)이 인증된 AI 에이전트를 악용하는 방식

2025년 초, 보안 연구원 Johann Rehberger는 SpAIware를 시연했습니다. 이는 악성 웹사이트를 통해 전달된 단일 간접 프롬프트 인젝션 (Indirect Prompt Injection)으로, ChatGPT의 메모리 저장소에 지속적인 명령을 심어두었습니다. 해당 명령은 로그아웃과 브라우저 재시작 후에도 유지되었습니다. 침해된 인스턴스는 이후 명령 및 제어 (Command-and-Control, C2) 릴레이 역할을 수행하며, 공격자의 명령을 확인하기 위해 공개 GitHub 리포지토리를 폴링(Polling)하고 탈취된 데이터를 Azure Blob Storage 요청 로그에 기록했습니다. CSA의 2026년 3월 Promptware 보고서는 이를 더 넓은 범위의 에이전트 C2 공격 클래스로 일반화했습니다.

에이전트의 내장된 기능(웹 접속, 메모리, 코드 실행)은 모두 런타임(runtime)에서 정당하게 사용 가능한 상태였습니다. EMA(Enterprise Managed Authorization) 방식의 중앙 집중식 프로비저닝(provisioning)은 결과에 영향을 미치지 못했을 것입니다. 주입된 지침(injected instructions)은 별도로 프로비저닝된 OAuth 연결이 아니라, 에이전트 환경에 이미 존재하는 기능들을 악용했습니다. 어떠한 권한 부여 계층(authorization layer)도 사용자가 시작한 동작과 주입에 의해 시작된 동작을 구분하지 못했습니다. 문제는 인증(authentication)이 아니었기 때문에, 연결 시점의 거버넌스(governance)는 무력했습니다. 에이전트는 자신이 주장하는 바로 그 존재였습니다.

2026년 중반, 연구자들은 GitHub 댓글, 이슈 본문, PR 제목을 통한 프롬프트 인젝션(prompt-injection) 공격이 Claude Code, Gemini CLI, 그리고 GitHub Copilot Agent를 하이재킹(hijack)할 수 있음을 입증했습니다. 세 제품 모두에서, 공격은 사전 승인된 도구 기능(tool capabilities)을 악용하여 CI 비밀 정보를 유출했습니다. 일부 변종은 셸 명령(shell-command) 실행을 유도하기도 했습니다. 이와 관련된 학술 연구는 15개의 GitHub Actions 전반에 걸쳐 유사한 인젝션 벡터(injection vectors)를 기록했습니다. Anthropic의 대응 방식은 시사하는 바가 큽니다. 그들은 광범위한 도구 액세스를 제한하는 대신 ps 도구 사용을 금지했습니다. 이러한 대응은 연결 수준(connection-level)의 상처에 반창고를 붙이는 임시방편에 불과했습니다.

이것들은 고립된 사례들이 아닙니다. F5는 공격자가 AI 챗봇에 프롬프트 인젝션 (Prompt Injection)을 사용하여 승인되지 않은 금융 거래를 시작하고, 은행이 여러 계좌가 영향을 받은 후에야 손실을 인지하게 되는 뱅킹 시나리오를 설명합니다. The AI Red Teaming Guide는 2025년까지 공개된 MCP 관련 취약점들을 지속적으로 목록화하고 있습니다. 2022년부터 프롬프트 인젝션 (Prompt Injection)을 추적해 온 Simon Willison은 이 패턴을 위해 다음과 같은 "치명적인 삼중주 (lethal trifecta)"(https://simonw.substack.com/p/the-lethal-trifecta-for-ai-agents)라는 용어를 만들었습니다: 즉, 개인 데이터 (private data), 신뢰할 수 없는 콘텐츠 (untrusted content), 그리고 외부 통신 (external communication)이 동일한 시스템 내에서 수렴하는 현상을 말합니다.

모든 공격을 관통하는 공통점은 다음과 같습니다: 공격자는 에이전트가 이미 자신의 런타임 (runtime)에서 사용할 수 있는 권한을 오용하도록 유도했습니다. 그 어떤 권한 부여 (authorization) 계층도 특정 동작이 사용자의 의도와 일치하는지 묻지 않았습니다.

**작업별 권한 부여 (Per-action authorization)**는 프롬프트 이후, 실행 시점에 모든 동작에 대해 독립적으로 조직 정책 (organization policy), 사용자 위임 (user delegation), 그리고 에이전트 역량 (agent capability)의 교차점을 확인하여 특정 도구 호출 (tool call)을 진행할지 여부를 평가합니다. 이는 권한 부여 시점의 권한 부여 (grant-time authorization, EMA가 제공하는 방식) 및 세션 수준의 권한 부여 (session-level authorization, 대화당 한 번 확인)와는 구별됩니다.

작업별 권한 부여 (Per-action authorization) 자체가 프롬프트 인젝션 (Prompt Injection) 탐지기는 아닙니다. 이는 결정론적 제약 조건 (deterministic constraints)을 위반하는 동작을 거부하거나 에스컬레이션함으로써 폭발 반경 (blast radius)을 제한합니다. 해당 제약 조건 내에 머무는 인젝션된 동작은 여전히 실행될 수 있으므로, 민감한 작업에 대해서는 출처 제어 (provenance controls), 콘텐츠 격리 (content isolation), 그리고 인간의 승인 (human approval)이 여전히 필요합니다.

EMA vs. 작업별 권한 부여 (Per-Action Authorization): 프로비저닝 (Provisioning) vs. 런타임 (Runtime)

EMA와 작업별 권한 부여 (per-action authorization)는 경쟁 관계에 있는 솔루션이 아닙니다. 이들은 실행 생명주기 (execution lifecycle)의 서로 다른 시점에서 작동하며, 서로 다른 위협 모델 (threat models)을 다룹니다.

우려 사항 (Concern)	EMA (연결 시점)	작업별 권한 부여 (Per-Action Authorization) (런타임)
결정 지점 (Decision point)	에이전트가 서버에 연결하기 전	에이전트가 특정 도구 호출 (tool call)을 실행하기 전
...

EMA는 외부 게이트 (outer gate)를 제공합니다. 이는 관리되는 기업용 ID (corporate identities)를 통해 승인된 사용자만이 승인된 서버에 연결되도록 보장합니다. 하지만 EMA 자체는 도구 호출별 (per-tool-call) 시맨틱 정책 (semantic policy)을 추가하지 않습니다. 개별 MCP 서버가 각 요청에 대해 스코프 (scopes), ACL (Access Control Lists), 또는 속도 제한 (rate limits)을 강제할 수는 있지만, 이러한 제어 방식은 서버별로 특화되어 있고, 생태계 전반에 걸쳐 일관성이 없으며, 도구 호출이 사용자의 의도에서 비롯된 것인지 아니면 주입된 명령 (injected instructions)에서 비롯된 것인지 인지하지 못합니다.

MCP 보안에 관한 NSA의 2026년 5월 사이버 보안 정보 문서는 단호합니다: "MCP 자체는 프로토콜 수준에서 이러한 보안 원칙을 강제할 수 없습니다." 이는 EMA에도 동일하게 적용됩니다. 이 확장 기능은 프로비저닝 (provisioning) 결정을 중앙 집중화합니다. 하지만 에이전트가 수행하려는 도구 호출이 사용자의 의도에 의해 트리거된 것인지, 아니면 GitHub 댓글에 포함된 악의적인 명령에 의해 트리거된 것인지는 평가할 수 없으며, 평가하지도 않습니다.

OAuth 스코프 (Scopes)가 AI 에이전트 권한 부여에 충분하지 않은 이유

OAuth 스코프 (scopes)는 공백으로 구분된 문자열이며, 트랜잭션별 (transaction-specific) 권한 부여를 수행하기에는 너무 거친 (coarse) 경우가 많습니다. mail.send 스코프는 어떤 수신자에게든 이메일을 보낼 수 있는 권한을 부여합니다. 이는 어떤 수신자인지, 어떤 맥락 (context)인지, 사용자가 이 특정 이메일을 의도했는지, 또는 대화가 인젝션 (injection)에 의해 오염되었는지 여부를 인코딩할 수 없습니다.

RFC 9396 (Rich Authorization Requests, RAR)는 type, locations, actions 필드를 사용하여 API 액세스를 설명하는 JSON 객체를 사용함으로써 이 문제를 부분적으로 해결합니다. RAR은 트랜잭션별 권한 부여 세부 정보(수신자, 금액, 리소스)를 사용하여 이후의 작업을 제한할 수 있으며, 리소스 서버(resource servers)는 이러한 세부 정보를 강제할 수 있습니다. 하지만 RAR은 에이전트의 이후 작업이 여전히 사용자의 현재 의도를 반영하는지에 대한 출처 인식 평가(provenance-aware evaluation)를 표준화하지는 않습니다. 에이전트가 잠재적으로 오염된 대화로부터 도구 호출(tool call)을 수행할 때, RAR은 매개변수(parameters)를 제한할 수는 있지만, 해당 호출이 사용자에 의해 시작된 것인지 아니면 인젝션(injection)에 의해 시작된 것인지는 판단할 수 없습니다.

MCP 사양의 인증 확장(auth extensions)도 동일한 구조적 한계에 직면해 있습니다. 2026년 6월 기준으로, EMA와 클라이언트 자격 증명(Client Credentials) 모두 전송/연결 레벨(transport/connection level)에서 작동합니다. ext-auth 리포지토리에는 작업별 권한 부여(per-action authorization) 확장이 포함되어 있지 않습니다. 최종 MCP SEP-2468은 권한 부여 서버(authorization servers)가 OAuth 권한 응답의 iss 매개변수를 포함할 것을 권장하며, 클라이언트가 이를 검증하도록 요구하여 권한 부여 서버 믹스업 공격(authorization-server mix-up attacks)을 완화합니다. 이는 전송 보안(transport-security) 조치이지, 작업별 평가(per-action evaluation)가 아닙니다. MCP의 핵심 권한 부여는 런타임 시의 불충분한 범위(insufficient-scope) 도전과 스텝업 권한 부여(step-up authorization)를 지원하며, 여기서 범위(scopes)는 요청 인자(request arguments) 및 컨텍스트(context)에 따라 달라질 수 있습니다. 이것들은 가치 있는 서버 측 제어 수단이지만, 여전히 서버 정의 범위 강제(server-defined scope enforcement)일 뿐, 표준화된 출처 인식 권한 부여(provenance-aware authorization)는 아닙니다.

이는 프로토콜이나 확장의 실수(oversight)가 아닙니다. 이는 아키텍처적 경계(architectural boundary)를 반영합니다. 인증(Authentication)은 "이것은 누구인가?"에 답합니다. 연결 레벨 권한 부여(Connection-level authorization, EMA 포함)는 "이 엔티티가 무엇에 액세스할 수 있는가?"에 답합니다. 작업별 권한 부여(Per-action authorization)는 "이 특정 작업이 지금 당장 일어나야 하는가?"에 답합니다. 제로 터치 OAuth(Zero-touch OAuth)는 앞의 두 가지를 확립합니다. 세 번째를 위해서는 추가적인 애플리케이션 또는 런타임 레벨의 메커니즘이 필요합니다.

OAuth는 권한 부여(Authorization) 및 토큰 생명주기 전반에 걸쳐 점진적으로 방어 체계를 추가해 왔습니다. RFC 6749 (2012)와 RFC 6750은 송신자 제한(Sender-constraining)이 없는 베어러 토큰(Bearer tokens)을 정의했습니다. PKCE (2015)는 권한 부여 코드 가로채기(Authorization-code interception)를 완화했습니다. DPoP (2023)는 재전송 공격(Replay)을 줄이기 위해 송신자 제한 토큰(Sender-constrained tokens)을 도입했습니다. RFC 9700 (2025)은 "OAuth 2.0이 발표된 이후 수집된 실질적인 경험"을 바탕으로 전체 위협 모델(Threat model)을 업데이트했습니다. 이러한 메커니즘들은 작업별 권한 부여(Per-action authorization)는 아니지만, 베어러 자격 증명(Bearer credentials)에만 의존하는 방식에서 벗어나려는 광범위한 움직임을 보여줍니다. 각각의 추가 사항은 권한 부여 시점의 자격 증명이 안전하게 커버할 수 있는 범위에 대한 가정을 악용한 실제 공격들에 대응한 결과였습니다.

AI 에이전트를 위한 3계층 권한 부여 모델

에이전트는 단일 권한 세트가 아닌, 세 가지 별개의 권한 세트가 교차하는 지점에서 작동합니다.

AWS IAM은 이 모델에 대한 유용한 선례를 제공합니다. 다음 표는 교차 원리(Intersection principle)를 설명하기 위해 IAM의 전체 평가 로직(ID 기반 및 리소스 기반 권한 부여를 결합한 후, 권한 경계(Permissions boundaries) 및 SCP로 이를 제한하는 방식)을 단순화한 것입니다:

IAM 계층	에이전트 권한 부여 유사 모델	제어 대상
서비스 제어 정책 (Service Control Policy, 조직)	조직 정책 (Organization policy)	이 조직 내의 어떤 에이전트도 가질 수 있는 최대 권한
...

ID 정책 또는 리소스 정책이 해당 작업을 허용해야 하며, 동시에 권한 경계(Permissions boundary)와 SCP가 이를 허용해야 합니다. 명시적 거부(Explicit deny)는 허용(Allow)보다 우선하며, 권한 경계를 추가하는 것은 유효 권한(Effective permissions)을 축소할 수만 있습니다.