AI agent access control at the action boundary

AI agent access control decides whether a particular agent can perform a particular operation on a particular resource. The decision belongs in software that controls the resource or the route to it. An instruction to the model cannot replace that check.

Start with a concrete request: a diagnostic agent wants the health status of the checkout service. The access decision needs the agent’s verified identity, the requested operation and the target environment. If the agent later asks to restart the service, evaluate that request separately.

Model the request before choosing a policy system

List the facts the enforcement point must know. Some can come from the request, but facts that establish authority need a trusted source.

Fact	Suitable source
Agent identity	Validated credential or workload identity
Account or tenant	Trusted identity mapping
Operation	Parsed request using a declared action definition
Target	Resolved resource record
Approval	Stored authorization for this request
Time limit	Policy and credential expiry

An agent-supplied field claiming “administrator” is input to inspect, not proof of a role. The same applies to a customer identifier copied from a prompt.

NIST’s zero trust architecture rejects implicit trust based only on network location or ownership. An internal network address should not exempt an agent request from access checks.

Keep authentication and authorization separate

Authentication establishes which identity made the request. Authorization decides whether that identity may do the requested work. A valid credential can identify an agent whose permission has expired or whose task is outside the requested resource scope.

Check authorization on every relevant request. OWASP’s authorization guidance recommends denying by default and validating permissions consistently. Apply the same rule to retries and alternate entry points.

For example, a CLI and an MCP tool may both call the same operation. If only the MCP handler checks permission, the CLI becomes a bypass. Put shared authorization close enough to execution that every supported caller reaches it.

Express useful permissions

A broad label such as “operator” often hides several decisions. A more useful permission combines an action with a resource scope and conditions.

A diagnostic identity might read selected metrics for one service in production. A maintenance identity might request a restart of one instance, with approval and a concurrency limit. Neither needs permission to create new identities.

Avoid treating the method name as the entire security contract. An action called “read report” could still return sensitive material or consume substantial resources. Review its inputs, downstream calls and output destination.

Handle approval without changing the permission model

Approval should authorize a request that policy allows a reviewer to approve. It should not give the requester a general-purpose credential or unrestricted session.

The following is conceptual pseudocode, not runnable policy syntax:

If the identity is invalid: deny
If the account does not own the target: deny
If the action is outside the allowed resource scope: deny
If the request has expired: deny
If a supplied approval has expired: deny
If policy requires approval and this request lacks it: wait
Otherwise: execute the validated request

This sketch leaves implementation details open. Systems also need to handle conflicting rules, concurrent changes and failures in the components that supply trusted facts.

Inspect downstream authority

A narrow API can still accept input that causes an administrator operation in the backend. Trace the request until it reaches the actual service, process or host that performs the work.

For MCP integrations, the protocol’s security guidance discusses token passthrough and confused-deputy risks. Credentials issued for one audience should not become a general authorization shortcut for unrelated services.

For a CLI, inspect the operating-system account and accessible credentials. A wrapper can offer a narrow command while the process still has access to files or tokens that expand its authority.

Test paths that look almost valid

Use test resources to check the approved operation, then change one material fact at a time. Try a different tenant, an unassigned target, an expired approval or a disabled identity. Confirm that denial happens before the side effect.

Test alternate client paths too. A failure should produce a clear status and an audit event without exposing credentials. Keep the expected results with the policy so reviewers can detect an integration update that changes the agent’s permissions.