MCP-IDJAG + agent identity in the envelope: why our MCP gateway is structurally different

Every AI Control Plane vendor with an MCP story tells the same opening sentence: "we run a managed MCP gateway with OAuth 2.1 and PKCE." It is technically true for Speakeasy, Truefoundry, MintMCP, Lunar.dev, Runlayer, and Visionality. It is also where most of them stop. This article walks through the three layers below the OAuth-2.1 surface where Visionality is structurally different — Enterprise-Managed Authorization via ID-JAG, agent identity signed into the spend-token envelope, and SQL-role-enforced invocation logging — and what each means at the procurement conversation.

Layer 1: ID-JAG (Enterprise-Managed Authorization)

The Model Context Protocol spec adopted Enterprise-Managed Authorization in 2026, with the ID-JAG (identity-assertion-grant exchange) lane stabilized and endorsed by Anthropic, Microsoft, and Okta. The standard solves the structural problem of MCP being designed as a developer-facing auth flow (one user, one workstation) when it actually runs in enterprise contexts (one identity provider, many users, scope-graded policies).

How ID-JAG works in one paragraph: the customer's identity provider issues an identity assertion (a signed JWT carrying the user's organizational identity). The MCP gateway receives the assertion and exchanges it for a scoped grant — the customer's IdP is the authority, the gateway is the enforcer. The user's MCP client never holds long-lived credentials; the gateway holds a per-session grant bound to the user's IdP identity. An organizational policy change (a leaver event, a role downgrade, a scope reduction) takes effect at the gateway on the next assertion exchange.

Visionality's MCP gateway is ID-JAG-ready today. The auth lane is shipped (Sprint χ), the PKCE consent flow (CC6.6 evidence collector) is shipped, the client registry is shipped. Onboarding an enterprise customer's IdP into ID-JAG is configuration, not engineering. Speakeasy positions for ID-JAG but the customer-facing implementation is still in their roadmap as of the April 2026 reference architecture publication. Portkey/PANW is in-flux post-acquisition. The MCP-niche entrants (Lunar.dev, Runlayer, MintMCP) are not in the spec-adoption conversation yet.

This matters for the procurement question "how does our IdP integrate with your MCP layer?" If you have an answer, you are in the deal. If you don't, the conversation does not progress past the security review.

Layer 2: agent_sub signed into the spend-token envelope

Most MCP gateways treat agent identity as application metadata. The gateway logs "the agent named coding-assistant made this MCP call." The audit trail trusts that the agent name was set correctly by the application that issued the call. This is the same architectural concession as application-level audit logs: the assumption that the application won't lie about the agent's name is the assumption being audited.

Visionality signs the agent_sub claim into the spend-token envelope (Token Authority v2) at issuance time. The token carries:

sub:        <user_id from the IdP>
agent_sub:  <agent identity assigned by the operator>
project_id: <Visionality project mapping>
exp:        <expiry>
binding_alg: aes-256-gcm
binding_key: <returned to the issuer once; never sent to wire afterward>

The agent_sub claim is part of the envelope's AAD-bound binding. An attacker who steals the token cannot change the agent_sub because the binding-key second factor would reject the modified call. A leaked token without the binding key is rejected at the gateway with a structured 401, and the rejection lands on request_logs.binding_status for the auditor as data, not as an incident-report-after-the-fact.

Practically: every MCP tool call from an agent operating under that token is provably the agent the operator assigned. The agent_owner column on request_logs (migration 0035) is denormalized from the agent identity table at insert time, so the chargeback CSV the controller exports at month-end shows agent → owner attribution as a single fact, not a join-time inference. The MCP-CC7.3 evidence collector reads the MCP invocation log and emits per-agent rollups directly.

The strategic implication is procurement-grade: the CISO conversation "how do we know which agent did what" has a structural answer, not a metadata-trust answer. None of the other MCP gateway products in the matrix have a comparable identity-binding posture at the time of writing.

Layer 3: SQL-role-enforced MCP invocation logging

The mcp_invocations table is one of the five audit tables under SQL-role REVOKE enforcement in migration 0015. The application role acc_app has INSERT, SELECT on the table; UPDATE and DELETE are revoked. The dashboard reads from the table; the operator's evidence-pack collector reads from the table; the auditor reads the role grants directly to confirm the enforcement.

This is the structural layer most MCP gateway products skip. The application is trusted to write the row, then trusted not to rewrite it. Visionality enforces the trust at the database level. Every MCP tool call is a row that the application cannot modify. The CC7.3 evidence collector emits the row count + the latest invocation timestamp + the role-grant status as the framework-mapped evidence:

{
  "framework": "SOC2",
  "control": "CC7.3",
  "title": "MCP invocation log",
  "status": "pass",
  "detail": {
    "table": "mcp_invocations",
    "row_count": 18234,
    "latest_invocation_at": "2026-06-26T15:23:01.234Z",
    "role_grants": {"acc_app": ["INSERT", "SELECT"]},
    "update_delete_revoked": true
  }
}

The framework-mapped evidence shows up in the continuous-evidence pack. The pack signs with SHA-256 + verifies offline via vis-verify. The auditor's procurement-grade question has an audit-grade answer.

What this looks like on the dashboard

If you've deployed Visionality, the MCP surface lives at:

• /mcp/audit — chronological PKCE consent audit timeline (CC6.6 source). Filter by outcome / client / subject. Download as RFC-4180 CSV via the "Download CSV" link.
• /mcp — MCP server registry + anomaly detector. Volume spikes, cost spikes, error spikes surface here graded critical / warning / info.
• /agents/manage — agent identity table. Per-agent agent_sub → display label + owner mapping. One-click agent_owner backfill button for historical rows.
• /compliance — continuous-evidence pack download + binding-status posture card with clickable drilldown to /requests filtered by binding_status.

The flow from MCP tool call → cost row → chargeback CSV → CC7.3 evidence collector → signed pack → offline verifier is single-product end-to-end. Speakeasy customers deploying the platform get the on-path enforcement; they do not get the SQL-role audit posture, the binding-key envelope, the four-framework evidence pack, or the offline verifier.

The procurement conversation

If the CISO is asking "how do we know which agent made this MCP tool call, that we can prove it later, that an attacker compromising the application can't rewrite the answer, and that the auditor can verify the answer offline?" — every layer above is in the answer. The honest competitive read:

• For the OAuth 2.1 + PKCE surface: every MCP gateway matches.
• For ID-JAG readiness: Visionality is shipped, Speakeasy is positioned, others vary.
• For agent_sub-signed-into-the-envelope identity: Visionality is uniquely shipped in the matrix.
• For SQL-role-enforced MCP invocation logging: Visionality is uniquely shipped.
• For the four-framework evidence pack with offline verifier: Visionality is uniquely shipped.

The depth-of-stack is the moat. Companion reads: Token Authority v2 binding-key envelope, MCP Gateway overview, Audit at the role, Continuous-evidence pack.

Book a 30-minute walkthrough and we'll show you the MCP audit timeline + the evidence pack live against a demo dataset.