AI agents need authority you can constrain and revoke

The operating problem is authority

An agent can complete useful work quickly because it can read information, choose a next step, and call tools. Those same abilities can turn a mistaken interpretation or malicious document into a consequential action. The security question is what happens between the model proposing an operation and a system allowing it.

The source of an agent's instruction matters. A user request, a retrieved web page, and a tool response do not carry the same authority. If external content can redirect a credentialed workflow, better inventory alone will not contain the damage. The operating controls must identify the actor, constrain the action, and provide a way to stop continued execution.

The 60-second summary

Start with the agents that can affect customers, money, sensitive data, or production systems. Give each an owner and an attributable workload identity. Record who delegated the task and what the agent may do. Enforce those permissions outside the model, at the tool boundary and the destination. Verify the released components, evaluate the workflow, and retain evidence that connects the request to its result. For media, provenance can help a recipient verify origin and editing history; it cannot establish truth. Finally, practice stopping the agent: block new actions, withdraw credentials, cancel queued work, and check downstream effects. The useful measure is how quickly the controls contain a real failure and explain what happened.

Five questions to answer with evidence

Apply these questions to suppliers as well as internal deployments. Record what a supplier can demonstrate, what it only asserts, and what your own team must enforce at the integration boundary.

• Which agents are in use, including employee-adopted tools and agents embedded in purchased products?
• What customer information, personal data, intellectual property, or operational data can each agent access and transmit?
• Which credentials does each agent use, who delegated them, and what permissions do they provide?
• Can the team stop new actions and contain running or queued work when an agent misbehaves?
• Can a reviewer reconstruct the request, policy decision, action, and outcome from protected records?

The control flow, from request to result

This flow may span several services. DNS filtering can restrict destinations, but a DNS record cannot authorize a particular refund, database row, or application operation. A gateway also needs coverage checks: direct API credentials or alternate network paths can bypass it.

1. REQUEST → Capture the initiating person or service, task purpose, and permitted resources.
2. IDENTITY → Authenticate the agent workload and preserve its distinction from the delegating principal.
3. POLICY → Check the specific action, destination, data, scope, expiry, and any required approval.
4. EXECUTION → Apply controls at the tool gateway, application, sandbox, and network boundary; record the result.
5. EVIDENCE → Connect the release, request, policy decision, tool operation, and output using stable identifiers.
6. CONTAINMENT → Withdraw authority, halt further work, preserve records, and verify downstream recovery.

Keep identity and delegated permission distinct

SPIFFE supplies an open framework for workload identity; SPIRE is one implementation. Identity provides an authentication foundation. The application must still decide which resources and actions that workload may use.

OAuth token exchange, described in RFC 8693, can represent delegation while retaining the distinction between subject and actor. Its availability does not determine your authorization policy. Define allowed audiences, resources, scopes, expiry, and delegation depth. An agent should receive only the permissions needed for the approved task, with further delegation explicitly controlled.

Consider a support agent asked to prepare a refund. It can read the relevant order and draft a recommendation. Executing the refund requires a separate permission and, above a chosen threshold, approval bound to the exact customer and amount. An instruction inside a support attachment cannot supply that approval.

Verify components and preserve useful provenance

Connect production execution to an approved release: model identifier, application version, tool configuration, and evaluation results. For artifacts you control, verify trusted signatures and digests before deployment. Signing proves neither model safety nor the correctness of its decisions. Hosted services require a different evidence agreement because the customer may not see the underlying weights.

When runtime attestation is useful, define which measurements a verifier accepts and how fresh its evidence must be. The RATS architecture in RFC 9334 provides the roles and appraisal model; the deployment supplies the trust policy.

For supported media workflows, C2PA Content Credentials can preserve verifiable statements about origin and editing history. Provenance is not truth. A valid credential does not make a synthetic event real or a recommendation accurate. Use a verification experience that explains these limits.

Practice revocation across the whole workflow

A stop button is useful only if its effect reaches the places where the agent can act. Disabling an identity may leave an existing session, a delegated token, or a queued job active. RFC 8693 explicitly does not make revocation propagation an automatic property of token exchange.

Test containment using a harmless simulated violation. Measure from detection through the last successful unauthorized attempt. Keep the evidence showing which controls blocked which paths.

• Block new task starts, credential issuance, and protected operations.
• Terminate sessions and running processes where supported; invalidate or deny outstanding credentials.
• Cancel queued work and stop child agents or separately delegated tasks.
• Identify completed external effects and perform the appropriate recovery.
• Resume through a reviewed configuration with a bounded test.

Make the next deployment earn broader authority

Choose one consequential workflow. In the first month, establish its owner, data map, credential inventory, and permission boundaries. Then connect runtime decisions to release and outcome records. Exercise hostile-input handling and containment before expanding scope.

A funding discussion should name the exposure and the demonstrated improvement: fewer shared credentials, smaller permissions, better evidence coverage, or faster containment. Keep behavioral evaluation and human oversight in the operating budget. Identity infrastructure can be reused from other workloads, but an AI deployment still needs its own evaluation, change control, and failure planning.

Questions to take back to your team

• Which agent has the greatest combination of sensitive data access and ability to change external state?
• Can its downstream service distinguish the agent from the person or system that delegated the task?
• Can any tool, credential, or network path bypass the intended policy check?
• What was the measured containment time in the last exercise?
• What evidence must exist before this agent receives broader authority?

Sources & further reading

1. OWASP: Prompt InjectionUntrusted input and the need for controls surrounding model behavior.
2. SPIFFE overviewWorkload identity and the relationship between SPIFFE and its implementations.
3. IETF RFC 8693: OAuth 2.0 Token ExchangeDelegation versus impersonation, resource and audience scope, and limits on automatic revocation propagation.
4. IETF RFC 9334: RATS ArchitectureAttestation roles, policy appraisal, and evidence freshness.
5. C2PA Content Credentials explainerVerifiable provenance and the distinction between provenance and factual truth.