No AI Agent Without Identity (Part 4): Deterministic Boundaries, Revocation, and MCP Enforcement

⋅

Series Context

In Part 3: Delegation, HITL, and Identity Propagation, we covered how to preserve accountability when agents act under human authority, human supervision, or through other agents. In this part, we focus on enforcement: how identity becomes operational through deterministic scope, short-lived credentials, revocation behavior, and MCP-aware authorization. The key question is not only who the agent is, but how the system ensures that the agent can act only within governed boundaries.

Dynamic Lifecycle and Short-Lived Credentials

For critical environments, agent identity should not be only a static provisioning exercise.

A hardened lifecycle should look like this:

  • Request — The agent runtime requests an identity, token, certificate, or scoped credential.
  • Authenticate — The request is authenticated through workload identity, attestation, signed deployment metadata, deployment provenance, or another trusted bootstrap method.
  • Validate — The identity system confirms the agent identity, owner, policy state, supervision mode, environment, and allowed scope.
  • Activate — A runtime credential is issued with limited scope and limited lifetime.
  • Use — The agent performs actions. Each meaningful access, decision, tool call, and output is logged with the agent identity, runtime instance ID, access or execution record, and policy decision.
  • Deactivate — When the agent instance terminates or the task completes, the credential expires, is revoked, or is inactivated. Temporary runtime state is closed. Audit evidence remains.

Dynamic agents should request runtime credentials through controlled channels rather than relying only on static, pre-provisioned secrets. Connected systems, MCP servers, gateways, and policy engines should validate those claims before allowing access.

This raises the bar against identity impersonation, substitution, and unauthorized agent injection. A rogue or maliciously spawned agent should not be able to simply appear with privileges. It must request identity through a trusted path, be validated against an approved agent record, and operate within scoped, auditable credentials.

Short-lived tokens, certificates, or scoped runtime credentials are strongly preferred. They reduce credential theft risk, limit replay windows, support just-in-time access, and make revocation and rotation easier.

But they still need an anchor.

A token may prove that a request is currently authorized. It does not necessarily explain the full governance context: who owns the agent, why the agent exists, what purpose it was approved for, what autonomy level is permitted, which human delegated the action, which policy version authorized the decision, which context led to the tool call, what retention class applies, or what happens if the agent must be disabled.

A good design uses all three:

  • Stable agent identity for governance.
  • Short-lived credentials for runtime access.
  • Traceable access and execution records for audit.

These are complementary, not competing, controls.

Scope Must Be Deterministic Even When the Agent Is Probabilistic

A common objection is that AI agents are probabilistic, so their permissions are hard to scope.

That is exactly why the scope cannot be left to the agent.

The model may reason probabilistically. The identity boundary must not.

The agent may generate variable outputs, choose among allowed tools, summarize different context, or propose different actions. But the permissions around that behavior must remain deterministic: which systems it can access, which tools it can call, which data domains it can read, which actions require approval, which actions are denied, and which outputs must be filtered before execution.

The agent can choose only inside the scope.

It cannot choose the scope.

For the same reason, identity, authentication, authorization, and approval enforcement cannot be delegated to the agent itself.

A prompt instruction telling the agent to respect human-in-the-loop rules is not governed approval. A prompt instruction telling the agent to respect its own access boundaries is not governed access control.

Filters, policy checks, and access enforcement must sit outside the model’s discretion. They must be deterministic and independent.

In an MCP-based architecture, the server should verify the agent identity, role, delegated authority, supervision mode, and allowed actions before allowing tool or resource access. It should not simply trust the MCP client or the agent’s self-declared intent.

The agent can request.

The enforcement layer decides.

Agent boundaries should not be processed by the LLM. They should be enforced around it.

That scope should be defined by identity, role, policy, system definition, and runtime enforcement. Depending on the architecture, enforcement may happen through the identity provider, policy engine, workload identity layer, MCP server, gateway, orchestration layer, CI/CD controls, or deterministic runtime guardrails.

The same applies to credential rotation. An agent should not own the process that grants, expands, or rotates its own privileged access. Credentials should be issued, rotated, expired, and revoked by the platform, identity system, or workload identity layer.

If an agent writes code, deploys changes, modifies workflows, or triggers infrastructure changes, those actions must still pass through separate identities, policy gates, CI/CD controls, and approval rules.

The probabilistic part is the reasoning.

The deterministic part must be the boundary.

This becomes even more important when access is denied or revoked. A boundary only works if the agent cannot reinterpret the denial as another problem to solve.

Revocation Must Be a Controlled Failure, Not a Retry Storm

Revocation is not only an access-control event. For agents, it is also a runtime behavior problem.

A revoked credential should not become new context that the LLM can reason around. Agent boundaries must be enforced by deterministic controls. Revocation, denial, expiration, and policy failure are control-plane signals, not reasoning material.

If an MCP server, tool, API, gateway, or identity provider returns a revocation signal — such as forbidden access, identity revoked, policy denial, or credential expired — that response should be intercepted by a deterministic control layer before it reaches the model.

One possible implementation is to place a deterministic enforcement layer inside or around the agent runtime, between the agent and the systems it interacts with. When the runtime detects a structured revocation or denial signal, it should treat it as a control-plane event rather than another problem for the LLM to solve.

In that case, the runtime can:

  • fail the current action safely
  • prevent further privileged actions
  • preserve the audit trail
  • escalate through approved channels

In more severe cases, the deterministic layer may quarantine the runtime instance or access attempt for forensic review.

The LLM should not be allowed to retry indefinitely, request broader permissions, choose alternate tools, or attempt to bypass the revocation. Recovery, if any, should be bounded and handled by deterministic logic, not by the model’s reasoning.

The exact mechanism can vary: structured error codes, policy metadata, gateway-enforced signals, identity-provider responses, or allow/deny rules.

The principle remains the same:

Revocation is a control signal, not model context.

The deterministic layer should decide how the agent fails, not the LLM.

OAuth, MCP, and Authorization vs Identity

MCP servers should not be treated only as neutral tool routers. They can also become policy enforcement points.

When an agent calls a tool through MCP, the server should be able to inspect the agent identity, runtime instance, delegated authority, role, supervision mode, and allowed actions before deciding whether to allow the request, deny it, narrow the available tool scope, require approval, or produce an audit event.

MCP authorization is important, but it should not be confused with a complete enterprise identity model.

For internal MCP servers, OAuth can help bind requests to agent identity, delegation, policy, and runtime context.

That is valuable.

But it only works well if the enterprise identity layer has already defined who the agent is.

The MCP server should be able to receive or resolve claims such as:

agent_identity = agent-invoice-processor-v2
runtime_instance_id = replica-47
access_record_id = access-20260620-184739-7f3a9b
human_delegator = user-maria
supervision_mode = autonomous_bounded
policy_decision = allow
allowed_tools = invoice.lookup, invoice.update-approved

For external providers, OAuth usually expresses delegated access through scoped tokens. The external system may care mainly about the resource owner, client, scopes, and token validity. It may not understand the enterprise’s internal agent identity unless that identity is federated, propagated, mapped into claims, or recorded upstream.

That is why upstream governance remains essential.

Before an agent connects externally, the enterprise still needs to know which agent initiated the connection, who owns it, what it is allowed to do, whether human approval is required, and whether the action belongs to an approved access or execution context.

MCP can carry and enforce parts of this model when identity context is passed correctly.

It does not replace the model.

This is also why gateway-only thinking is not enough for MCP-powered AI. As I argued in Gateway Security Won’t Be Enough for MCP-Powered AI, MCP needs identity-aware governance, not only a checkpoint at the edge.

What This Part Establishes

This part demonstrates that agent boundaries must be enforced by deterministic policy, not model discretion. It shows why probabilistic reasoning requires deterministic scope, why credentials should be short-lived and anchored to stable identity, why revocation must be handled as a control-plane signal rather than model context, and why MCP authorization can support agent governance but cannot replace the enterprise identity model.

Previous:

← Part 3: Delegation, HITL, and Identity Propagation

Next in the series:

→ Part 5: Auditability and the Minimum Bar for Governed Autonomy

Liked Liked