An authenticated agent can still perform an unauthorized task because identity proves who is acting, while authorization determines whether that action is allowed in the current context. Production controls must evaluate the task, target, tool, data scope and timing at the moment of execution.
The dangerous incident pattern looks ordinary in access logs. The agent presents a valid credential, the identity provider accepts it, and the downstream system processes the request. Every component behaves as configured.
The failure sits in the gap between those components: nobody checked whether this authenticated agent should perform this particular job.
A valid identity answers only one question
Authentication establishes identity. It can confirm that a request came from a registered agent, service account or workload rather than an unknown caller.
That matters, but the conclusion is narrow. A valid login does not establish that the agent received an approved instruction, selected the correct customer account, stayed within the current workflow or used a tool for its intended purpose.
Consider the permissions an operations agent might need. It may read support tickets, inspect account settings and issue refunds within defined limits. Those permissions can be legitimate individually. A request can still be wrong if the agent applies a refund to the wrong customer, acts on an unverified message or continues after the approval window has closed.
The credentials remain valid throughout. The job does not.
This distinction becomes more important as agents move across systems. A single task may involve reading a message, querying a database, opening an internal dashboard and sending an external response. Authentication can succeed at every step while the chain as a whole exceeds what the user approved.
Authorization must travel with the task
Static role-based access often gives an agent a broad set of actions it may perform. Task-level authorization should narrow that set for each run.
A useful authorization record should bind the request to concrete limits:
- The named task and originating instruction.
- The tools permitted for that task.
- The accounts, records or repositories in scope.
- Spending, refund or transaction limits.
- Required human approvals.
- An expiry time and a clear completion condition.
These constraints need enforcement at the tool boundary. A sentence in the system prompt does not stop a database, payment API or deployment service from accepting a technically valid request.
This is where current infrastructure work around cryptographic agent identities and granular tool-call filtering matters. Stronger identity can make agent activity easier to attribute. Filters can block disallowed calls before they reach sensitive systems. Neither control supplies business intent on its own, so teams still need a policy layer that connects identity, task and action.
That policy should be specific enough to distinguish “read the deployment status” from “restart production,” even when the same agent can do both under different circumstances.
Logs should show why the action was allowed
Most audit records answer who, what and when. Agent systems also need to preserve why.
For each consequential action, record the task identifier, the instruction source, the policy decision, the resources in scope and any approval used. Keep the credential reference separate from the authorization evidence. That separation makes it possible to see whether the identity was valid but the job was not.
Avoid logging secrets, raw tokens or reviewer credentials. Record an approved secret location or credential identifier instead.
Clear denial reasons matter too. “Unauthorized” gives an operator little to investigate. “Repository outside task scope” or “refund exceeds approved limit” points directly to the failed control.
These records also make incident review more useful. Without them, investigators can prove that an agent made a call but may be unable to reconstruct why the system permitted it. That is the same ownership problem examined in The Commit That Was Not Yours: attribution needs enough context to support a decision, not merely a name attached after the fact.
Put the final check beside the consequence
The strongest control sits immediately before the action that changes state.
Before sending an email, merging code, moving money, deleting data or modifying production, the system should re-evaluate authorization against the current task. Check that the target still matches, the approval remains valid and no earlier tool output has silently changed the job.
High-impact actions should also support a stop point. Present the proposed action, affected resource and reason in plain language before execution. Stop Before You Send explores why that pause matters when an automated system is about to cross an external boundary.
Test these controls with mismatched cases, not only happy paths. Give the right agent the wrong customer record. Reuse a valid approval after expiry. Ask a read-only task to invoke a write tool. Switch the target between approval and execution.
The test passes when the final system refuses the action and records the exact policy that stopped it. A successful login should be the beginning of that decision, never the end.
Comments
No comments yet.