MCP is solving an important interoperability problem: giving models and agents a consistent way to discover and invoke external tools, data sources, and services.

But enterprise architecture has a second problem that should not be collapsed into connectivity:

An agent being able to call a tool does not, by itself, establish that the agent is authorized to take the resulting action.

NIST's Software and AI Agent Identity and Authorization work separates identification, authorization, access delegation, logging/transparency, and data-flow provenance. Its concept paper describes linking specific user identities to agents for delegation and accountability, while noting MCP's use of existing identity standards such as OAuth and OIDC.

Current platform implementations make the same distinction concrete. Docker's MCP policy model governs registration separately from use-time actions, can default-deny tool invocation unless policy permits it, and supports per-request confirmation for selected operations. Oracle Integration's MCP Gateway places centralized identity, policy, credential handling, enforcement, tool filtering, and observability between MCP clients and enterprise tools.

These implementations do not prove that one universal agent-governance architecture has won. They show why “the agent connected successfully” is an incomplete control statement.

Seven-layer control model

  1. Connectivity — Which tools, resources, and systems can the agent reach?
  2. Identity — Which user, agent, workload, or service is acting?
  3. Delegated authority — Whose authority is the agent carrying, and what rights were actually delegated?
  4. Policy — Under what context, scope, and constraints is this action permitted?
  5. Execution — What consequential action actually occurred?
  6. Evidence — Can the organization reconstruct the identity, authorization decision, tool invocation, inputs, outputs, and outcome?
  7. Revocation and recovery — Can authority be withdrawn and unsafe execution stopped or contained?

The first layer answers what can the agent connect to? The remaining layers answer: What is this agent allowed to do, for whom, under which conditions, and how will we prove what happened afterward?

Architecture consequence

Treat MCP interoperability as one layer rather than the complete trust boundary. Authentication, delegated authorization, least-privilege tool exposure, contextual policy, credentials, execution controls, audit evidence, and revocation should remain independently reasoned about.

A useful design-review question is:

If this agent discovers a tool and successfully authenticates, what independent control determines whether this specific action is authorized?

Existing commercial route

For teams evaluating agent architecture, the existing AI & Platform Architecture Diagnostic may be relevant where the decision requires independent review of boundaries, controls, execution paths, or production-readiness assumptions. This creates no new service or promise.