MCP(Model Context Protocol) 멀티에이전트 위임 패턴 심층 분석 — OAuth Token Exchange(RFC 8693)와 단방향 권한 축소로 에이전트 체인 보안 설계하기
프로덕션 장애는 예상치 못한 곳에서 찾아옵니다. 한 팀이 문서 요약 파이프라인을 에이전트로 자동화했을 때입니다. 오케스트레이터 에이전트는 서브에이전트에게 read:documents만 부여할 의도였지만, 토큰 교환 없이 원본 액세스 토큰을 그대로 전달했습니다. 서브에이전트는 결국 delete:documents 권한으로 파일을 영구 삭제했고, 감사 로그에는 오케스트레이터 에이전트의 신원만 남아 있었습니다. 서브에이전트가 무엇을 했는지, 어떤 위임 경로로 권한을 얻었는지는 추적이 불가능했습니다.
이 글은 바로 그런 상황을 구조적으로 막는 방법을 다룹니다. MCP 환경에서 에이전트가 다른 에이전트에게 권한을 넘길 때 발생하는 신뢰 경계 문제를 분석하고, OAuth 2.0 Token Exchange(RFC 8693), 단방향 권한 축소, On-Behalf-Of 흐름을 조합해 위임 체인 전체를 암호학적으로 검증·추적하는 설계를 구체적으로 살펴봅니다. JWT와 OAuth 2.0 기초에 익숙한 백엔드·풀스택 개발자라면 바로 읽을 수 있습니다.
이 글을 다 읽고 나면 멀티에이전트 위임 체인에서 권한 에스컬레이션을 구조적으로 차단하고, 각 위임 단계에 감사 가능한 흔적을 남기며, 특정 에이전트의 권한만 선택적으로 취소하는 설계를 직접 구현할 수 있게 됩니다.
핵심 개념
신뢰 경계(Trust Boundary)와 위임이 필요한 이유
전통적인 단일 서비스에서는 사용자 인증이 한 번 이루어지면 그 세션이 전체 요청 수명 동안 유효합니다. 그런데 멀티에이전트 시스템에서는 "사용자 → 오케스트레이터 에이전트 → 서브에이전트 A → MCP 서버 → 서브에이전트 A-1"처럼 여러 홉(hop)을 거칩니다. 각 홉마다 새로운 신뢰 경계가 생기며, 이 경계를 넘을 때마다 "지금 이 요청을 보낸 주체가 정말 원래 사용자의 의도를 대변하는가?"를 검증해야 합니다.
MCP는 각 서버 인터페이스마다 신원 전파가 구조적으로 끊어지는 특성이 있습니다. 아무런 장치 없이 에이전트가 다른 에이전트를 호출하면, 수신 측에서는 "누가 보낸 요청인지"를 알 방법이 없습니다. 이것이 위임 패턴이 필요한 근본 이유입니다.
신뢰 경계(Trust Boundary): 두 컴포넌트 사이에서 서로 다른 신뢰 수준이 적용되는 경계선. 에이전트 체인에서는 매 홉마다 이 경계가 발생하며, 경계를 넘을 때 반드시 신원과 권한을 재검증해야 합니다.
토큰 전파(Token Propagation) — RFC 8693과 act 클레임
위임 체인에서 신원을 전달하는 핵심 메커니즘은 **OAuth 2.0 Token Exchange(RFC 8693)**입니다. 에이전트가 자신의 토큰을 새 토큰으로 교환할 때, 원본 사용자의 신원(sub)과 현재 행위자(act)를 모두 담을 수 있습니다. 위임 체인이 깊어지면 act 클레임이 중첩(nested) 구조로 쌓입니다.
{
"sub": "user-alice-001", // 원본 사용자 (변경되지 않음)
"act": {
"sub": "orchestrator-agent-A", // 1차 위임: 오케스트레이터
"act": {
"sub": "subagent-A1", // 2차 위임: 서브에이전트
"client_id": "mcp-tool-caller"
}
},
"scope": "read:documents", // 실제 부여된 권한
"aud": "mcp-server-docs", // 이 토큰을 수신할 MCP 서버
"exp": 1775000000 // 만료 시각 (Unix timestamp)
}이 토큰을 보면 "Alice가 오케스트레이터 A에게, A가 서브에이전트 A1에게 위임했으며, 현재 A1이 read:documents 권한으로 MCP 문서 서버를 호출하고 있다"는 사실을 한눈에 파악할 수 있습니다. MCP 서버는 sub와 act 체인 전체를 감사 로그에 기록하는 것이 좋습니다.
한 가지 중요한 실제 제약이 있습니다. act 클레임이 깊이 중첩될수록 JWT 페이로드 크기가 홉당 200
500바이트씩 선형으로 증가합니다. HTTP 헤더 크기 제한(일반적으로 8KB)에 도달할 수 있고, 서명 검증 비용도 깊이에 비례해 증가합니다. 위임 깊이를 3
4홉으로 제한하라는 권고의 핵심 이유가 여기에 있습니다.
// RFC 8693 Token Exchange 요청 예시 (TypeScript)
async function exchangeTokenForAgent(
userToken: string,
agentClientId: string,
requestedScopes: string[]
): Promise<string> {
const response = await fetch("https://auth.example.com/token", {
method: "POST",
headers: { "Content-Type": "application/x-www-form-urlencoded" },
body: new URLSearchParams({
grant_type: "urn:ietf:params:oauth:grant-type:token-exchange",
subject_token: userToken,
subject_token_type: "urn:ietf:params:oauth:token-type:access_token",
requested_token_type: "urn:ietf:params:oauth:token-type:access_token",
audience: "mcp-server-docs",
scope: requestedScopes.join(" "),
client_id: agentClientId,
}),
});
if (!response.ok) {
const errorBody = await response.text();
throw new Error(
`Token exchange failed (${response.status}): ${errorBody}`
);
}
const body = await response.json();
if (!body.access_token) {
throw new Error("Token exchange succeeded but no access_token returned");
}
return body.access_token; // act 클레임이 포함된 위임 토큰
}단방향 권한 축소 — Biscuit과 Macaroon의 선택 기준
단방향 권한 축소(Monotonic Attenuation) 원칙은 간단합니다. 하위 에이전트는 절대 상위 에이전트보다 넓은 권한을 가질 수 없습니다. 오케스트레이터가 read, write 권한을 가지고 있다면, 서브에이전트에게는 read만 위임할 수 있고, admin 권한은 위임 자체가 불가능합니다.
이 원칙을 암호학적으로 강제하는 두 가지 토큰 포맷이 있습니다. Macaroon은 HMAC 체인으로 캐비엇을 추가하는 방식으로, 구현이 간단하고 많은 언어에서 지원됩니다. 그러나 제3자 캐비엇(third-party caveat)에서 보안 취약점이 발견됐고, 공개 검증(수신자가 서명을 독립 확인하는 것)이 어렵습니다. Biscuit은 이 한계를 극복하기 위해 별도로 설계된 포맷으로, Ed25519 공개 키 암호화 기반이라 공개 키만 있으면 누구나 서명을 독립 검증할 수 있고, 제3자 캐비엇도 안전하게 처리합니다. 새 프로젝트를 시작한다면 Biscuit이 더 나은 선택입니다.
두 포맷 모두에서 캐비엇의 핵심 특성은 동일합니다. 추가(권한 축소)는 누구나 할 수 있지만, 제거(권한 확대)는 원본 발급자의 서명이 없으면 불가능합니다.
캐비엇(Caveat): 토큰에 덧붙이는 검증 조건. "이 토큰은 2026-04-15 이전에만 유효", "이 토큰은 read 권한만 허용" 같은 제약을 암호학적으로 체인에 붙일 수 있으며, 추가는 가능하지만 제거는 원본 서명자만 할 수 있습니다.
# Biscuit 토큰으로 단방향 권한 축소 구현 (Python)
# 실제 biscuit-python 패키지 API는 아래와 다를 수 있습니다.
# 블록 추가 시 키페어 처리 방식이 다르므로 공식 문서를 참고하세요.
# pip install biscuit-python
from biscuit_auth import BiscuitBuilder, BlockBuilder, KeyPair
root_keypair = KeyPair() # 실제 환경에서는 환경 변수나 HSM에서 로드합니다
# 오케스트레이터용 루트 토큰 발급
root_token = (
BiscuitBuilder()
.fact('right("docs", "read")')
.fact('right("logs", "write")')
.fact("budget(100)")
.build(root_keypair.private_key)
)
# 서브에이전트 A에게 위임 — 권한을 read only, 예산 40으로 축소
attenuated_token = root_token.append_block(
BlockBuilder()
.check('check if right($resource, "read")') # write 제거
.check("check if budget($b), $b <= 40") # 예산 40으로 제한
)
# 서브에이전트 A-1에게 재위임 — docs만 허용, 예산 10으로 추가 축소
further_attenuated = attenuated_token.append_block(
BlockBuilder()
.check('check if right("docs", "read")') # logs 제거
.check("check if budget($b), $b <= 10")
)지금까지 세 가지 기반 개념(신뢰 경계, 토큰 전파, 단방향 권한 축소)을 살펴봤습니다. 다음은 이 세 개념을 실제로 연결하는 On-Behalf-Of 흐름입니다.
On-Behalf-Of(OBO) 흐름 — 두 신원을 동시에 제시하기
에이전트가 사용자를 대신해 행동할 때는 사용자 신원과 에이전트 신원을 동시에 제시해야 합니다. 이 두 신원이 분리되어야 "사용자 Alice가 요청했는가?"와 "에이전트 A가 처리했는가?"를 각각 독립적으로 추적할 수 있습니다.
사용자(Alice) IdP 에이전트 MCP 서버
│ │ │ │
│── 로그인 ────────>│ │ │
│<─ id_token ───────│ │ │
│── id_token 전달 ──────────────────────>│ │
│ │<── Token Exchange ─│ │
│ │ (RFC 8693 OBO) │ │
│ │── act 토큰 ────────>│ │
│ │ │── API 호출 ────>│
│ │ │ (sub=Alice, │
│ │ │ act=AgentA) │
│ │ │<── 응답 ────────│
│ │ │ │── 감사 로그
│ │ │ (sub+act 기록)이 흐름의 핵심은 IdP가 두 신원을 모두 검증한 뒤 하나의 토큰에 담아준다는 점입니다. MCP 서버는 수신한 토큰에서 sub(원본 사용자)과 act(에이전트 체인) 전체를 감사 로그에 남기게 됩니다.
실전 적용
예시 1: DelegateOS로 중첩 위임 체인 구현하기
DelegateOS는 Ed25519 서명 기반의 위임 토큰, 단방향 권한 축소, 예산 추적, MCP 통합을 제공하는 TypeScript 라이브러리입니다. 아래 코드는 DelegateOS의 설계 철학을 보여주는 개념적 예시입니다. 실제 구현 전에 패키지가 현재 npm에 게시되어 있는지 GitHub 레포지터리에서 확인하는 것이 좋습니다.
import { DelegationChain, DelegationToken, Budget } from "@newtro/delegateos";
// orchestratorPrivateKey는 환경 변수나 HSM(Hardware Security Module)에서
// 로드해야 합니다. 코드에 하드코딩하면 안 됩니다.
// 예: const orchestratorPrivateKey = loadKeyFromEnv("ORCHESTRATOR_PRIVATE_KEY");
// 1. 오케스트레이터 루트 토큰 발급
const orchestratorChain = await DelegationChain.create({
subject: "user-alice-001",
actor: "orchestrator-agent",
permissions: ["read", "write"],
budget: new Budget({ tokens: 100, apiCalls: 500 }),
expiresIn: "1h",
signingKey: orchestratorPrivateKey,
});
// 2. 서브에이전트 A에게 위임 (read only, 예산 40)
const subAgentAToken: DelegationToken = await orchestratorChain.delegate({
to: "subagent-a",
permissions: ["read"], // write 제거
budget: new Budget({ tokens: 40, apiCalls: 200 }),
attestation: {
taskId: "task-summarize-docs",
reason: "문서 요약 작업",
timestamp: Date.now(),
},
});
// 3. 서브에이전트 A-1에게 재위임 (read:docs only, 예산 10)
const subAgentA1Token: DelegationToken = await subAgentAToken.delegate({
to: "subagent-a1",
permissions: ["read:docs"], // 리소스 범위 추가 축소
budget: new Budget({ tokens: 10, apiCalls: 50 }),
attestation: {
taskId: "task-summarize-docs-section-1",
reason: "1장 요약",
timestamp: Date.now(),
},
});
// 4. 서브에이전트 B에게 위임 (write:logs only, 예산 60)
const subAgentBToken: DelegationToken = await orchestratorChain.delegate({
to: "subagent-b",
permissions: ["write:logs"],
budget: new Budget({ tokens: 60, apiCalls: 300 }),
attestation: {
taskId: "task-write-audit-log",
reason: "감사 로그 기록",
timestamp: Date.now(),
},
});
// 5. MCP 서버 호출 시 토큰 전달
const mcpResponse = await mcpClient.callTool(
"read_document",
{ documentId: "doc-001" },
{
headers: {
Authorization: `Bearer ${subAgentA1Token.serialize()}`,
"X-Delegation-Chain": subAgentA1Token.getChainProof(),
},
}
);| 코드 포인트 | 설명 |
|---|---|
permissions: ["read"] |
상위(오케스트레이터)의 ["read", "write"]에서 write 제거 — 단방향 권한 축소 적용 |
budget: new Budget(...) |
예산이 상위보다 크면 라이브러리가 자동으로 예외를 발생시킵니다 |
attestation |
각 위임 단계마다 서명된 증거를 생성해 감사 체인을 구성합니다 |
getChainProof() |
MCP 서버가 전체 위임 경로를 독립적으로 검증할 수 있는 증명 데이터 |
signingKey |
환경 변수나 HSM에서 로드한 Ed25519 개인 키 |
예시 2: Microsoft Agent Governance Toolkit으로 실행 링(Execution Ring) 적용하기
Microsoft AGT는 CPU 특권 링을 모델로 한 실행 링 개념을 도입합니다. Ring 0이 가장 신뢰도 높은 시스템 레벨, Ring 3이 신뢰도 가장 낮은 외부 에이전트입니다. 각 링마다 허용되는 작업이 정의되며, 하위 링에서 상위 링의 권한을 사용하려 하면 정책 엔진이 즉시 차단합니다.
from agent_governance_toolkit import AgentRuntime, ExecutionRing, Policy
# 정책 정의: Ring 별 허용 작업
policy = Policy.from_yaml("""
rings:
ring0: # 오케스트레이터 (최고 신뢰)
allowed_actions: ["*"]
budget_limit: 10000
ring1: # 내부 서브에이전트
allowed_actions: ["read:*", "write:logs", "call:mcp_tools"]
budget_limit: 1000
max_delegation_depth: 2
ring2: # 외부 API 호출 에이전트
allowed_actions: ["read:public", "call:external_api"]
budget_limit: 100
max_delegation_depth: 0 # 재위임 금지
ring3: # 미검증 외부 에이전트
allowed_actions: [] # 모든 작업 차단
require_human_approval: true
""")
runtime = AgentRuntime(policy=policy)
# 에이전트 등록 및 링 배정
orchestrator = runtime.register_agent(
agent_id="orchestrator-001",
ring=ExecutionRing.RING0,
identity_token=orchestrator_jwt,
)
subagent_a = runtime.register_agent(
agent_id="subagent-a",
ring=ExecutionRing.RING1,
identity_token=subagent_a_jwt,
)
# 위임 실행 — Ring 정책 자동 적용
async def run_task():
async with runtime.delegation_context(
delegator=orchestrator,
delegatee=subagent_a,
task_scope=["read:documents"],
) as ctx:
result = await subagent_a.call_mcp_tool(
"read_document",
args={"id": "doc-001"},
delegation_context=ctx,
# Ring 정책 엔진이 모든 호출을 실시간으로 검사합니다
)
# 감사 로그 자동 생성 (EU AI Act, HIPAA, SOC 2 매핑 포함)
return result참고:
max_delegation_depth: 0으로 설정된 Ring 2 에이전트는 추가 위임이 불가능합니다. 이 설정은 외부 API 호출 에이전트가 예상치 못한 하위 에이전트를 생성하는 상황을 방지합니다.
예시 3: Auth0 Token Vault로 서드파티 API 위임하기
사용자가 에이전트에게 Google Drive 접근을 허용할 때, 원본 OAuth 토큰을 에이전트에 직접 노출하지 않고 Token Vault를 통해 단기 토큰만 발급하는 패턴입니다.
import { TokenVault } from "@auth0/agent-toolkit";
const vault = new TokenVault({
domain: "your-tenant.auth0.com",
clientId: process.env.AUTH0_CLIENT_ID,
});
// 에이전트가 Google Drive 접근이 필요할 때
async function getGoogleDriveAccess(
userToken: string,
agentId: string
): Promise<string> {
// Token Vault가 내부적으로 RFC 8693 Token Exchange 수행
const { access_token } = await vault.exchangeForService({
subjectToken: userToken,
targetService: "google-drive",
actor: agentId,
scopes: ["https://www.googleapis.com/auth/drive.readonly"],
maxDuration: 3600, // 원본 사용자 세션보다 길어질 수 없습니다
});
// 원본 Google OAuth 토큰은 Vault에만 존재, 에이전트에 노출되지 않습니다
return access_token; // 단기 위임 토큰만 반환
}
// MCP 도구 구현
const googleDriveTool = {
name: "list_drive_files",
handler: async (args: { folderId: string }, context: MCPContext) => {
const driveToken = await getGoogleDriveAccess(
context.userToken,
context.agentId
);
// driveToken은 1시간짜리 단기 토큰으로, 유출되더라도 피해가 최소화됩니다
return await googleDriveClient.listFiles(args.folderId, driveToken);
},
};장단점 분석
장점
| 항목 | 내용 |
|---|---|
| 최소 권한 강제 | 단방향 권한 축소 원칙으로 권한 에스컬레이션을 구조적으로 차단합니다. 코드 버그로도 상위 권한 획득이 불가능합니다. |
| 감사 가능성 | 서명된 어테스테이션 체인으로 HIPAA, SOC 2, EU AI Act 컴플라이언스를 달성할 수 있습니다. |
| 책임 분리 | 사용자 신원(sub)과 에이전트 신원(act)이 분리되어 이상 탐지와 정책 집행이 세밀해집니다. |
| 세분화된 취소 | 특정 서브에이전트의 토큰만 무효화해 전체 세션을 건드리지 않고 권한을 회수할 수 있습니다. |
| 예산 제어 | 비용과 API 호출 횟수를 암호학적으로 강제해 에이전트의 무제한 소비를 방지합니다. |
| 오프라인 검증 | Biscuit 기반 토큰은 네트워크 왕복 없이도 공개 키로 서명을 검증할 수 있어 레이턴시가 줄어듭니다. |
단점 및 주의사항
실무에서 마주치는 빈도순으로 정렬했습니다.
| 항목 | 내용 | 대응 방안 |
|---|---|---|
| ⚠️ 토큰 재사용·audience 누락 (가장 흔함) | audience가 없는 토큰은 다른 MCP 서버에서도 유효하게 수락되어 리플레이 공격에 노출됩니다. | OAuth 2.1 리소스 인디케이터로 aud를 특정 MCP 서버로 명시하고, 토큰에 nonce를 바인딩합니다. |
| ⚠️ 원본 토큰 직접 전달 (가장 흔함) | 토큰 교환 없이 원본 토큰을 서브에이전트에 넘기면 단방향 권한 축소가 완전히 무너지고 감사 체인이 사라집니다. | 모든 위임 단계에서 RFC 8693 Token Exchange를 필수화합니다. |
| 위임 체인 스플라이싱 | 손상된 중간 에이전트가 서로 다른 컨텍스트의 subject_token과 actor_token을 조합해 의도치 않은 권한 조합을 만들 수 있습니다. |
각 토큰에 audience와 nonce를 바인딩하고, 토큰 교환 엔드포인트에서 컨텍스트 일관성을 검증합니다. |
| 복잡성 증가 | 위임 체인이 깊어질수록 토큰 검증 로직과 감사 로그 관리가 복잡해집니다. JWT 페이로드도 홉당 수백 바이트씩 증가합니다. | 최대 위임 깊이를 3~4홉으로 제한하고, 거버넌스 라이브러리로 추상화합니다. |
| 성능 오버헤드 | 각 홉마다 토큰 교환 왕복이 추가됩니다. 외부 IdP 의존 시 레이턴시가 크게 증가할 수 있습니다. | 오프라인 검증 가능한 Biscuit 토큰을 사용하거나, IdP 응답을 짧게 캐싱합니다. |
| 표준 미성숙 | IETF draft-klrc-aiagent-auth는 아직 초안 단계로, 프레임워크마다 구현이 달라 상호운용성 문제가 발생할 수 있습니다. |
코어 로직은 RFC 8693 기반으로 구현하고, 프레임워크별 어댑터를 별도로 관리합니다. |
| 토큰 수명 관리 | 에이전트가 장시간 실행될 경우 원본 사용자 세션보다 긴 토큰이 발급될 수 있습니다. | max_duration을 원본 세션의 남은 시간으로 상한을 설정합니다. |
| 동의 복잡성 | "어떤 에이전트가 어떤 리소스에 접근한다"는 사실을 사용자가 이해할 수 있는 형태로 동의를 받기 어렵습니다. | 동의 화면에서 에이전트 이름, 접근 리소스, 유효 기간을 명시적으로 표시합니다. |
위임 체인 스플라이싱(Delegation Chain Splicing): 공격자가 A 컨텍스트의 사용자 토큰과 B 컨텍스트의 에이전트 토큰을 조합해 의도치 않은 권한 조합을 만드는 공격.
nonce는 이 공격을 방어하는 핵심 메커니즘입니다. 토큰 교환 요청마다 UUID 등의 무작위 값을nonce클레임으로 생성하고, 발급된 토큰에 이 값을 포함시킵니다. 수신 서버는nonce가 해당 교환 컨텍스트와 일치하는지, 그리고 이미 사용된 값인지를 단기 캐시로 확인합니다. 다른 컨텍스트에서 발급된 토큰은nonce불일치로 즉시 거부됩니다.
실무에서 가장 흔한 실수
- 서브에이전트에게 오케스트레이터와 동일한 토큰을 그대로 전달하는 것입니다. 토큰 교환 없이 원본 토큰을 넘기면 단방향 권한 축소 원칙이 완전히 무너지고, 감사 로그에서
act체인이 사라집니다. 도입부의 사고 사례가 바로 이 경우입니다. - 위임 토큰의
audience를 특정 MCP 서버로 한정하지 않는 것입니다. audience가 없는 토큰은 다른 MCP 서버에서도 유효하게 수락되어 리플레이 공격에 노출됩니다. OAuth 2.1 리소스 인디케이터로aud를 반드시 명시하는 것이 좋습니다. - 에이전트가 OAuth 토큰을 메모리나 파일에 직접 저장하고 재사용하는 것입니다. 토큰이 유출되면 피해가 커집니다. Auth0 Token Vault 같은 외부 보관소를 통해 단기 토큰만 발급받는 패턴을 사용하면 유출 피해를 최소화할 수 있습니다.
마치며
멀티에이전트 위임 설계의 핵심은 "신뢰는 항상 축소되는 방향으로만 흘러야 하며, 모든 위임 단계는 검증 가능한 흔적을 남겨야 한다"는 원칙에 있습니다. 복잡해 보이지만 RFC 8693의 act 클레임, Biscuit의 캐비엇, DelegateOS의 서명된 어테스테이션 체인을 조합하면 이 원칙을 코드로 직접 구현할 수 있습니다.
세 가지 예시 중 어떤 것을 선택할지는 상황에 따라 다릅니다.
| 상황 | 권장 접근 |
|---|---|
| 오픈소스 프로젝트, 세밀한 제어가 필요, TypeScript 환경 | DelegateOS(개념 기반으로 자체 구현) |
| 엔터프라이즈 환경, 컴플라이언스(EU AI Act·SOC 2·HIPAA) 자동화 필요 | Microsoft Agent Governance Toolkit |
| 서드파티 API(Google, GitHub 등) 위임, SaaS 환경, 빠른 도입 | Auth0 Token Vault |
| 세 가지 모두 공통 | RFC 8693 Token Exchange + audience 명시 |
지금 바로 시작할 수 있는 3단계:
- 기존 MCP 에이전트의 토큰 흐름을 점검하세요. 서브에이전트 호출 시 원본 토큰을 그대로 전달하고 있다면, RFC 8693 Token Exchange를 지원하는 IdP(ZITADEL, Keycloak 등)를 도입해
act클레임이 포함된 위임 토큰으로 교체하는 것부터 시작할 수 있습니다. - 샌드박스 프로젝트에서 위임 체인의 경계 조건을 실험해보세요. 권한 에스컬레이션 시도, 예산 초과, audience 불일치 상황에서 선택한 라이브러리나 IdP가 어떻게 반응하는지 직접 확인하면 이후 프로덕션 설계에서 예상치 못한 빈틈을 줄일 수 있습니다.
- 감사 로그 구조를 미리 설계해두면 SOC 2 감사 비용이 크게 줄어듭니다. 각 MCP 서버 호출마다
sub(원본 사용자),act체인(에이전트 경로),tool_name,timestamp,budget_consumed를 구조화된 로그로 남기면, HIPAA나 SOC 2 감사 요청이 왔을 때 증거를 재구성하는 작업이 훨씬 수월해집니다.
다음 글: MCP 서버의 프롬프트 인젝션 공격 — 외부 콘텐츠가 에이전트를 장악하는 메커니즘과 방어 설계 패턴
참고 자료
- Intelligent AI Delegation — Google DeepMind | arXiv
- DelegateOS: Cryptographic delegation tokens for multi-agent systems | Hacker News
- GitHub — newtro/delegateos
- Introducing the Agent Governance Toolkit | Microsoft Open Source Blog
- GitHub — microsoft/agent-governance-toolkit
- Authenticated Delegation and Authorized AI Agents | arXiv / MIT Media Lab
- The Ultimate Guide to MCP Auth: Identity, Consent, and Agent Security | Permit.io
- On-Behalf-Of authentication for AI agents | Scalekit
- Control the Chain, Secure the System: Fixing AI Agent Delegation | Okta
- Zero Trust for AI Agents: Delegation, Identity and Access Control | CyberArk
- Token Delegation and MCP server orchestration for multi-user AI systems | DEV Community
- MCP Authorization: Securing MCP Servers With Fine-Grained Access Control | Cerbos
- State of MCP Server Security 2025 | Astrix
- RFC 8693 — OAuth 2.0 Token Exchange | IETF
- IETF AI Agent Authentication and Authorization — draft-klrc-aiagent-auth | IETF
- GitHub — agentic-community/mcp-gateway-registry
- CoSAI WS4 — Secure Design of Agentic Systems | GitHub
- Advancing Multi-Agent Systems Through Model Context Protocol | arXiv