When an agent acts for you, whose permissions should count?

An employee can issue a refund. An agent can call the refund tool. Does it follow that the agent can issue any refund the employee asks for?

Not yet. The service still needs to establish that the employee is who they claim to be. Their authority must cover this account and transaction. The agent must be permitted to perform this kind of work. The transaction must still be eligible. And the request must fall within whatever delegation the organization actually intended.

That is a lot to hide inside “acts on behalf of.” The phrase sounds like an explanation, but it mostly tells us which questions to ask next.

Start with the employee, the agent, and the refund

Take a hypothetical support workflow. A service agent handles refund requests for verified support employees. The organization permits ordinary support staff to request refunds up to $100 on assigned accounts. Supervisors can handle larger amounts, but nobody can refund an already-refunded transaction through this workflow.

There are several distinct facts here. The agent's identity tells the service which software is calling. The employee's identity tells it whose delegated request this is. The employee's assignment and refund entitlement describe their business authority. The ledger establishes the transaction's current state.

These facts need not come from the same source, and they should not all come from the agent's request body.

OAuth token exchange provides useful vocabulary for separating the party represented from the party acting. RFC 8693 distinguishes subject and actor information and leaves issuance subject to authorization-server policy. It does not choose a company's refund policy or prescribe one universal way to combine every party's permissions. OAuth token exchange specification.

Preserving both identities is valuable because the two parties can need different interventions. An employee may lose an account assignment while the agent remains legitimate. The agent may be suspended while the employee retains permission to do the work manually.

Write the business rule in a sentence

“Take the intersection of the permissions” is a useful starting intuition for many delegated workflows. It is not always a complete specification.

Which permission sets? Does the employee need direct API access, or a business entitlement expressed elsewhere? Is the agent allowed to prepare an action but not commit it? Does supervisor approval attach to a particular transaction or grant a temporary wider scope?

For the hypothetical support service, a clearer rule is: allow the request when this agent is approved for delegated refunds, the represented employee is verified and entitled to refund this account at this amount, and the ledger confirms the transaction remains eligible.

That sentence tells each part of the system what to check. Identity verification establishes the employee. An entitlement source supplies assignment and limits. The refund service checks transaction state at the point where it can protect the business operation.

It also reveals missing design choices. How fresh must the assignment be? What happens if the entitlement source is unavailable? Can approval expire while a request is queued? Those questions are easier to resolve before they become a confusing denial in production.

A label is not proof

An agent might send an account ID, a user ID, and a field saying approved: true. These can be useful request parameters. They are not evidence of ownership or approval merely because they appear in valid JSON.

In the example, the service should retrieve the transaction's account from its authoritative ledger. It should establish the represented employee through the chosen verification mechanism. If a human approval is required, the approval needs a trusted source and a defined scope.

Otherwise, the system has asked the requester to supply both the action and the reason it should be allowed.

The same distinction applies to model-generated explanations. “The customer qualifies” may be a recommendation worth reviewing. The component committing a refund still needs the facts its policy requires. A fluent explanation does not replace the ownership check.

Absence of a user can be legitimate

Not every agent action needs a person attached to it. A nightly reconciliation job can operate under standing service authority. Requiring it to borrow an employee identity may make the record less accurate, not more accountable.

The important distinction is whether the workflow was designed and approved to operate that way.

This table is a proposed design, not a universal authorization standard. Its value is that every row has an explicit explanation.

If a missing user causes the application to switch to a powerful service account, failed identity verification could give the request more permission. Decide what to do with that failure explicitly; don't let a convenient fallback make the decision.

Trace one refund before designing the whole framework

There is a practical alternative to building an elaborate delegation framework for every task: start with one consequential operation and trace its decision.

Write down who acted, whom they represented, what operation was requested, which resource was affected, and where each relevant fact came from. Then ask what changes if the employee loses access, the agent loses access, or the transaction changes before execution.

A narrow background task may need only a well-scoped service identity and ordinary backend validation. A delegated customer workflow may need several independently verified facts. The review should reflect that difference.

The goal is an authorization decision that someone else can explain without reading the model's mind. “The agent acted for this employee” should be the beginning of that explanation. The rest should explain why this employee and this agent were allowed to refund this transaction.