Tetrate and Ory bring parameter checks to MCP authorization
Tetrate and Ory announced AI agent authorization that can enforce policy on MCP tool-call request parameters, not just tool visibility.
- What happened: Tetrate and Ory announced a strategic partnership for AI agent authorization on June 3, 2026.
- The integration pairs Ory's identity and authorization layer with Envoy-based gateway enforcement in Tetrate Agent Router Enterprise.
- Technical point: The control plane moves beyond hiding or allowing an MCP tool and evaluates
request parametervalues at runtime.- A refund tool can stay available for small adjustments while requiring step-up approval and short-lived elevated access for a larger refund.
- Builder impact: Production agent design now has to connect tool schema, user identity, agent identity, approval logs, and gateway policy in one path.
- Watch: Parameter-level enforcement does not replace agent inventory, technical documentation, security testing, or post-deployment monitoring.
Tetrate and Ory announced a strategic partnership for enterprise AI agent security on June 3, 2026. The announcement says Ory's identity and authorization platform will be combined with Tetrate Agent Router Enterprise so policies can be enforced when production agents call models, tools, and enterprise services. For engineering teams building around MCP, the question shifts from "which tools can this agent see?" to "which values may this agent pass when it invokes this tool?"

The announcement argues that many MCP runtimes stop at tool visibility or allowlists. The Tetrate and Ory pairing instead says it will evaluate every live request and inspect the parameters inside MCP tool calls. A refund tool should not treat a $20 refund and a $20,000 refund as the same authorization event. A transfer tool should not treat an internal account movement, a high-risk destination, and a large outbound transfer as one permission. This partnership moves that distinction out of the prompt and into a runtime gateway plus an authorization engine.
The architecture is split across two layers. Ory treats the agent and the user as first-class identities, uses Ory Hydra for OAuth2 and OIDC token flows, and uses Ory Keto for least-privilege authorization decisions. Tetrate enforces decisions in Tetrate Agent Router Enterprise, an Envoy-based gateway that sits in front of live requests, model calls, MCP tool calls, and enterprise service calls. The announcement describes a flow where Tetrate can pause a high-risk request, trigger an authentication or approval path through Ory, issue short-lived elevated access, and record the approval path for audit.
That structure matters because MCP tools are starting to represent real business APIs, not just search helpers. A customer-support agent may adjust account credits. An IT operations agent may create a production change. An HR agent may read or update personnel data. If authorization is attached only to the tool name, the blast radius becomes too broad. Allowing issueRefund as a whole gives the same permission to a small goodwill credit and a large cash refund.
| Authorization basis | Tool allowlist model | Parameter-level runtime enforcement |
|---|---|---|
| Decision unit | Decides which MCP tools an agent can see or call. | Evaluates values such as amount, destination, record type, and blast radius at call time. |
| Approval path | An allowed tool call often proceeds without further review. | A request crossing a risk threshold can require step-up approval and temporary elevated access. |
| Audit record | Centers on whether a tool call succeeded or failed. | Records who approved the action and which parameter caused elevation. |
| Operational question | Asks whether this agent may use the refund tool. | Asks whether this agent, acting for this user, may refund this amount to this customer. |
Tetrate's listed use cases include retail, financial services, healthcare, government, customer support, IT operations, and HR. In retail, an agent may process refunds inside an approved limit while larger refunds require additional approval because the refund amount parameter changes the risk. In financial services, routine transfers can continue while larger amounts or high-risk destinations trigger a different policy. In IT operations, low-risk automation can run automatically while production changes or privileged access requests require step-up authorization.
This is a different layer from a network-oriented MCP gateway such as NetFoundry's. NetFoundry's MCP Gateway focuses on reducing exposed public inbound ports, shared secrets, and provider-specific endpoint exposure. Tetrate and Ory are dealing with authorization semantics after traffic reaches the gateway. The question is not only which service path an agent may take, but which request values remain permitted inside that path. The two approaches are complementary layers in a production agent stack.
It also differs from AI coding security products such as Salt Code. Salt Code injects organizational security policy into assistants like Claude Code, Cursor, Copilot, and Codex through context and MCP configuration while code is being generated. Tetrate and Ory focus on execution-time business actions after an agent has already been deployed and is calling MCP servers or enterprise APIs on behalf of a user. One side tries to shape the generated code and assistant behavior; the other creates an authorization and audit path for runtime tool calls.
Tetrate's Agent Router product page shows the broader gateway strategy around this announcement. Agent Router is described as a gateway for model providers, MCP servers, team and agent token budgets, SSO, observability, and runtime guardrails. The product page lists Anthropic, OpenAI, Google Vertex AI, AWS Bedrock, Azure OpenAI, Mistral AI, Baseten, and self-hosted models among supported model targets. On the agent framework side, it names LangChain, LangGraph, Claude Code, Agentforce, CrewAI, AutoGen, Pydantic AI, and OpenAI-compatible SDKs. The Ory integration adds identity and authorization decisions to that gateway surface.
The Envoy foundation is not just an implementation detail. The announcement says Tetrate is a major contributor to Envoy and Envoy Gateway, and that Agent Router Enterprise is based on Envoy AI Gateway. An AI gateway that does more than reverse proxy traffic has to coordinate latency, retries, failover, routing, policy, audit, and distributed deployment. The announcement also says Ory previously used Tetrate Enterprise Gateway for Envoy to reduce resource use by 40%. That number is not a standalone benchmark for AI agent security, but it shows the two companies had an infrastructure relationship before this authorization launch.
Research is pointing at the same control problem. The Tool Forge paper posted to arXiv on May 27, 2026 proposes intent-scoped tool sessions and an MCP-facing routing model for governed agentic execution. Instead of placing the full tool catalog into the model context, it limits execution through verified tool chains and a router. A separate MCP threat-modeling paper published on March 23, 2026 analyzes the MCP host, client, LLM, MCP server, external datastore, and authorization server with STRIDE and DREAD. That paper calls out weak static validation and limited parameter visibility as MCP security issues. Tetrate and Ory's parameter-level control is the product-language version of that research concern.
Community reaction to this specific announcement is still limited. I did not find evidence that the Tetrate and Ory launch had already produced a major Hacker News front-page debate. A related Hacker News discussion from 16 days earlier about an open-source EU AI Act compliance layer for AI agents repeatedly argued that audit trails alone do not satisfy high-risk AI governance. Commenters pointed to human oversight, Annex IV technical documentation, risk classification, and override ability as separate architecture work. That critique applies here as well: parameter-level enforcement can reduce unsafe calls, but it does not replace agent inventory, documentation, test records, or governance procedures.
The practical checklist for engineering teams has four parts. First, agent identity and user identity need to be separated. Teams have to define whom the agent represents, which service principal it uses for tool calls, and how those two identities are tied together in tokens and audit logs. Second, MCP tool schemas become authorization inputs. If parameters do not express risk clearly, a gateway cannot apply meaningful value-level policy. Third, step-up approval requires user experience and operations design. Pausing a request is useful only if the system knows who can approve it and how long the elevation remains valid. Fourth, denial and failure paths need tests. Teams should verify what an agent does when approval is rejected, a token expires, or a policy mismatch occurs.
Product buyers should ask more specific questions than whether the platform supports MCP authorization. How does Ory Keto receive MCP parameters, especially nested JSON values or fields that contain personal data? What policy-decision latency is added to long-running agent loops? Where exactly does the Tetrate gateway pause the request before and after a tool call? If a tool streams results or triggers a long-running action, what rollback or cancellation behavior exists? Can audit logs flow into SIEM and OpenTelemetry pipelines, and do approval records bind the user session and agent session together?
The announcement should not be read as a complete answer to MCP security. Prompt injection can still drive an agent to misuse a legitimate tool. MCP server supply-chain risk, tool description poisoning, local credential leakage, and agent memory poisoning require separate controls. Tetrate and Ory are addressing one specific moment in the runtime path: an approved tool is about to execute with real business values. That is still a practical control point because the most damaging agent failures are often not caused by seeing the wrong tool, but by calling an allowed tool with the wrong amount, destination, record, or privilege.
Teams moving agents from internal demos into business systems should be uncomfortable with an MCP allowlist alone. Tools such as refund, transfer, updateEmployeeRecord, and deployToProduction are risky because of their arguments, not just their names. The operational question from this announcement is simple: can your agent runtime stop a call based on the request values and delegated identity, or can it only block the tool name? Without that answer, agent authorization remains closer to API keys and prompt promises than to enforceable production policy.