Детерминистические границы не подлежат переговорам для идентификации агента ИИ

Revocation is not a retry prompt for the LLM — it's a control-plane signal that the deterministic layer must intercept. Let the model keep reasoning, but deny access with a structured error code that the runtime handles, not the chatbot.

Why Scope Must Be Deterministic

Agents generate probabilistic outputs, but their permissions cannot be probabilistic. The identity boundary must be deterministic: which systems, tools, data domains, and actions are allowed. The agent chooses inside the scope; the scope itself is defined by policy, not by a prompt telling the LLM to behave. As the author puts it, "Filters, policy checks, and access enforcement must sit outside the model's discretion." That means no delegating access control to a system prompt.

A practical architecture: the agent requests a runtime credential through a trusted path — attestation, signed deployment metadata, workload identity. That credential is short-lived, scoped, and anchored to a stable agent identity like agent-invoice-processor-v2. The credential proves current authorization but does not capture the full governance context — owner, purpose, autonomy level, human delegator, policy version. You need all three: stable identity for audit, short-lived credentials for runtime, and traceable records for every tool call.

Revocation as a Controlled Failure, Not a Retry Storm

Here's the crux: a revoked credential should never become new context for the LLM to reason around. If an MCP server or API returns a denial, the deterministic enforcement layer intercepts it before the model sees it. The runtime then fails the action safely, quarantines the instance if needed, and preserves the audit trail. The LLM does not get to retry indefinitely, request broader permissions, or choose alternate tools. Recovery, if any, is bounded by deterministic logic.

That means the agent stops dead on a revocation signal — no reinterpretation, no workaround. The author calls revocation "a control signal, not model context." This is the only way to prevent an agent from treating an access denial as just another problem to solve.

MCP Authorization Isn't Enough on Its Own

MCP servers can become policy enforcement points: they inspect agent identity, runtime instance, delegated authority, and supervision mode before allowing a tool call. That's valuable. But MCP authorization does not replace an enterprise identity model. For internal servers, OAuth can bind requests to agent identity and delegation. For external providers, OAuth usually only sees the resource owner and scopes — not the enterprise's internal agent identity unless it's federated. Upstream governance — knowing which agent initiated the call, who owns it, whether human approval is required — must happen before the MCP handshake.

The author warns that "gateway-only thinking" for MCP misses the point. You need identity-aware governance at every level, not just a checkpoint at the edge.

Deterministic scope, short-lived credentials, revocation as a control signal, and MCP enforcement with identity context: get these right, and your agent operates inside governed boundaries. Get them wrong, and the probabilistic model is effectively writing its own permission slip.

Source: No AI Agent Without Identity (Part 4): Deterministic Boundaries, Revocation, and MCP Enforcement
Domain: hackernoon.com