They should preserve attribution from the initiating person through every hop, tool call, and backend service so the action can be traced end to end. The agent should not become a separate standing identity with its own entitlements. That keeps accountability intact while still allowing the workflow to run under live policy.
How to handle an agent that is acting for a human principal
The practical rule is to keep the human principal attached to the workflow, not to hand the workflow over to a new standing identity. Every action should remain attributable to the initiating person, with the agent operating as a delegated mechanism rather than an independent actor. That preserves accountability, supports policy enforcement, and avoids turning convenience into persistent privilege.
That distinction matters because the security question is not whether the agent can execute work, but whether the delegation model still lets teams answer who approved it, who is responsible for it, and what scope was actually granted. When teams lose that chain, they usually lose both governance clarity and the ability to constrain downstream access.
Preserve the principal through the full action chain
In a human-on-behalf-of pattern, the identity that matters is the initiating person, plus the proof that the agent is authorized to act within a bounded context. The agent may exchange credentials, call tools, or pass through backend services, but those hops should preserve the original principal claim rather than replacing it with a generic shared account.
This is the same design logic behind delegation and token exchange patterns. For teams building the flow, the useful question is whether each system can see both the caller and the delegated scope, not just whether the request is technically authenticated. That is why RFC 8693: OAuth 2.0 Token Exchange is often the cleanest delegation model when an agent must act on a person’s behalf.
Preserving attribution also means keeping the agent’s authority narrow. The agent should carry only the permissions needed for the specific task, ideally with per-action checks and time-bounded access, so the human principal does not inherit uncontrolled standing privilege through automation.
Do not let the agent become a separate identity
If the agent is treated as its own durable identity with broad entitlements, teams usually drift into overprivilege, weak ownership, and ambiguous accountability. The more the agent looks like an autonomous account, the more likely it is to accumulate access that no longer matches the original human intent.
That risk is why agent identity must stay subordinate to delegated authority. A good operating model lets the agent prove it is authorized to act, but not own the action in the way a separate employee or service account would. The Agentic AI Identity Guide is useful here because it frames delegation, registration, ownership, and retirement as lifecycle controls rather than one-time setup choices.
Teams should also distinguish between “the agent can act” and “the agent should retain access.” If the workflow ends, or the human principal’s approval expires, the delegated capability should collapse with it. Otherwise, the system quietly turns temporary representation into persistent access.
Build traceability into policy, logs, and approvals
To make on-behalf-of execution defensible, teams need traceability at every hop: the original principal, the delegated action, the tool invoked, and the backend service that executed it. If any hop drops that chain, incident response and audit review become guesswork.
The operational standard is to log attribution in a way that survives orchestration layers, queueing, and service-to-service calls. That includes correlation of the human principal to the agent action and, where relevant, to the downstream service decision. The AI Agent Observability, Audit and Incident Response Guide is relevant because it focuses on agent attribution, logging, and the signals that show when delegated action has gone wrong.
For teams that want the policy side rather than the observability side, the key control is authorization at the point of use. That means the request should be checked against the task, the principal, and the current context, not merely against a reusable credential. The AI Agent Authorisation Guide reinforces that per-action policy and least privilege are what keep delegation bounded.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Non-Organizational Users) | Covers delegated non-human and service-to-service authentication in on-behalf-of flows. |
| AC-6 — Least Privilege | The agent should only receive the minimum scope needed for the delegated task. | |
| AU-3 — Content of Audit Records | Traceability depends on logging the human principal, delegated action, and downstream service hop. | |
| Recommendation — Require delegated workflows to authenticate the acting component while preserving the original principal context. Limit each delegated action to the minimum permissions required for the specific request. Record principal, delegated scope, and target service in each audit event. | ||
| NIST Zero Trust (SP 800-207) | N/A — Zero Trust Architecture | On-behalf-of execution benefits from continuous verification and no standing trust across hops. |
| Recommendation — Verify the principal and request context at each hop instead of trusting the agent once. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The question is directly about preventing an agent from becoming a separate privileged actor. |
| ASI02 — Tool Misuse | Delegated agents may misuse tool access if scope and approval are not tightly bounded. | |
| Recommendation — Prevent agents from accumulating standing privilege beyond the human principal's delegated scope. Constrain tool access to the smallest approved action set for the delegated task. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | When a human principal is represented by an agent, the initiating user's identity assurance remains relevant to accountability. |
| Recommendation — Bind delegated actions to the assurance level of the initiating human identity. | ||
Practitioner Guidance
What to verify: Confirm that every request can be traced from the initiating human principal to the final backend action without losing the delegated context. If a service only sees “an agent” and not the underlying person plus scope, the design is too coarse for accountable delegation.
Decision rule: If the workflow needs persistence after the human session ends, treat that as a separate access design problem rather than a reason to grant the agent standing identity. Short-lived delegation is usually the safer default; durable access needs a stronger justification and tighter review.
Common mistake: Teams often solve convenience by giving the agent its own account, then spend the next review cycle trying to reconstruct who really approved what. That reverses the order of control, because attribution and authorization should be preserved by design, not recovered after the fact.
Practitioner takeaway: The best on-behalf-of model keeps the human principal visible, keeps the agent bounded, and makes every downstream action explainable without pretending the agent is the owner of the authority.