Skip to main content
The OWASP MCP Top 10 identifies the most critical security risks in Model Context Protocol deployments. As AI agents interact with enterprise systems through MCP, new attack surfaces emerge — from token mismanagement and privilege escalation to shadow servers and context injection. The Maverics Orchestrator in AI Identity Gateway mode addresses several of these risks directly. Using a second Orchestrator as an Auth Provider (OIDC Provider) with per-tool token exchange, it provides identity, authorization, and audit controls for every MCP interaction. This page maps each OWASP MCP risk to the specific capabilities that mitigate it — and is transparent about where complementary controls are needed.
Disclaimer: This page is provided for informational purposes only and does not constitute a guarantee of security, compliance, or complete risk mitigation. The mappings described here reflect general architectural capabilities and may not apply to every deployment topology or configuration. Security outcomes depend on proper configuration, organizational governance, and complementary controls. Customers are responsible for evaluating their own security posture, conducting independent assessments, and implementing appropriate controls for their specific environment. Strata Identity makes no warranties regarding the completeness or accuracy of these mappings.
The AI Identity Gateway operates at the identity and authorization layer — authentication, token management, policy enforcement, telemetry, and auditing. Some OWASP MCP risks target the AI model layer (prompt injection, intent manipulation, context memory). For those risks, the gateway limits the blast radius and enables detection, but prevention requires complementary controls at the model and application layers.

​
Coverage Summary

OWASP RiskCoverageHow the AI Identity Gateway Addresses It
MCP01 — Token MismanagementDirectly addressesUpstream services never see long-lived or over-scoped tokens. Per-tool token exchange mints short-lived, scoped tokens with customizable TTLs (e.g., 5s). The agent’s original token is never forwarded to upstream services.
MCP02 — Privilege EscalationReduces attack surfacePer-tool scopes and short-lived tokens prevent runtime scope accumulation. OPA policies and token minting policies enforce configured boundaries. Configuration-level scope creep (admins gradually broadening permissions) requires organizational governance.
MCP03 — Tool PoisoningReduces attack surfaceThe gateway only serves tools from OpenAPI specs and MCP servers that your organization explicitly registers — no public registries or auto-discovery. OPA policies can validate tool arguments before they reach upstream services. Tool namespacing mitigates shadowing.
MCP04 — Supply Chain AttacksReduces attack surfaceThe Orchestrator is a single binary with no plugin marketplace or dependency resolution. Upstream servers and APIs are explicitly registered in configuration. Complementary controls needed for SBOM and dependency scanning of your own services.
MCP05 — Command InjectionDirectly addresses (gateway layer)The gateway forwards structured protocol messages (MCP or REST) to upstream services, never executes commands or code. OPA policies can inspect and reject malicious tool argument values before they reach upstream services.
MCP06 — Intent Flow SubversionLimits blast radiusEven if an agent is subverted, OPA policies constrain which tools it can invoke and what arguments it can pass. Delegation tokens enforce both the agent’s and the delegating user’s permissions on upstream services. Auditing enables detection. Prevention requires AI model-layer controls.
MCP07 — Insufficient AuthDirectly addressesUpstream services are protected by multi-layer auth: OAuth 2.0 agent authentication, OPA policies on every tool call, per-tool token exchange with scoped delegation tokens, and token minting policies. This is the core problem the gateway was built to solve.
MCP08 — Lack of AuditDirectly addressesEvery tool call to an upstream service is logged with agent identity, user identity, tool name, parameters, and outcome. Structured JSON for SIEM. Downstream analysis and tamper protection depend on SIEM configuration.
MCP09 — Shadow MCP ServersDirectly addresses (gateway layer)Agents access upstream services only through the centralized gateway. Upstream servers are explicitly registered. Network isolation prevents agents from bypassing the gateway. Discovering rogue servers in the org requires separate tooling.
MCP10 — Context Injection & Over-SharingReduces attack surfaceUpstream services are protected from cross-context access — each tool invocation gets its own scoped token, and sessions are isolated per agent. Model-layer context memory isolation requires complementary controls.

​
Risk Details

OWASP risk: Tokens and credentials serve as the primary means of authentication and authorization in MCP systems. Developers frequently embed secrets improperly, creating “contextual secret leakage” where protocols themselves become unintentional credential repositories. Long-lived sessions and context persistence compound the problem. Attackers retrieve tokens through prompt injection, log scraping, or context poisoning — leading to complete infrastructure compromise, lateral movement across integrated services, and data exfiltration.Coverage: Directly addressesThe Orchestrator’s per-tool token exchange protects upstream services by ensuring they never receive long-lived or over-scoped tokens:
  • Per-tool token exchange — Every tool invocation triggers a fresh token exchange. The gateway mints a new delegation token with only the scopes that tool needs and a customizable TTL (e.g., 5s). A different tool call a moment later gets a completely different token with different scopes.
  • No token forwarding — The gateway never passes the agent’s original token to upstream services. Every upstream call uses a freshly minted, minimally scoped delegation token. The agent’s primary token never reaches the backend.
  • Inbound delegation support — Agents can optionally perform a token exchange before connecting to the gateway, producing a token with the user as the subject and the agent as the actor (act claim). Regardless of whether this inbound exchange happens, the gateway always performs its own outbound token exchange for each tool call.
The protection profile varies depending on your deployment topology. When the upstream service is another AI agent, short TTLs and scoped tokens are especially critical — a compromised downstream agent with a long-lived, broadly scoped token could leverage that access far more aggressively than a traditional API consumer would. When the upstream is a REST API, the same token constraints protect against token reuse and lateral movement, but the attack vectors differ. The gateway’s per-tool token exchange addresses both scenarios by ensuring that no upstream service — agent or API — ever receives more access than a single tool invocation requires.
OWASP risk: Scope creep occurs when narrowly scoped permissions granted to an MCP agent expand over time — intentionally for convenience or accidentally through configuration drift — until the agent holds broad or administrative privileges. This enables unauthorized code modifications, unreviewed deployments, full environment control through service account impersonation, and regulatory violations. The risk is amplified by autonomous agent execution paths that compound incremental permission increases.Coverage: Reduces attack surfaceThe Orchestrator prevents runtime scope accumulation, but configuration-level scope creep — where admins gradually broaden permissions over time — is an organizational governance problem the gateway cannot solve on its own. What the gateway does is make scope boundaries explicit, auditable, and enforceable at runtime:
  1. Per-tool scopes — Each tool has an explicit, declarative scopes list. Scopes are defined in configuration, not accumulated at runtime. A listUsers tool gets user:List; a createUser tool gets user:Create. Adding a new scope requires a deliberate configuration change, which flows through your change management process.
  2. Automatic token expiry — Every minted token has a TTL measured in seconds. Permissions cannot accumulate over time because each token is destroyed before the next one is issued. There is no long-lived session where scopes could grow.
  3. OPA inbound policies — Rego policies evaluate every tool invocation with a deny-by-default stance before the request reaches any upstream service. Policy authors have access to tool name, argument names and values, HTTP headers (including the inbound access token, which can be parsed for identity claims), and source IP. The identity claims available in the token depend on the inbound flow — an agent that performed token exchange presents a token with the user as subject and agent as actor, while an autonomous agent presents its own identity token. Policy authors can write arbitrarily granular validation logic against any of this context. For example, a policy can allow createUser only when the role argument is not admin, or restrict deleteItem to specific token subjects. For elevated operations, OPA policies will soon support human-in-the-loop approval, requiring explicit human authorization before the action proceeds. An agent cannot invoke a tool that the policy does not explicitly permit.
  4. Token minting policies — The Auth Provider Orchestrator can apply OPA-based governance over which tokens are issued during exchange. This is a second, independent control point — even if an inbound policy allows a tool call, the Auth Provider can refuse to mint the token if the requested scopes violate minting policy.
OWASP attack scenarios and how the gateway responds:
  • Accidental escalation (temporary repo:write expands to permanent broad access): Scopes are defined declaratively and require a deliberate configuration change to modify, not an ad-hoc runtime grant.
  • Credential harvesting + escalation (long-lived token found in logs, used to grant additional scopes): Delegation tokens minted for upstream calls expire in seconds and cannot be used to request additional scopes. The agent’s own access token should also be configured with an appropriately short TTL on the Auth Provider. The token exchange flow is one-directional — delegation tokens are minted by the Auth Provider for specific tools, not requested or influenced by the agent.
  • Automated policy bypass (attacker updates agent manifest to add admin privileges): The Auth Provider defines the universe of allowed scopes. A tool cannot request a scope that is not registered in the Auth Provider.
Complementary controls needed: The gateway enforces whatever scopes and policies are configured, but does not prevent those configurations from becoming overly permissive over time. OWASP recommends automated scope expiry, periodic entitlement reviews, and separation of duties for configuration changes. These are organizational governance practices that complement the gateway’s runtime enforcement.
See the MCP Bridge authorization and MCP Proxy authorization guides for full configuration details.
OWASP risk: Tool poisoning occurs when an adversary compromises the tools, plugins, or their schemas that an AI model depends on. Techniques include rug pulls (malicious updates to trusted tools), schema poisoning (corrupting interface definitions so legitimate agents execute unintended destructive operations), and tool shadowing (introducing fake or duplicate tools). Impact includes data compromise, privilege escalation, policy circumvention, and audit trail corruption — because logs show valid actions per contract despite the contract being malicious.Coverage: Reduces attack surfaceThe Orchestrator prevents tool poisoning through architectural controls that keep tool definitions under organizational control:
  • Explicitly registered upstream services — Both app types require explicit registration of upstream services. MCP Bridge dynamically generates tools from OpenAPI specifications you provide. MCP Proxy proxies tool calls to upstream MCP servers registered by URL. In both cases, tools come from sources your organization controls — there is no auto-discovery from public registries, third-party marketplaces, or community repositories. Rogue tools cannot enter the catalog because the system only serves tools from explicitly registered upstreams.
  • Tool namespacing — Tool names are prefixed with a configurable namespace (e.g., my_api_listUsers). This mitigates tool shadowing by making the source of each tool identifiable — if two tools share a name, the namespace disambiguates them. Agents see which registered upstream each tool comes from.
  • OPA argument-level validation — Inbound OPA policies inspect tool arguments before any request reaches an upstream service. Policy authors can validate argument names, check argument values against expected patterns, reject unexpected parameters, and enforce business rules — catching anomalous behavior that might indicate a poisoned tool definition before it affects upstream resources.
Complementary controls needed: The Orchestrator does not implement cryptographic schema signing (JWS/COSE/PKI), content-addressable hash verification of tool definitions, or provenance metadata tracking (author, timestamp, approver) on schemas — all recommended by OWASP for this risk. If your threat model includes sophisticated supply chain attackers who could compromise your internal OpenAPI specs or MCP server configurations, implement schema signing and integrity verification in your CI/CD pipeline as a complementary control.
OWASP risk: MCP ecosystems depend on open-source packages, connectors, and model-side plug-ins that may contain malicious or vulnerable components. Attackers target MCP server libraries, third-party plugins, dependency updates, and build pipelines. Compromised dependencies can call unsafe APIs, exfiltrate context data, insert rogue schemas, tamper with tool execution, or silently escalate privileges. These components often appear legitimate and can operate undetected for extended periods.Coverage: Reduces attack surfaceThe Orchestrator’s deployment model eliminates several attack vectors that make MCP supply chain attacks possible:
  • No runtime plugin ecosystem — Unlike MCP frameworks that rely on user-installed plugins, connectors, or community extensions, the Orchestrator does not have a runtime extension mechanism where customers pull packages from public registries. This eliminates the dependency confusion, typosquatting, and registry compromise vectors that OWASP highlights for the gateway layer specifically.
  • Explicit upstream registration — All upstream services are explicitly registered. MCP Proxy connects to upstream MCP servers you configure. MCP Bridge reads OpenAPI specifications from URIs you provide. In neither case does the system auto-discover or auto-install tools from public repositories.
  • Deliberate configuration changes — Tool definitions, authorization policies, and server registrations are defined declaratively. Changes are auditable through your existing change management process.
Complementary controls needed: The gateway adds one component to the deployment (the Orchestrator binary itself), but does not reduce supply chain risk for upstream MCP servers, REST APIs, or the AI agents connecting to it. Each of those systems has its own dependencies, build pipelines, and attack surface. It is the customer’s responsibility to ensure that upstream services, agents, and the Orchestrator deployment all follow standard supply chain security practices — SBOM management, dependency scanning, version pinning, signed builds, and vendor security assessments.
OWASP risk: AI agents construct and execute system commands, shell scripts, API calls, or code snippets using untrusted input without proper validation or sanitization. The attack surface is unique because the agent interprets natural language instructions and translates them into executable operations. Techniques include prompt-driven execution, dynamic command construction through string concatenation, tool-mediated execution via MCP tools wrapping system calls, and chained execution using shell operators.Coverage: Directly addresses (gateway layer)The gateway protects upstream services from command injection by validating and constraining every tool invocation before it is forwarded:
  • Protocol-level gateway, not a command executor — The Orchestrator forwards structured protocol messages to upstream services in both app types. MCP Proxy forwards MCP protocol messages to upstream MCP servers. MCP Bridge translates MCP tool calls into structured REST API requests (HTTP method, URL, headers, body) mapped through the OpenAPI spec. In neither case does the Orchestrator execute shell commands, scripts, or arbitrary code. There is no string concatenation or template injection in the forwarding path.
  • OPA argument-level validation — Inbound OPA policies inspect every tool invocation before it reaches an upstream service. Policy authors have access to tool argument names and values, the tool name, HTTP headers, and source IP. Policies can reject arguments containing shell metacharacters, SQL injection patterns, path traversal sequences, or any other suspicious content. Because Rego is a full policy language, policy authors can write validation logic as granular as their upstream services require — allowlisting specific argument values, enforcing type constraints, or matching against regex patterns.
  • Per-tool token scoping — Even if a malicious argument passes OPA validation and reaches an upstream service, the delegation token limits the blast radius to the scopes configured for that specific tool. The upstream service cannot be used to access resources beyond the tool’s configured scope.
Upstream service security is outside gateway scope. The Orchestrator validates and constrains at the gateway layer, but cannot prevent an upstream MCP server or REST API from being vulnerable to injection in its own implementation. If your upstream tools wrap shell commands, SQL queries, or code execution, those tools must implement their own input sanitization, parameterized execution, and sandboxing as recommended by OWASP.
OWASP risk: Intent flow subversion occurs when malicious instructions embedded within retrieved context cause an MCP-enabled agent to deviate from the user’s original goal. Unlike direct prompt injection, this happens “in-flow” — the agent retrieves resources containing hidden directives that override intended objectives. Impact includes goal hijacking (the agent pursues an entirely different objective), unauthorized autonomous actions (deleting repositories, modifying cloud configurations), and stealthy persistence (meta-instructions in long-lived contexts alter behavior across multiple sessions).Coverage: Limits blast radiusIntent flow subversion is fundamentally an AI model-layer problem — the attack targets how the model interprets context, not how identity or authorization is enforced. The AI Identity Gateway cannot prevent a model from being manipulated by malicious context. However, it protects upstream services by ensuring that even a subverted agent cannot exceed its authorized boundaries:
  • OPA policies as a containment boundary — Even if an agent’s intent is hijacked, every tool invocation must pass OPA policy evaluation before reaching any upstream service. Policy authors can constrain not just which tools are allowed, but what argument values are permitted. If the OWASP attack scenario describes an agent being tricked into calling delete_branch on a production repository, the OPA policy can deny that tool entirely, restrict it to specific branches, or block it based on the argument values. For high-impact operations, OPA policies will soon support human-in-the-loop approval, requiring explicit human authorization before the request proceeds to the upstream service. The policy enforces the boundary regardless of what the agent’s manipulated intent says.
  • Delegation tokens enforce both agent and user permissions — For user-delegated agents, the delegation token carries the user as the subject and the agent as the actor (act claim). Upstream services receive tokens that reflect both sets of permissions — the user’s actual entitlements and the agent’s configured scopes. An agent acting on behalf of a read-only user cannot perform write operations on upstream services even if its intent is subverted. For autonomous agents operating without a delegating user, the token carries only the agent’s own registered scopes, and OPA policies enforce boundaries based on agent identity alone. In both cases, an agent without the required scopes is blocked regardless of its intent.
  • Short-lived, per-invocation tokens — Delegation tokens are minted by the gateway and sent directly to upstream services — the agent never sees or handles them. Each token is scoped to a single tool with a customizable TTL (e.g., 5s). Even if a delegation token is intercepted in transit, it expires almost immediately and cannot be used for a different tool or service.
  • Auditing enables detection — Action-level logging captures every tool invocation with full identity context. Unusual patterns — unexpected tools being called, anomalous invocation frequency, suspicious parameters — are visible in the audit trail for security teams to detect and respond to.
Complementary controls needed: The gateway provides damage limitation, not prevention. To address intent flow subversion at its source, implement AI model-layer controls: intent alignment validation, guardrail models that review agent plans independently of potentially poisoned context, context sanitization that treats all retrieved MCP resources as untrusted data (not instructions), and drift detection that pauses sessions when agent behavior deviates from the original objective. See OWASP MCP06 for detailed model-layer mitigation guidance.
OWASP risk: MCP servers, tools, or agents fail to properly verify identities or enforce access controls during interactions. Manifestations include missing API validation, hardcoded secrets, static credentials, insecure token issuance without expiry or scoping, client-side-only authorization, and unverified caller metadata. Since MCP ecosystems involve multiple agents, users, and services exchanging data and executing actions, weak identity validation exposes critical attack paths: unauthorized access to sensitive operations, privilege escalation through token reuse, agent impersonation, and complete service compromise through chained malicious actions.Coverage: Directly addresses — this is the core problem the gateway was built to solveThe Orchestrator protects upstream services through multiple independent layers of authentication and authorization, addressing every vulnerability indicator OWASP lists:
  1. Agent authentication (OAuth 2.0 inbound) — Every agent must authenticate before accessing any upstream tools or services. The gateway validates agent tokens using JWT verification or token introspection against the Auth Provider Orchestrator. Unauthenticated agents receive a 401 and are directed to the authorization server via RFC 9470 protected resource metadata. There is no anonymous or guest access to upstream resources.
  2. Inbound authorization (OPA policies) — After authentication, every tool invocation is evaluated against Rego policies with a deny-by-default stance before reaching any upstream service. Policy authors can write granular rules based on tool name, tool argument names and values, HTTP headers (including the inbound token’s identity claims), and client IP. Authorization is enforced server-side on the gateway — never client-side.
  3. Outbound authorization (per-tool token exchange) — The Orchestrator performs per-tool token exchange with the Auth Provider, minting a scoped delegation token for each upstream call. Each token is bound to a specific tool, carries only the scopes that tool needs, expires in seconds, and includes both agent and user identity. Tokens are not reusable across agents, tools, or sessions.
  4. Token minting policies — The Auth Provider Orchestrator can apply OPA-based governance during token exchange. This is an independent control point — even if an inbound policy allows a tool call, the Auth Provider can refuse to mint the token.
  5. Centralized identity management — The Auth Provider Orchestrator integrates with your organizational IdP (Microsoft Entra ID, Okta, Auth0, or any OIDC provider) via Identity Fabric connectors. Agent identities are managed through your existing IAM infrastructure, not through separate, disconnected credential stores.
  6. Per-agent identity — Each agent authenticates with its own credentials. Credentials are not shared across agents. The Auth Provider defines the permitted scopes per agent registration.
OWASP attack scenarios and how the gateway responds:
  • Token replay (intercepted token reused for admin operations): Delegation tokens expire quickly (with configurable TTLs, typically seconds), are scoped to a single tool, and are bound to a specific audience. A replayed token is expired, wrong-scoped, and wrong-audience.
  • Cross-environment escalation (test and production share auth scopes): The Auth Provider can restrict which downstream services each gateway client can request tokens for. Test and production gateways use separate client registrations with separate audience restrictions.
  • Spoofed agent registration (malicious service registers as legitimate agent): Agent registration happens in the Auth Provider’s OIDC Provider configuration or upstream IdP, both under administrative control. There is no self-service or unprotected enrollment endpoint.
  • Inherited privileged credentials (agents inherit credentials through shared context): The gateway never forwards the inbound agent’s token to upstream services. Each upstream call receives a freshly minted delegation token with only the scopes configured for that specific tool. If the upstream service is another agent, it receives a scoped token — not the calling agent’s credentials. Agent-to-agent credential sharing that happens outside the gateway (through shared context or direct communication) is outside gateway scope.
OWASP risk: MCP systems orchestrate complex, autonomous workflows with minimal human intervention. When auditing mechanisms fail, organizations cannot track agent actions, access patterns, or decision logic. Consequences include inability to perform root-cause analysis, regulatory violations (GDPR, PCI DSS, ISO 27001), extended breach dwell time, behavioral drift going undetected, and inability to demonstrate proper data governance.Coverage: Directly addressesThe Orchestrator generates comprehensive, structured audit data for every interaction with upstream services:
  • Full identity context per event — The Orchestrator can log all MCP requests and responses, capturing agent identity, delegating user identity, tool name, tool parameters, response content, and session ID. This creates a complete audit trail that traces every action back to both the agent and the human who authorized it. Policy authors can also add custom log messages via OPA policies for additional context.
  • Structured JSON logging — Logs are output in structured JSON format for direct SIEM ingestion. Session IDs correlate events across a user’s session for complete interaction reconstruction.
  • Authorization decision logging — Every OPA policy evaluation is logged: which policies were evaluated, what input data they received, and whether access was allowed or denied. Failed authorization attempts are captured alongside successful ones.
  • Token exchange logging — Token exchange events are logged: which tokens were minted, for which tools, with which scopes, and with what TTL. This provides visibility into the delegation chain for every upstream call.
  • Access logging — HTTP-level access logging records every inbound request with method, path, status code, and timing.
OWASP attack scenarios and how the gateway responds:
  • Silent exfiltration (agent exports data through legitimate tool calls without detection): Every tool call is logged with full parameters. Unusual data access patterns (large result sets, unexpected tools, high frequency) are visible in the audit trail for SIEM-based alerting.
  • Insider manipulation (developer disables telemetry during testing): The Orchestrator’s logging is configured at the infrastructure level, not controlled by individual agents or users. An agent cannot disable logging for its own sessions.
  • Prompt injection data theft (malicious instruction causes credential retrieval): The audit trail shows the exact tool invocations, parameters, and outcomes — enabling forensic reconstruction of what data was accessed and where it was sent.
See the Compliance and Audit guide for SIEM integration setup and the Telemetry reference for all logging configuration.
Downstream responsibilities: The Orchestrator generates the audit data. Tamper-evident storage (append-only, HMAC integrity), retention policy enforcement, PII redaction, ML-based anomaly detection, and real-time alerting are responsibilities of your SIEM/XDR platform (Splunk, ELK, Sentinel, Datadog, etc.).
OWASP risk: Shadow MCP servers are unapproved or unsupervised MCP deployments that operate outside formal security governance. Like Shadow IT, these rogue nodes are spun up for experimentation or convenience, using default credentials, permissive configurations, or unsecured APIs. They create unmonitored attack surface, expose sensitive data processing capabilities, introduce compliance violations, and complicate incident response because untracked servers are invisible during containment and forensics.Coverage: Directly addresses (gateway layer)The Orchestrator’s gateway architecture ensures agents only reach approved, governed upstream services:
  • Single entry point — Agents connect to the AI Identity Gateway Orchestrator, not directly to MCP servers. The gateway is the only MCP endpoint configured in agent configurations. All tool discovery and invocation flows through the gateway’s authentication and authorization layers. An agent configured to use the gateway cannot reach an unregistered MCP server through the gateway.
  • Explicit server registration — Upstream MCP servers must be explicitly registered in the gateway. The gateway does not auto-discover, auto-register, or dynamically connect to MCP servers. Shadow servers cannot inject themselves into the tool catalog.
  • Network isolation — The recommended deployment pattern restricts network access so that MCP servers only accept connections from the Orchestrator. Agents that attempt to bypass the gateway and connect to MCP servers directly are blocked at the network level. This turns the gateway into a mandatory checkpoint.
  • Centralized governance — All authentication, authorization, and audit policies are configured on the Orchestrator. Shadow servers that bypass the gateway operate without any identity governance, making them detectable through their absence from audit logs — and through network monitoring for MCP traffic patterns outside the gateway’s known endpoints.
Complementary controls needed: The gateway prevents managed agents from accessing shadow servers, but does not discover shadow servers in your network. OWASP recommends network discovery scanning (Nmap, CSPM, EASM), passive network sensors for MCP traffic patterns, mandatory registration governance before deployment, CI/CD pipeline gates blocking unregistered instances, and developer education on shadow MCP risks. These are organizational governance controls outside the scope of the gateway.
OWASP risk: In MCP-based systems, context acts as the working memory for agents — storing prompts, retrieved documents, intermediate reasoning, and interaction history. When this shared context lacks proper isolation or governance, sensitive information from one task, user, or agent may be exposed to another. The risk combines context injection (malicious content embedded in shared memory) with over-sharing (reusing context across systems that should be isolated). Impact includes cross-agent and cross-user information disclosure, regulatory violations, exposure of trade secrets, and persistent behavioral contamination.Coverage: Reduces attack surfaceThe Orchestrator protects upstream services from cross-context access through token-level and session-level isolation:
  • Per-tool token scoping — The gateway mints a separate delegation token for each tool invocation and sends it directly to the upstream service — the agent never sees or handles these tokens. Each token carries only the scopes that specific tool needs. An upstream service receiving a user:List token cannot use it to access a different service expecting order:List. This prevents cross-tool data access at the authorization layer.
  • Short TTLs limit exposure — Delegation tokens expire in seconds. Even if a token is intercepted between the gateway and an upstream service, it cannot be reused in a different context or against a different service because it has already expired and is scoped to a single tool.
  • Delegation vs impersonation controls — The Orchestrator supports two token exchange modes. Delegation (default) produces tokens with an act claim that preserves full identity context — downstream services see both agent and user identity. Impersonation produces tokens that assume the user’s identity without exposing the agent’s identity. Organizations choose the mode that matches their data-sharing requirements.
  • Session isolation — At the MCP transport layer, sessions are isolated per agent connection. One agent’s session context — including discovered tools, session state, and MCP session ID — is not shared with other agents connecting to the same gateway. This is transport-level isolation; model-level context isolation (the core OWASP concern) is addressed in the complementary controls below.
Complementary controls needed: The gateway prevents token-based cross-context access but does not control the AI model’s context memory. OWASP recommends ephemeral contexts with automatic deletion post-task, per-user/per-agent namespace isolation in vector stores, data classification tagging (Public/Internal/Confidential/Restricted), TTL enforcement on context memory with automated purging, PII redaction before context storage, and injection filtering that detects instruction-like persistence attempts. These are AI model-layer and data pipeline controls outside the scope of the identity gateway.

AI Identity Overview

Set up the Auth Provider and AI Identity Gateway with per-tool token exchange

Compliance and Audit

Configure audit logging, TLS, secret management, and SIEM integration

Authorization Policies

Define OPA-based access control policies for fine-grained authorization

AI Identity Gateway Reference

Complete configuration reference for MCP Provider settings, transports, and OAuth