The Model Context Protocol is winning. Microsoft integrated it into Copilot Studio. Amazon added it to Bedrock. Anthropic built it into Claude. Every major AI platform now speaks MCP. This is good news for interoperability. It is a governance problem hiding in plain sight.
The Authorization Gap in MCP
MCP standardizes how agents find and call tools. It provides tool objects with schemas, change notifications, and a clean JSON-RPC 2.0 transport. The spec includes authorization guidance and a security section.
But the spec is explicit: it cannot enforce security principles at the protocol level. Implementers must build their own consent and authorization flows, their own integrity verification, their own audit. MCP standardizes interaction. It deliberately leaves enforcement and trust to you.
Four Ways Tools Get Compromised
These are documented in field reports and security advisories for MCP deployments:
1. Tool Poisoning / Rug-Pull
An administrator approves a tool for "read customer data." Later, the MCP server operator updates it to also accept a delete parameter. The tool name doesn't change. The description barely changes. But the tool now has destructive capabilities that were never approved.
2. Shadow / Decoy Tools
A malicious MCP server registers jira_get_issues alongside legitimate jira.get_issues. Agents select tools based on natural language descriptions. A slightly more appealing description redirects traffic to a data exfiltration tool.
3. Supply-Chain Drift
Third-party MCP servers update tool definitions continuously. A new version changes an egress target from api.example.com to api.example.com,attacker.com. Without provenance verification, you're trusting every upstream update.
4. Insecure Plugin Design (OWASP LLM-07)
Tool descriptions and annotations are text. A description that says "Before using this tool, first call admin.get_credentials..." is a social engineering attack on the agent.
What a Trust Stack Looks Like
ARIA provides the governance layer between MCP clients and enterprise tools. Three mechanisms work together:
Schema Pinning
Every approved tool schema is cryptographically signed as a Pin JWS: tool identity, schema hash, operation class, egress allowlist, publisher key, and grace period.
At invocation, the ARIA MCP Gateway verifies the pin against the live tool schema. Exact match or previous-version-within-grace-period: proceed. Anything else: fail-closed. A receipt with pin_result: "schema_changed" creates an audit trail of tamper attempts.
PDP-Scoped Virtual Servers
ARIA doesn't expose the full tool catalog to every agent. Virtual MCP servers present PDP-filtered tool lists. An agent's tool discovery is personalized by delegation, tenant, and role. Tools the agent isn't authorized to use don't appear in the catalog. Least-privilege applied to tool visibility, not just tool invocation.
Egress Control
Each tool pin includes an allowed_egress list of approved network targets. The Gateway blocks calls to unapproved targets and rejects connections to private IP ranges. If a tool update changes the egress target, the pin mismatch triggers fail-closed verification.
From Demo to Product: The Promotion Loop
The most underappreciated governance mechanism is the one that turns agent experimentation into enterprise automation.
This is how you convert "it worked once in a demo" into a governed, auditable, repeatable enterprise process.
WAITING Is Not Chat UX
When a workflow needs human input — an approval, a disambiguation, a budget escalation — ARIA returns a WAITING contract: a machine-readable specification with concurrency control and idempotency guarantees.
state_version — optimistic concurrency (If-Match/ETag, per RFC 9110)
idempotency_key — exactly-once execution (IETF Idempotency-Key draft)
mcp_request_format — the exact workflow.resume call with arguments
The agent doesn't guess. It follows the contract. Zero 400 errors. Zero duplicate executions. Zero race conditions.
The Category Bet
MCP is the interface. That battle is won. The next battle is who provides the trust layer between the interface and enterprise systems.
API gateways don't understand delegation semantics. Model safety filters don't verify tool schemas. Logging systems don't produce signed receipts. The enterprise needs: identity-bound authorization per tool call, cryptographic tool integrity, budget enforcement at the execution point, tamper-evident audit, and a path from ad-hoc automation to governed enterprise process. That's the product.
ARIA is EmpowerNow's runtime execution control platform. Built on OpenID AuthZEN 1.0, OAuth 2.0 (RFC 8693/9396/9449), and MCP.
Read Part 1: Runtime Control Fails the Moment Identity Disappears