AI 에이전트 최소 권한 토큰 구현 가이드: MCP OAuth 2.1 + RFC 8707
에이전트에 API 키를 하드코딩해 두었다가 보안 감사에서 지적받은 경험이 있다면, 이 글이 정확히 필요한 내용일 것입니다. 5,200개의 MCP 서버를 대상으로 한 2025년 조사에서 OAuth를 실제로 사용하는 비율이 고작 8.5% 에 불과했고, 같은 조사에서 절반 이상의 서버가 유출 시 무기한·무제한 접근을 허용하는 장기 API 키나 PAT에 의존 중이라는 사실이 드러났습니다. 에이전트가 도구를 호출하고, 또 다른 에이전트를 깨우고, 프로덕션 데이터베이스에 쓰기를 시도하는 복잡한 워크플로에서 "하나의 긴 토큰"은 폭탄에 핀을 꽂아놓은 것과 다르지 않습니다.
MCP의 공식 인증 표준인 OAuth 2.1에 RFC 8707 Resource Indicators와 단기 발급(Ephemeral) 스코프 토큰 패턴을 결합하면, AI 에이전트가 요청하는 모든 도구 호출을 "특정 서버·특정 작업·특정 시간"으로 묶인 최소 권한 임시 액세스 토큰으로 통제할 수 있습니다. 이 글에서는 왜 기존의 Bearer 토큰 방식이 에이전트 환경에서 위험한지, RFC 8707이 어떤 공격 벡터를 차단하는지, 그리고 실제 MCP 서버에 이 패턴을 어떻게 적용하는지를 핵심 개념부터 멀티 에이전트 위임 체인, 실전 코드, 흔한 실수까지 한 번에 정리합니다.
핵심 개념
MCP가 OAuth 2.1을 선택한 이유
MCP(Model Context Protocol)는 Anthropic이 제안한 AI 에이전트와 외부 도구·서비스를 연결하는 표준 프로토콜입니다. 2025년 3월 공식 명세가 원격 서버 접근에 OAuth 2.1을 의무화하면서, MCP 서버는 공식적으로 OAuth Resource Server로 분류되었습니다.
Authorization Server vs Resource Server: Authorization Server는 토큰을 발급하는 주체(예: Auth0, ZITADEL)이고, Resource Server는 그 토큰을 받아 API 요청을 처리하는 주체(여기서는 MCP 서버)입니다. 에이전트는 먼저 Authorization Server에서 토큰을 발급받은 뒤, 그 토큰을 Resource Server(MCP 서버)에 제출해 도구를 호출합니다.
OAuth 2.1은 기존 OAuth 2.0의 보안 취약점을 제거한 통합 표준입니다.
| 제거된 항목 | 이유 |
|---|---|
| 암묵적 플로우(Implicit Flow) | 액세스 토큰이 URL 프래그먼트에 노출됨 |
| 비PKCE 인가 코드 플로우 | 인가 코드 탈취 공격에 취약 |
| 리소스 소유자 패스워드 플로우 | 클라이언트가 사용자 자격증명을 직접 처리 |
PKCE(Proof Key for Code Exchange): 공개 클라이언트(브라우저·에이전트)에서 인가 코드 탈취를 방지하는 확장입니다. 인가 요청(Authorization Request) 시에는
code_challenge(검증자의 해시값)를 전송하고, 이후 별도의 토큰 요청(Token Request) 시에 원본code_verifier를 함께 보내 두 요청이 동일 주체임을 증명합니다. 두 파라미터가 서로 다른 단계에서 전송된다는 점이 핵심입니다.
OAuth 2.1의 인가 코드 + PKCE 플로우가 실제로 어떻게 동작하는지는 예시 1의 토큰 검증 코드에서 확인할 수 있습니다.
RFC 8707 Resource Indicators — 토큰 미스리딤션 공격의 해법
RFC 8707이 해결하는 핵심 위협은 토큰 미스리딤션(Token Mis-Redemption) 공격입니다.
토큰 미스리딤션 공격: 악의적인 MCP 서버 A가 서비스 B용으로 발급된 액세스 토큰을 가로채 서비스 B에 재사용하는 공격. 토큰이 발급 대상(audience)을 명시하지 않으면 어떤 Resource Server에나 제출할 수 있어 발생합니다.
RFC 8707은 토큰 요청에 resource 파라미터를 추가해 "이 토큰은 오직 이 URI의 서버에서만 유효하다"는 제약을 토큰 자체에 각인합니다.
토큰 요청 (resource 파라미터 포함):
POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https://agent.example.com/callback
&resource=https://mcp-server.example.com ← RFC 8707 핵심
&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk발급된 토큰의 JWT 페이로드:
{
"iss": "https://auth.example.com",
"sub": "agent-user-123",
"aud": "https://mcp-server.example.com",
"scope": "tool:files:read",
"exp": 1713100800,
"iat": 1713100500,
"jti": "a1b2c3d4-e5f6-..."
}MCP 서버는 aud 클레임이 자신의 URI와 일치하는지 반드시 검증합니다. 불일치하면 즉시 거부합니다. 이 검증이 실제 코드에서 어떻게 구현되는지는 예시 1에서 확인할 수 있습니다.
Ephemeral Scoped Token — 최소 권한의 실체
단기 발급 토큰 패턴은 세 가지 축으로 최소 권한을 구현합니다.
| 축 | 전통적 API 키 | Ephemeral Scoped Token |
|---|---|---|
| 수명(TTL) | 무기한 또는 수개월 | 2분~30분 |
| 대상(Audience) | 제한 없음 | 특정 서버 URI 하나 |
| 권한(Scope) | 모든 권한 또는 넓은 범위 | 단일 도구·단일 작업 |
도구별로 별개의 스코프를 설계하면 고위험 작업과 저위험 탐색을 분리할 수 있습니다.
scope=tool:files:read → 파일 읽기, TTL 5분
scope=tool:files:write → 파일 쓰기, TTL 3분
scope=tool:code:execute → 코드 실행, TTL 2분 (고위험)
scope=tool:db:write:prod → 프로덕션 DB 쓰기, TTL 1분 + 인간 승인 필요이 스코프 설계가 실제로 에이전트 코드에서 어떻게 적용되는지는 예시 2에서 확인할 수 있습니다.
RFC 8693 Token Exchange — 에이전트 위임 체인
멀티 에이전트 아키텍처에서는 상위 에이전트의 토큰을 하위 에이전트용으로 좁혀 교환해야 합니다. RFC 8693이 이 역할을 담당합니다.
[사용자] → Orchestrator Agent
↓ RFC 8693 Token Exchange
Sub-Agent A (act 클레임에 상위 에이전트 정보 포함)
↓
MCP Server (aud=서버 URI, TTL=30초)교환 요청의 각 파라미터:
POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<orchestrator_access_token>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&requested_token_type=urn:ietf:params:oauth:token-type:access_token
&resource=https://mcp-subagent.example.com
&scope=tool:search:read
&actor_token=<subagent_client_assertion>
&actor_token_type=urn:ietf:params:oauth:token-type:jwt| 파라미터 | 역할 |
|---|---|
grant_type |
RFC 8693 Token Exchange 그랜트 타입 지정 |
subject_token |
위임자(Orchestrator)의 현재 액세스 토큰 |
subject_token_type |
subject_token이 access_token임을 명시 |
requested_token_type |
발급받을 토큰 타입 지정 |
resource |
RFC 8707: 발급될 토큰의 대상 서버 URI |
scope |
하위 에이전트에게 위임할 최소 스코프 |
actor_token |
행위자(Sub-Agent)의 자기 증명 JWT |
actor_token_type |
actor_token이 JWT임을 명시 |
발급된 하위 토큰에는 act 클레임이 추가되어, 모든 행위를 최초 인가한 인간까지 역추적할 수 있는 위임 체인이 만들어집니다.
{
"sub": "user-456",
"aud": "https://mcp-subagent.example.com",
"scope": "tool:search:read",
"exp": 1713100830,
"act": {
"sub": "orchestrator-agent",
"act": {
"sub": "user-456"
}
}
}증분 동의(Incremental Consent): 에이전트가 처음부터 모든 스코프를 요청하는 대신, 실제로 해당 작업이 필요한 시점에 추가 스코프를 요청하는 방식입니다. 예를 들어 파일 읽기 작업은 이미 허가된 상태에서, 나중에 프로덕션 DB 쓰기가 필요해질 때 별도로 사용자 승인을 받습니다. 에이전트가 미리 과도한 권한을 쌓아두는 것을 방지하며, 고위험 도구 호출 시 사람이 개입할 수 있는 자연스러운 게이트를 만들어줍니다. 위임 체인 시나리오(예시 3)에서 이 패턴의 효과가 가장 두드러집니다.
실전 적용
예시 1: MCP 서버에서 RFC 8707 토큰 검증 구현 (Python)
mcp-auth 라이브러리와 MCP Python SDK를 활용하면 Resource Server 검증 로직을 간결하게 구현할 수 있습니다.
# requirements: mcp[auth], python-jose, fastapi, httpx
from fastapi import FastAPI, Depends, HTTPException, status
from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials
from jose import jwt, JWTError
import httpx
app = FastAPI()
security = HTTPBearer()
MCP_SERVER_URI = "https://mcp-server.example.com"
AUTH_SERVER_JWKS_URI = "https://auth.example.com/.well-known/jwks.json"
async def get_jwks():
"""
Authorization Server의 공개키를 가져와 토큰 서명을 검증합니다.
주의: 이 구현은 설명 목적으로 캐싱 로직을 생략했습니다.
프로덕션에서는 cachetools, httpx_auth 등을 이용한 캐싱 처리가 반드시
필요합니다. 캐싱 없이 사용하면 매 요청마다 외부 호출이 발생해 레이턴시가
증가하고, Authorization Server 장애 시 서비스가 함께 중단될 수 있습니다.
"""
async with httpx.AsyncClient() as client:
response = await client.get(AUTH_SERVER_JWKS_URI)
return response.json()
async def verify_ephemeral_token(
credentials: HTTPAuthorizationCredentials = Depends(security)
) -> dict:
"""
RFC 8707 준수 검증:
1. 서명 유효성
2. 만료 여부 (exp)
3. audience 클레임이 이 서버 URI와 일치하는지
4. 필요한 scope 포함 여부
"""
token = credentials.credentials
jwks = await get_jwks()
try:
payload = jwt.decode(
token,
jwks,
algorithms=["RS256"],
audience=MCP_SERVER_URI, # ← RFC 8707 핵심: aud 검증
options={"verify_exp": True}
)
except JWTError as e:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail=f"토큰 검증 실패: {str(e)}",
headers={"WWW-Authenticate": "Bearer"}
)
return payload
@app.get("/tools/files/read")
async def read_file(
path: str,
token_payload: dict = Depends(verify_ephemeral_token)
):
"""tool:files:read 스코프를 가진 단기 토큰만 허용합니다."""
scopes = token_payload.get("scope", "").split()
if "tool:files:read" not in scopes:
raise HTTPException(
status_code=status.HTTP_403_FORBIDDEN,
detail="이 도구에 필요한 스코프가 없습니다: tool:files:read"
)
# TTL이 매우 짧으므로 여기까지 도달한 토큰은 유효한 것으로 신뢰
# TODO: 실제 파일 읽기 로직 구현 필요
return {"content": f"파일 읽기: {path}", "ttl_remaining": "검증됨"}| 코드 포인트 | 역할 |
|---|---|
audience=MCP_SERVER_URI |
RFC 8707 핵심 — aud 클레임이 이 서버 URI와 다르면 자동 거부 |
"verify_exp": True |
단기 TTL 토큰의 만료를 엄격히 검사 |
scope 검증 |
도구별 스코프 분리로 횡적 이동(Lateral Movement) 방지 |
| JWKS 캐싱 주석 | 프로덕션 적용 전 반드시 캐싱 레이어 추가 필요 |
예시 2: 도구 호출 시 동적 토큰 요청 (TypeScript MCP 클라이언트)
에이전트 측에서 도구 호출 직전마다 좁은 스코프 토큰을 요청하는 패턴입니다.
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";
interface TokenRequest {
resource: string; // RFC 8707: 대상 서버 URI
scope: string; // 도구별 최소 권한
}
/**
* client_credentials 그랜트로 단기 토큰을 요청합니다.
*
* 참고: PKCE(code_verifier/code_challenge)는 authorization_code 플로우에서만
* 사용합니다. client_credentials 그랜트에는 적용되지 않습니다(RFC 7636).
* 사용자 인가가 필요한 플로우라면 별도로 PKCE를 적용한 authorization_code
* 플로우를 사용하세요.
*/
async function requestEphemeralToken(req: TokenRequest): 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: "client_credentials",
resource: req.resource, // ← RFC 8707
scope: req.scope,
client_assertion_type:
"urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
client_assertion: await generateClientAssertion(),
}),
});
const { access_token } = await response.json();
return access_token;
}
/**
* authorization_code 플로우에서 PKCE를 사용할 경우,
* code_verifier는 RFC 7636 §4.1에 따라 43-128자의 Base64URL 문자열이어야 합니다.
* crypto.randomUUID()는 엔트로피가 충분하지 않으므로 아래 방식을 사용하세요.
*/
function generateCodeVerifier(): string {
const array = new Uint8Array(32);
crypto.getRandomValues(array);
return btoa(String.fromCharCode(...array))
.replace(/\+/g, "-")
.replace(/\//g, "_")
.replace(/=/g, "");
}
async function callToolWithEphemeralToken(
toolName: string,
toolArgs: Record<string, unknown>
) {
const toolScopeMap: Record<string, { scope: string; ttl: number }> = {
"read_file": { scope: "tool:files:read", ttl: 300 },
"write_file": { scope: "tool:files:write", ttl: 180 },
"execute_code": { scope: "tool:code:execute", ttl: 120 },
};
const toolConfig = toolScopeMap[toolName];
if (!toolConfig) throw new Error(`알 수 없는 도구: ${toolName}`);
// 1. 도구 호출 직전 단기 토큰 요청
const token = await requestEphemeralToken({
resource: "https://mcp-server.example.com",
scope: toolConfig.scope,
});
// 2. 토큰을 헤더에 담아 MCP 도구 호출
// 참고: 이 예시는 도구 호출마다 새 연결을 생성합니다.
// 프로덕션에서는 연결을 재사용하고 토큰만 갱신하는 방식이 일반적입니다.
const transport = new StdioClientTransport({
command: "mcp-server",
env: { MCP_AUTH_TOKEN: token },
});
const client = new Client({ name: "agent", version: "1.0.0" }, {});
await client.connect(transport);
const result = await client.callTool({ name: toolName, arguments: toolArgs });
await client.close();
return result;
}예시 3: 멀티 에이전트 위임 체인 — 폭발 반경 제한 시나리오
퍼블리싱 에이전트가 침해되는 최악의 시나리오를 가정합니다. Ephemeral Scoped Token이 있다면 피해가 어떻게 봉쇄되는지 비교합니다.
import httpx
# 취약한 방식: 장기 API 키 사용
headers_unsafe = {
"Authorization": f"Bearer {LONG_LIVED_API_KEY}",
# 만료: 없음, 범위: 전체, 대상: 모든 서비스
}
# 안전한 방식: Ephemeral Scoped Token + RFC 8707
async def publish_post_safely(post_content: str) -> dict:
"""
scope=create:post, TTL=60초로 발급된 토큰만 사용.
토큰이 탈취되더라도:
- 60초 후 자동 만료
- dev.to 서버 외 재사용 불가 (aud 클레임)
- 새 글 생성 외 다른 작업 불가 (scope 제한)
request_ephemeral_token()은 클라이언트 측 토큰 요청 함수입니다.
시그니처:
async def request_ephemeral_token(
resource: str, # RFC 8707 대상 서버 URI
scope: str, # 최소 권한 스코프
ttl: int # 토큰 수명 (초)
) -> str: ...
예시 2의 requestEphemeralToken()과 동일한 역할을 Python으로 구현한 것입니다.
"""
token = await request_ephemeral_token(
resource="https://dev.to/api",
scope="create:post",
ttl=60 # 60초 TTL
)
async with httpx.AsyncClient() as client:
response = await client.post(
"https://dev.to/api/articles",
headers={"Authorization": f"Bearer {token}"},
json={"article": {"title": "...", "body_markdown": post_content}}
)
return response.json()| 시나리오 | 장기 API 키 유출 시 | Ephemeral Token 유출 시 |
|---|---|---|
| 유효 기간 | 무기한 | 최대 60초 |
| 접근 가능 서비스 | 키가 허용하는 모든 서비스 | dev.to만 (aud 고정) |
| 가능한 작업 | 모든 API 작업 | 글 생성 1건만 |
| 피해 범위 | 계정 전체 탈취 | 단일 게시물 생성 1회 |
장단점 분석
장점
| 항목 | 내용 |
|---|---|
| 토큰 미스리딤션 방지 | aud 클레임이 특정 서버 URI로 고정되어 토큰 재사용 공격을 원천 차단 |
| 폭발 반경 최소화 | 단기 TTL + 좁은 스코프로 침해 시 피해를 특정 작업·시간으로 한정 |
| 인간 감독 가능 | 증분 동의(Incremental Consent)로 에이전트의 고위험 스코프 요청 시 사용자 승인 단계 삽입 가능 |
| 감사 추적 | act 클레임 기반 위임 체인이 모든 행위를 최초 인가 주체까지 역추적 가능 |
| 표준 호환성 | IETF 표준(RFC 8707, 8693, 9728) 기반으로 특정 벤더에 종속되지 않음 |
| 규정 준수 | 2026-03-15 MCP 명세에서 RFC 8707 구현이 클라이언트 MUST로 격상됨 |
단점 및 주의사항
| 항목 | 내용 | 대응 방안 |
|---|---|---|
| 구현 복잡도 | Authorization Server, Resource Server, Token Introspection, Dynamic Registration 등 다수 엔드포인트 필요 | Scalekit, Auth0 Token Vault, ZITADEL 같은 전문 플랫폼 활용 |
| 토큰 갱신 오버헤드 | TTL이 수 분이면 도구 호출마다 재발급 요청이 빈번해져 지연 발생 | 토큰 캐싱 + 선제적 갱신(proactive refresh) 전략 적용 |
| 단일 장애점 | Auth Server 다운 시 모든 에이전트 작동 중단 | HA(고가용성) 구성 + 토큰 인트로스펙션 결과 캐싱 |
| 낮은 현장 채택률 | MCP 서버 대부분이 여전히 장기 API 키 사용 | Dynamic Client Registration(RFC 7591)으로 마이그레이션 비용 완화 |
| 스코프 설계 난이도 | 너무 세분화하면 관리 복잡도 폭증, 너무 넓으면 최소 권한 원칙 위반 | 도구 위험도별 3~5단계 스코프 계층 설계 권장 |
| Clock Skew | 단기 TTL 토큰은 서버 간 시각 동기화 오차에 민감 | NTP 동기화 필수, nbf 클레임에 60초 여유 설정 |
Clock Skew: 분산 시스템에서 서버들의 시계가 미세하게 다를 때 발생하는 시각 차이. TTL이 2분인 토큰에서 30초의 clock skew는 실질적인 유효 시간을 절반으로 줄일 수 있습니다.
Dynamic Client Registration(RFC 7591): 에이전트가 처음 MCP 서버를 만날 때 사전 등록 없이 자율적으로 클라이언트 ID를 발급받는 프로토콜. M개의 에이전트 × N개의 서버 조합을 사전에 모두 등록해야 하는 M×N 문제를 해소합니다.
실무에서 가장 흔한 실수
aud클레임 검증을 생략하는 경우 — JWT 서명만 확인하고aud를 검증하지 않으면 RFC 8707을 적용해도 토큰 미스리딤션 공격에 그대로 노출됩니다. Resource Server 측에서 반드시audience=자신의_URI로 디코드해야 합니다. Python이라면jwt.decode(..., audience="https://your-mcp-server.example.com")이 출발점입니다.- TTL을 길게 설정하는 경우 — 구현 편의를 위해 TTL을 24시간으로 설정하면 "단기 토큰" 패턴의 의미가 사라집니다. 도구 유형별로 위험도에 따른 TTL 정책(저위험: 5분, 중위험: 2분, 고위험: 1분 + 인간 승인)을 문서화하고 준수하는 것이 효과적입니다.
- 스코프를 너무 넓게 설정하는 경우 —
scope=*또는scope=admin처럼 포괄적인 스코프를 하나의 에이전트에 부여하면 최소 권한 원칙이 무력화됩니다. 에이전트가 실제로 호출하는 도구 목록을 기준으로 스코프를 설계하는 접근 방식이 좋습니다.
마치며
RFC 8707 Resource Indicators와 Ephemeral Scoped Token 패턴은 AI 에이전트 시대의 최소 권한 원칙을 실현하는 가장 실용적인 표준 기반 접근법입니다.
이 패턴의 핵심은 단순합니다. 토큰에 "누가, 어디서, 무엇을, 언제까지"라는 4가지 제약을 각인하면, 에이전트가 침해되더라도 공격자가 얻는 것은 수 분짜리, 단 하나의 서버에서만, 하나의 작업만 가능한 토큰 한 장입니다.
구현을 시작하기 전에 팀이 먼저 결정해야 할 아키텍처 수준의 질문이 있습니다. Authorization Server를 관리형 서비스(Auth0, ZITADEL, Scalekit 등)로 선택할지, 자체 구축할지에 따라 RFC 8707 지원 여부와 구현 일정이 크게 달라집니다. 이 선택을 먼저 확정한 뒤 아래 단계로 이어지는 것이 효율적입니다.
2026년 3월 MCP 명세에서 RFC 8707이 클라이언트 MUST로 격상되었습니다. 단순한 권고를 넘어서는 이유가 있습니다. 이 요건을 구현하지 않은 MCP 클라이언트는 명세를 준수하는 서버와의 호환성 문제가 발생할 수 있고, 기업 환경에서는 보안 감사 실패로 이어질 수 있습니다.
지금 시작할 수 있는 3단계:
- 기존 MCP 서버의 토큰 검증 코드를 점검해 보시면 좋습니다.
aud클레임을 자신의 서버 URI로 검증하고 있는지 확인하고, 없다면 JWT 디코드 로직에audience파라미터를 추가하는 것부터 시작할 수 있습니다. - 에이전트가 호출하는 도구 목록을 정리하고, 각각에
tool:{domain}:{action}형식의 스코프와 TTL 정책을 매핑하는 문서를 작성하면 이후 구현 시 일관성을 유지하기 쉽습니다. - mcp-auth.dev Quick Start를 따라 OAuth 2.1을 기존 MCP 서버에 플러그인 형태로 붙여볼 수 있습니다. 처음부터 Authorization Server를 직접 구축하는 것보다, RFC 8707을 지원하는 관리형 플랫폼을 활용해 토큰 발급 부분을 위임하고 Resource Server 검증 로직에 먼저 집중하는 방식이 진입 장벽을 낮춰줍니다.
다음 글: RFC 9728 Protected Resource Metadata를 활용해 MCP 클라이언트가 서버의 인증 요구사항을 자동 탐색(Auto-Discovery)하는 Zero-Config 인증 아키텍처 구현 방법
참고 자료
- The New MCP Authorization Specification | dasroot.net
- Authorization - Model Context Protocol 공식 명세 | modelcontextprotocol.io
- MCP, OAuth 2.1, PKCE, and the Future of AI Authorization | Aembit
- OAuth 2.0 Resource Indicators (RFC 8707) Explained | Scalekit
- RFC 8707: Resource Indicators for OAuth 2.0 | IETF
- RFC 8693: OAuth 2.0 Token Exchange | IETF
- MCP Authentication and Authorization Implementation Guide | Stytch
- Authorization for MCP: OAuth 2.1, PRMs, and Best Practices | Oso
- MCP Spec Updates from June 2025 | Auth0
- OAuth for MCP: Emerging Enterprise Patterns for Agent Authorization | GitGuardian
- Ephemeral Authentication: Securing Autonomous AI Workflows | AI Journal
- Auth0 Token Vault: Secure Token Exchange for AI Agents | Auth0
- Credential Risks Across 5,200 MCP Servers | NHIMG
- Design MCP Authorization to Securely Expose APIs | Curity
- Secure your MCP servers: Implement OAuth 2.1 | Scalekit
- MCP Auth 공식 문서 | mcp-auth.dev