Your AI Agent Should Not Borrow the Requester’s Identity

An AI agent can receive a legitimate request and still perform an unauthorized action.

The failure happens when the system treats the human requester and the agent as the same principal.

Consider a hypothetical example. An employee asks an internal AI agent to prepare a supplier payment. The employee is allowed to view supplier records, but payment release requires a second approval.

The agent calls the finance system using the employee’s access token. The finance system sees an authorized user and accepts the request. It has no way to tell whether the employee clicked “Release payment” or whether an autonomous process made the call on their behalf.

The original request may have been valid. The resulting action still bypasses the control designed for payment release.

That distinction matters because intent and authority are different things.

The human requester establishes context: who asked, what they wanted, and when the request began. The agent needs its own identity to represent the process that interpreted the request, selected tools, and took action.

If those identities collapse into one, several controls become unreliable:

• Access logs show the employee, not the agent.
• Approval rules evaluate the requester instead of the specific action.
• Revoking the agent’s authority means revoking the employee’s access.
• Investigators can’t separate human decisions from autonomous steps.

The practical control is to preserve both identities throughout the execution path.

A platform team should inspect whether every agent action carries:

1. The human requester
2. The agent identity
3. The requested operation
4. The target resource
5. The policy decision
6. The approval state

The downstream system should authorize the action against the agent’s delegated permissions, while retaining the requester as context. That lets policy ask a more precise question:

“May this agent perform this operation on this resource for this requester, under these conditions?”

That question is harder to implement than checking whether the employee has access. It is also the question that reflects how agentic systems actually behave.

The control should run at action time, not only when the conversation starts. An agent may begin with a harmless request, retrieve new information, and then decide to call a sensitive tool. The authorization decision must apply to the action the agent is about to take.

For security leaders, the buyer test is simple:

Can your audit trail prove the difference between what the person requested, what the agent inferred, and what the system allowed?

If the answer is no, the system may have authentication without meaningful agent accountability.

Learn more about AXEC and schedule a meeting