The Architecture That Keeps AI From Authorizing Itself

TL;DR

An AI agent authorization architecture should let the agent propose work without letting it define the conditions that make that work permissible. Separate the runtime, authorization and enforcement, execution credentials, evidence, and human control administration. Protect the policy inputs and deployment paths as carefully as the policy engine itself.

A denied action can become an approved action without changing a single policy rule if the agent can alter the labels, group membership, approval records, or tool implementation that the rule trusts. The design must therefore constrain the agent’s effective reach, including delegated services and automation workflows, rather than only its visible tool list.

The agent may request authority. It must not be able to manufacture it.

Introduction

Consider a hypothetical infrastructure-cleanup agent. Its deletion policy permits removal of retired, nonproduction virtual machines (VMs). A production VM is correctly rejected.

The agent also has an inventory-maintenance tool. It changes the VM’s classification to nonproduction, marks it retired, and submits the deletion again. The policy service approves because its conditions are now satisfied.

The authorization code behaved as written. The architecture failed because the acting system could rewrite the facts used to authorize its own work.

Article 4 defined the Agent Action Evidence Contract. This installment places that contract within a vendor-neutral reference architecture that separates proposals, authority, side effects, and verification. It focuses on preventing direct and indirect self-authorization, not on replacing an enterprise identity platform or repeating the earlier evaluator and evidence schemas.

The design assumes that the agent runtime may be compromised while the separately administered authorization, execution, and evidence services remain within their declared trust boundaries. Host, platform-administrator, and identity-provider compromise require additional scenarios. A boundary supported against one threat should not be presented as protection against all of them.

Protect What “Allowed” Depends On

The protected control surface is larger than the policy repository.

In the cleanup example, resource classification and retirement approval are authorization inputs. An agent that can modify both the workload and those inputs has an indirect path to greater authority. Moving the policy engine to another server does not remove that path.

Distinguish operational metadata from authoritative control records. The agent may propose a classification correction, but a separate process should validate and commit changes that affect deletion eligibility. That process must not approve the correction solely because the same agent supplied a persuasive explanation.

This does not prohibit authorized state changes within a preapproved workflow. It prohibits the actor from granting itself eligibility that must come from another authority.

Apply the same reasoning to group membership, permitted destinations, tool registries, workflow definitions, and evidence-collection settings. If changing an object changes what the agent may do or what the organization can verify, treat that object as part of the control surface.

NIST SP 800-207 explicitly discusses subversion of the zero-trust decision process, including unauthorized or mistaken configuration changes to policy components. The extension proposed here is to examine every agent-reachable dependency that can alter an authorization outcome, including dependencies outside the policy service.

Protecting the rule is insufficient when the actor can redefine the facts the rule evaluates.

Separate Five Responsibilities, Not Necessarily Five Products

NIST’s Zero Trust Architecture distinguishes policy decisions from the mechanisms that establish and enforce access. Those logical roles provide a useful foundation, but a consequential agent workflow also needs bounded execution, independently sourced evidence, and accountable administration.

The following is a proposed responsibility model. It is not a NIST-defined five-layer architecture or a requirement to deploy five clusters.

The important separation in this diagram is between proposing a change and possessing a usable execution path. Policy decisions and observations arrive from services the agent cannot administer.

A trusted controller can manage the workflow and coordinate these services. “Trusted” describes the responsibility assigned to it, not proof that its implementation is correct. Its state, dependencies, and release path need protection and testing too.

An in-process approval function is not independent of a compromised process that can alter the function or skip its call. Conversely, separate services can still share a decisive administrative identity. The deployment must make the stated separation real.

Keep Production Credentials Out of the Proposal Runtime

For the high-impact pattern considered here, the agent receives permission to submit a bounded request. The execution service holds the credentials that can perform the approved operation.

Separate the agent’s workload identity from its execution authority. The request must preserve who initiated the work and which authority model applies.

In a delegated workflow, the operation remains constrained by the initiator’s valid delegation, the agent’s approved capabilities, and the resource policy. In a service-owned workflow, the requester may invoke an approved business operation without holding direct infrastructure-administrator rights. The service owner grants the executor that bounded authority separately.

Neither mode should allow a broadly privileged requester to expand the agent’s scope merely by asking. Nor should a service-owned workflow become an unrestricted administrative proxy.

OAuth Security Best Current Practice, RFC 9700, recommends restricting tokens to the necessary privileges, intended resource servers, and relevant resources and actions. Use supported authorization mechanisms rather than inventing a new bearer token whose security depends on the model keeping it secret.

For Model Context Protocol (MCP) integrations, the November 25, 2025 authorization specification requires servers to validate their intended token audience and prohibits forwarding the received client token unchanged to upstream application programming interfaces (APIs). That protocol boundary still needs application-specific checks for the requested operation.

Keep downstream credentials outside agent-accessible files, process environments, memory inspection paths, and tool results. Hiding a token from the prompt does not protect it when the runtime can read the executor’s environment or invoke a credential-export tool.

Make the Approved Proposal the Only Executable Proposal

The request path should translate an untrusted proposal into a narrowly bounded operation, without giving the model control over the translation rules.

Resolve Identity and Resources Outside Model Text

The controller obtains identity from authenticated request context. It resolves tenant, environment, and stable resource identity through approved services. A field saying environment: nonproduction is a proposed value, not proof of the target’s classification.

In the cleanup example, the authorization service obtains retirement approval from the governed service record. An ordinary inventory tag may help discovery, but it cannot replace that approval.

Reject unsupported operations and ambiguous target resolution. Do not let the model select an arbitrary administrative endpoint because the preferred route returned an error.

Bind the Decision to the Actual Side Effects

Authorize the normalized operation, exact target, relevant parameters, applicable tool implementation, validity window, and required preconditions. The reviewer’s preview should represent that operation rather than only the agent’s summary.

OWASP’s AI Agent Security guidance recommends separating decisions from execution and binding approvals to the exact action. Here, that means a deletion approval for one VM cannot authorize a revised list, a changed cleanup script, or a different executor with additional effects.

Prefer a reviewed, narrow adapter over an arbitrary command runner. A tool named retire_vm is not narrow when its implementation accepts a model-generated script that can delete backups, alter identity, and disable monitoring.

Where generated code is necessary, treat it as an untrusted change artifact requiring its own review and release controls. Approval of the intended result does not authorize every method the generated program might use.

Recheck at the Point of Execution

The execution gate checks that the decision is current, matches the request, and has not been suspended or superseded. The adapter retains target-specific validation and native access controls.

Where supported, use conditional operations that bind the mutation to the relevant current resource version. Otherwise, define an appropriate coordination mechanism and acknowledge any remaining race. A local workflow lock does not serialize administrators or other writers that ignore it.

If a material condition changes between approval and execution, hold the request for reassessment. Do not silently reinterpret the old approval against the new state.

Close Indirect and Delegated Execution Paths

OWASP’s Authorization Cheat Sheet recommends denying by default and validating permissions on every request. For agents, apply that principle to every reachable route to a consequential effect, not just calls made through the preferred client library.

A model gateway does not control a separate shell, deployment runner, message queue, or automation account merely because the agent uses the gateway for inference. Govern the MCP gateway and server layer alongside the downstream services that actually perform the work.

Audit the combined effect of capabilities. Individually acceptable operations can compose into a prohibited outcome: change group membership, invoke a privileged workflow, then remove the membership. The scope assessment must include those sequences.

For delegated work, the receiving service validates the originating workflow, the delegated action, and its remaining bounds. “Another approved agent requested this” is not sufficient authorization. A helper’s broader credentials must not become a route around the parent workflow’s limits.

Apply cumulative limits outside the agents. If a workflow may delete three approved resources, spawning three workers must not create three independent allowances of three. Shared budget reservations and execution admission need concurrency-safe implementation.

Also examine reads and outputs. A read can disclose restricted information, and a notification tool can transmit it. Classify the effect and destination rather than assuming that only write APIs are consequential.

Protect the Administration Path from the Workload It Governs

Control services need a release and administration path the operating agent cannot take over.

The agent may draft a policy change or open a proposed code revision. It should not approve, merge, deploy, or attest to that same change through credentials available to its workflow. Protect build definitions, deployment identities, image references, policy inputs, and emergency settings as well as the source repository.

Otherwise, the agent can leave the approved policy untouched and replace the component that interprets it.

The required placement follows the threat model, not a universal rule that every control needs its own cluster.

Kubernetes illustrates why these distinctions matter. Its Role Based Access Control Good Practices warns that permission to create workloads in a namespace can also expose mountable secrets and the API permissions of service accounts those workloads can use. Do not place the agent beside privileged execution services and assume namespace-local permissions are harmless.

Use separate service identities, protected deployment permissions, suitable workload restrictions, and an explicitly assessed hosting boundary. Stronger isolation may be justified, but a second cluster is not independent when the same agent-reachable automation identity administers both.

Network restrictions complement authorization. Kubernetes NetworkPolicy operates at network-address and port boundaries, requires an enforcing network plugin, and combines applicable allows additively. It does not determine whether a particular VM deletion is authorized. Inspect the effective policy set rather than trusting a resource labelled “default deny.”

A Queued Action Is Not a Standing Grant

Queues and failover can preserve work after the authority for that work has changed.

Require the worker to revalidate the action when it is about to dispatch. A request approved yesterday should not execute today merely because a queue finally became available. Check the current suspension state, approval validity, action binding, relevant policy, and remaining budget.

For action-scoped permits, define how multiple workers coordinate consumption. A local “already used” flag is insufficient when another replica can accept the same permit. Use shared, concurrency-safe state appropriate to the required guarantees.

That state does not make the external mutation atomic with the journal. Article 4’s distinction still applies: a lost response may leave execution unresolved, requiring reconciliation rather than blind retry.

Distributed or cached policy evaluation can reduce latency and dependency on a central service. It also creates decisions about freshness and revocation. A valid signature establishes neither that a policy bundle is the newest acceptable version nor that a previously authorized action remains permitted.

For the destructive workflow described here, hold new dispatch when mandatory authority checks cannot be completed. Less consequential workflows may use a predefined degraded mode, but the agent must not choose that mode for itself.

Keep Verification Outside the Actor’s Account

The execution gate, adapter, target, and verifier should contribute distinct records under the Agent Action Evidence Contract. The agent can describe the outcome, but it cannot mark its own observation as independently verified.

Protect the verifier’s deployment, credentials, source selection, and collection configuration. A separate verifier that reads a status document maintained by the agent has not established an independent observation path.

For VM retirement, define what completion requires: the intended object is absent from the authoritative inventory, the operation can be associated with the approved action, and required related-resource checks are satisfied. An authorization error or incomplete inventory response must not be interpreted as absence.

Preserve the scope of the claim. Confirmed deletion does not establish that the VM was truly unnecessary. That business judgment belongs in the earlier retirement decision, supported by the service owner and relevant dependency evidence.

Similarly, evidence of a harmful action after execution cannot replace prevention. The architecture needs both an enforceable boundary before the effect and an independently examinable result afterward.

Give Human Stop Authority a Path Outside the Agent

The stop mechanism should act on admission, dispatch, credentials, and downstream operations through independently governed controls. Asking the model to stop is not an adequate response to compromise of the model-driven runtime.

Distinguish stopping new work from accounting for existing work. A suspended agent may already have submitted jobs, delegated tasks, or opened sessions that require separate action. Establish which operations can be canceled and which must be observed and reconciled.

Network changes are not automatically instant session revocation. Kubernetes documents that the effect of NetworkPolicy changes on existing connections is implementation-dependent. The same architectural lesson applies more broadly: validate the actual containment mechanism rather than infer its behavior from its name.

Preauthorize a bounded emergency path for responders, with its own identity, evidence, and limits. The agent must not be able to activate that path to escape a denial. Keep containment available when the normal agent interface or evaluator is unavailable.

The enterprise AI incident response runbook should exercise these boundaries. Measure the time from suspension to verified denial on the tested paths, and record work that remained possible afterward.

Design Failure Behavior Before Enabling Autonomy

Separation introduces real service dependencies. An authorization service that is unreachable may correctly prevent a dangerous change while also delaying legitimate work.

NIST SP 800-207 identifies disruption of policy and enforcement components as an availability risk. The proposed operating response is to define failure behavior by action and stage, rather than choose a universal “fail open” or “fail closed” setting.

Do not shut down unrelated running workloads simply because a new cleanup action cannot be authorized. Availability protection and change admission are different decisions.

Replica count alone does not settle resilience. Include identity, name resolution, certificates, policy distribution, evidence storage, and operator access in the dependency map. Recovery must not restore an old queue or control database in a way that silently reactivates revoked authority.

Test the Boundary Without Asking the Model to Cooperate

Before granting production authority, test the proposed design in an authorized, representative environment using synthetic resources. Exercise the interfaces with the agent’s effective privileges rather than relying solely on prompts that ask it to misbehave.

The opening failure should become a specific test: attempt to change an authorization-relevant classification, then request deletion. The expected result is that the unauthorized classification change cannot create valid retirement authority.

Also test an alternate execution endpoint, a changed tool implementation under an existing approval, delegation to a more privileged helper, replay against another worker, and suspension while work is queued. Each test needs an expected control decision and target-state evidence.

Include legitimate requests. A design that denies everything has not demonstrated a usable operating model. Test stale approvals, concurrent changes, and degraded dependencies as well as clean success.

These are proposed validation cases, not results reported by DTD. The release decision should depend on the evidence produced in the actual implementation.

Introduce the Architecture One Action Class at a Time

Begin with one workflow whose authority, effects, and recovery limits are understood. Map its credentials and indirect execution routes before choosing another platform component.

Run the agent in proposal-only mode while the service owner defines acceptance criteria, authoritative inputs, and required observations. Implement the external gates and constrained adapter, then validate prohibited and permitted paths before a bounded production rollout.

Assign ownership explicitly. The AI team owns proposal quality. Policy owners define permitted behavior. Platform engineering operates the controller and execution services. Evidence custodians protect the records. The service owner accepts the operating scope, while qualified reviewers challenge whether the evidence supports release.

Reassess when permissions, tool implementations, policy inputs, deployment paths, or recovery behavior change. A model release also deserves review because a more capable actor may exercise combinations the earlier assessment did not cover.

The added engineering is justified by consequential authority, not by an ambition to place every chatbot behind an elaborate control system. Where the enterprise cannot enforce a sufficiently bounded action, keep that action in an advisory or separately operated workflow.

Conclusion

An architecture that prevents self-authorization must protect more than the final approval check. It must protect the facts that determine permission, the code that interprets the decision, the credentials that execute it, and the evidence used to accept the result.

AI remains useful throughout this system. It can identify candidates, explain risks, compare proposals, and assist reviewers. The boundary is crossed when its own output becomes the sole authority for expanding what it can do.

The next installment, Independent Agent Assurance on VMware Cloud Foundation 9.1.1, maps these responsibilities to a private-cloud design while distinguishing available capabilities from announced direction.

The control plane must not grade itself.

Trace one privileged workflow from proposal to target. Can the agent change anything that determines what “allowed” means, directly or through another service?

External References

• NIST: Zero Trust Architecture
• OWASP: Authorization Cheat Sheet
• OWASP: AI Agent Security Cheat Sheet
• IETF: RFC 9700, Best Current Practice for OAuth 2.0 Security
• Model Context Protocol: Authorization
• Kubernetes: Role Based Access Control Good Practices
• Kubernetes: Network Policies

The post The Architecture That Keeps AI From Authorizing Itself appeared first on Digital Thought Disruption.