Tetrate·Ory MCP 권한 제어, 도구 호출 값까지 검문

AI 요약

• 무슨 일: Tetrate와 Ory가 2026년 6월 3일 AI 에이전트용 권한 제어 파트너십을 발표했습니다.
  • Ory의 identity·authorization 계층과 Tetrate Agent Router Enterprise의 Envoy 기반 gateway enforcement를 결합합니다.
• 기술 포인트: MCP tool을 허용하거나 숨기는 수준을 넘어 request parameter 값까지 정책 대상으로 삼습니다.
  • 예를 들어 같은 refund tool이라도 환불 금액이 커지면 step-up approval과 short-lived elevated access가 필요해집니다.
• 개발자 영향: production agent 설계에서 tool schema, user identity, agent identity, approval log가 한 흐름으로 묶입니다.
• 주의점: parameter-level enforcement는 agent inventory, 기술 문서, 테스트 기록, 사후 모니터링을 대신하지 않습니다.

Tetrate와 Ory가 2026년 6월 3일 AI 에이전트 보안을 위한 전략적 파트너십을 발표했습니다. 발표문은 Ory의 identity·authorization platform과 Tetrate Agent Router Enterprise를 결합해, production agent가 model, tool, enterprise service를 호출하는 순간 정책을 적용한다고 설명합니다. 개발팀 관점에서 볼 변화는 분명합니다. MCP 보안의 질문이 "이 에이전트가 어떤 tool을 볼 수 있는가"에서 "이 tool을 어떤 값으로 호출해도 되는가"로 내려갑니다.

발표 자료는 많은 MCP runtime이 tool visibility나 allowlist를 결정하는 데 머문다고 지적합니다. Tetrate·Ory 조합은 live request마다 정책을 평가하고, MCP tool call의 parameter까지 확인하겠다고 말합니다. 같은 refund tool이라도 20달러 환불과 2만 달러 환불은 다른 승인 절차를 가져야 합니다. 같은 transfer tool이라도 내부 계좌 이체, 고위험 목적지, 큰 금액의 송금은 다른 정책 객체입니다. 이 차이를 model prompt가 아니라 runtime gateway와 authorization engine의 책임으로 옮기는 발표입니다.

구성은 두 계층으로 나뉩니다. Ory는 agent와 user를 first-class identity로 다루고, OAuth2·OIDC token flow를 Ory Hydra로 관리하며, Ory Keto가 least-privilege access policy를 결정합니다. Tetrate는 Envoy 기반 Tetrate Agent Router Enterprise에서 live request, model call, MCP tool call, enterprise service call을 enforcement 대상으로 삼습니다. 발표문은 위험 임계값을 넘는 호출에서 Tetrate가 request를 멈추고, Ory를 통한 authentication·approval flow를 일으킨 뒤, short-lived elevated access와 approval path audit record를 남길 수 있다고 설명합니다.

이 구조가 필요한 이유는 MCP tool이 단순 검색 보조 기능을 넘어서기 때문입니다. 기업 agent가 customer support, IT operations, HR, finance, healthcare workflow에 들어가면 tool은 실제 업무 API가 됩니다. 고객지원 agent는 account credit을 조정하고, IT agent는 production change를 만들며, HR agent는 personnel record를 읽을 수 있습니다. 이때 tool 이름만으로 권한을 정하면 blast radius가 큽니다. 정책이 issueRefund 전체를 허용하면 작은 보상 처리와 대형 환불이 같은 권한으로 묶입니다.

Tetrate가 든 사용 사례는 retail, financial services, healthcare, government, customer support, IT operations, HR입니다. retail agent는 승인된 금액 안에서 환불을 처리할 수 있지만, 더 큰 환불은 환불 금액 parameter 때문에 추가 승인을 요구합니다. financial services agent는 routine transfer를 처리할 수 있지만, 큰 금액이나 고위험 목적지에서는 다른 정책을 탑니다. IT operations agent는 저위험 자동화는 실행하되 production change나 privileged access request에는 step-up authorization을 붙입니다.

이 발표는 NetFoundry의 MCP Gateway처럼 네트워크 경로를 닫는 이야기와 다릅니다. NetFoundry가 public inbound port, shared secret, provider별 endpoint 노출을 줄이는 쪽에 초점을 맞췄다면, Tetrate·Ory 발표는 이미 gateway를 통과한 호출의 authorization semantics를 다룹니다. 어느 agent가 어떤 service path를 탈 수 있는가뿐 아니라, 같은 path 안에서 어떤 request 값이 허용되는가를 묻습니다. 둘은 대체 관계라기보다 production agent stack의 다른 층입니다.

Salt Code 같은 AI coding security 제품과도 구분됩니다. Salt Code는 Claude Code, Cursor, Copilot, Codex 같은 assistant가 코드를 만들 때 조직의 보안 정책을 context와 MCP configuration으로 주입하는 방향입니다. Tetrate·Ory는 생성 단계의 코드 품질이 아니라 실행 단계의 business action을 봅니다. agent가 이미 배포됐고, user를 대신해 MCP server와 enterprise API를 호출하는 상황에서 권한과 감사 경로를 만들겠다는 접근입니다.

Tetrate Agent Router 제품 페이지를 보면 이 회사의 더 넓은 의도가 보입니다. Agent Router는 model provider, MCP server, team·agent별 token budget, SSO, observability, runtime guardrail을 한 gateway 앞에 묶는 제품으로 설명됩니다. 지원 대상으로 Anthropic, OpenAI, Google Vertex AI, AWS Bedrock, Azure OpenAI, Mistral AI, Baseten, self-hosted model이 언급됩니다. agent framework 쪽에는 LangChain, LangGraph, Claude Code, Agentforce, CrewAI, AutoGen, Pydantic AI, OpenAI-compatible SDK가 들어갑니다. 이번 Ory 결합은 그 gateway에 identity와 authorization decision을 더 얹는 발표입니다.

Envoy 기반이라는 점도 그냥 구현 세부사항은 아닙니다. 발표문은 Tetrate가 Envoy와 Envoy Gateway의 주요 contributor이며, Agent Router Enterprise가 Envoy AI Gateway 기반이라고 설명합니다. AI gateway가 단순 reverse proxy를 넘어서려면 latency, retry, failover, routing, policy, audit, distributed deployment가 함께 움직여야 합니다. Ory가 이전에 Tetrate Enterprise Gateway for Envoy를 사용해 resource use를 40% 줄였다는 내용도 발표문에 들어 있습니다. 이 숫자는 AI agent 보안 기능의 독립 성능 지표는 아니지만, 두 회사 관계가 이번 발표에서 갑자기 생긴 marketing tie-up은 아니라는 근거로 읽을 수 있습니다.

연구 쪽에서도 비슷한 문제가 제기됩니다. 2026년 5월 27일 arXiv에 올라온 Tool Forge 논문은 governed agentic execution을 위해 intent-scoped tool session과 MCP-facing routing model을 제안합니다. 전체 tool catalog를 model context에 실어주는 대신, 검증 가능한 tool chain과 router를 통해 agent 실행을 제한하자는 방향입니다. 2026년 3월 23일 공개된 MCP threat modeling 논문은 MCP host, client, LLM, MCP server, external datastore, authorization server를 STRIDE와 DREAD로 나눠 분석합니다. 이 논문은 static validation과 parameter visibility 부족을 MCP 보안 이슈로 지적합니다. Tetrate·Ory 발표가 제품 언어로 말한 parameter-level control은 이 연구 문제와 직접 닿아 있습니다.

커뮤니티 반응은 아직 제한적입니다. 이번 발표 자체가 HN 전면에서 큰 토론을 만든 흔적은 확인하지 못했습니다. 다만 16일 전 HN에 올라온 EU AI Act compliance layer for AI agents 토론에서는 audit trail, human oversight, technical documentation이 runtime logging만으로 해결되지 않는다는 지적이 반복됐습니다. 댓글들은 high-risk system 분류, Annex IV documentation, human override ability가 별도 설계 대상이라고 봤습니다. 이 관점은 Tetrate·Ory에도 그대로 적용됩니다. parameter-level enforcement는 호출을 줄이는 장치이지, agent governance 전체를 완성하는 문서 체계는 아닙니다.

개발팀이 이 발표에서 가져갈 체크리스트는 네 가지입니다. 첫째, agent identity와 user identity를 분리해야 합니다. 에이전트가 누구를 대리하는지, 어떤 service principal로 tool을 호출하는지, 두 identity가 token과 audit log에서 어떻게 연결되는지 정해야 합니다. 둘째, MCP tool schema는 권한 설계의 입력입니다. parameter가 risk를 표현하지 못하면 gateway가 값 단위 정책을 적용하기 어렵습니다. 셋째, step-up approval은 UI와 운영 절차가 필요합니다. 호출을 멈출 수 있어도 누가 승인하고 어떤 시간 동안 elevation이 유효한지 없으면 감사 항목이 비어 있습니다. 넷째, override와 실패 경로를 테스트해야 합니다. agent가 승인 거절, token 만료, policy mismatch를 만났을 때 같은 tool을 다른 값으로 재시도하는지 확인해야 합니다.

제품 구매자 입장에서는 질문이 더 구체적이어야 합니다. Ory Keto policy가 MCP parameter를 어떤 shape으로 받는지, nested JSON이나 PII field를 어떻게 다루는지, policy decision latency가 긴 agent loop에 어떤 영향을 주는지 확인해야 합니다. Tetrate gateway가 tool call 전후 어느 지점에서 request를 멈추는지, streamed tool result나 long-running action에서 rollback이 가능한지도 봐야 합니다. audit log는 SIEM과 OTEL pipeline으로 나가는지, approval record가 user session과 agent session을 함께 묶는지도 배포 전에 확인할 항목입니다.

이번 발표를 과장해 읽을 필요는 없습니다. Tetrate와 Ory가 모든 MCP 보안 문제를 해결했다고 말할 수는 없습니다. prompt injection으로 agent가 합법 tool을 악용하는 문제, MCP server supply chain, tool description poisoning, local credential leakage, agent memory poisoning은 별도 방어가 필요합니다. 그래도 이번 발표가 짚은 지점은 현실적입니다. production agent에서 가장 위험한 순간은 tool 목록을 보여주는 때가 아니라, 승인된 tool이 실제 업무 값을 들고 호출되는 때입니다. Tetrate·Ory의 파트너십은 그 순간을 gateway와 authorization engine의 명시적인 책임으로 만들겠다는 제안입니다.

AI 에이전트를 사내 실험에서 업무 시스템으로 옮기는 팀이라면 MCP allowlist만으로 만족하기 어렵습니다. refund, transfer, updateEmployeeRecord, deployToProduction 같은 tool은 이름보다 값이 위험을 결정합니다. 이번 발표가 남기는 실무 질문은 단순합니다. 우리 agent runtime은 tool 이름을 막는가, 아니면 호출 값과 대리 identity까지 보고 멈출 수 있는가. 이 질문에 답하지 못하면 agent 권한은 여전히 API key와 prompt 약속에 가까운 상태로 남습니다.