No AI Agent Without Identity (Part 3): Delegation, HITL, and Identity Propagation

Series Context In Part 2: Building the Layered Identity Model , we defined the architectural foundation for scaling agent identity: stable agent principals, temporal runtime or context instances, roles, policies, execution records, and audit records. In this part, we address what happens when agents operate under human delegation, human supervision, or through other agents. The focus is identity propagation: preserving accountability across humans, agents, runtime instances, tools, and agent-to-agent handoffs. Supervision Belongs in Identity and Policy Human-in-the-loop should be part of the agent’s governance posture, not just a workflow detail. A common and dangerous assumption is that adding a human in the loop makes strong identity unnecessary. Many organizations treat supervision as a sufficient safeguard on its own, and therefore see identity primarily as a control mechanism for fully autonomous agents. This view is flawed. If the enterprise cannot reliably identify the agent, it cannot enforce the requirement that the agent must operate under human supervision. In such cases, supervision often reduces to a fragile UI confirmation, a workflow convention, or an instruction in the system prompt — all weaker than policy-bound enforcement. This is why supervision must be attached to the agent’s governance model, not merely treated as a workflow step. When supervision requirements are represented through groups, roles, attributes, claims, or policy metadata linked to the agent identity, enforcement can move from the application layer into the identity and policy layer. This makes supervision a governable, auditable, and enforceable property rather than a hopeful assumption. Identity is therefore not only relevant for autonomous agents. It is foundational for all agentic operations — whether the agent is fully autonomous, semi-autonomous, delegated, or strictly supervised. An agent should be classified as supervised, autonomous-bounded, read-only, propose-only, execute-with-approval, or fully autonomous inside a narrow domain. This can be represented through groups, roles, attributes, claims, or policy metadata. In most environments, groups and roles are the preferred starting point because they are familiar, operationally simple, and widely supported — even in standalone or air-gapped systems where users and groups exist at the operating-system or application level. At minimum, an agent identity should not look like a normal human user. It should belong to a dedicated agent group, role, attribute, or classification such as AI-Agent, Non-Human-Agent, or Agentic-System, so policies, monitoring rules, access reviews, and audit queries can treat it as a distinct class of actor. Attributes, claims, and policy metadata can then add more dynamic context where needed: supervision state, autonomy level, risk tier, approved tools, approval requirements, or runtime conditions. For example: agent.supervision = human_required agent.mode = propose_only agent.mode = execute_with_approval agent.mode = autonomous_bounded agent.risk_tier = high agent.allowed_actions = read, summarize, propose agent.allowed_actions = execute_low_risk agent.approval_required_for = external_send, payment_release, privilege_change Supervision mode should not live only inside a prompt. Prompts are not a reliable source of enterprise policy. This matters because the same tool call may be acceptable for one agent and unacceptable for another. A security triage agent may be allowed to read incident logs but not disable accounts. A finance agent may be allowed to process approved invoices but not change vendor bank details. A customer support agent may be allowed to draft a response but not issue refunds without approval. A code agent may be allowed to open a pull request but not merge into production. The difference is not only technical. It is governance. The Human-in-the-Loop Trap Many organizations try to solve agent governance by adding human-in-the-loop (HITL) approvals to agentic workflows. The motivation is understandable. HITL looks like a simpler alternative to building real identity, access control, policy enforcement, and audit infrastructure. But that shortcut is not only insufficient — it creates its own trap. HITL is hard to implement correctly, and weak HITL can become security theater. LLM replies, confirmation messages, or MCP elicitation flows may be presented as human confirmation, but they cannot be treated as human-in-the-loop governance by themselves. Treating governance as secondary while hoping that human-in-the-loop combined with prompt-based instructions will be sufficient is a form of wishful thinking. These mechanisms may appear to provide control in limited or low-risk scenarios, but they do not deliver reliable, enforceable, or scalable governance once agents operate with meaningful autonomy or access to enterprise resources. Real governance requires deterministic boundaries in identity and policy layers, not hopeful assumptions expressed at the model or workflow level. At best, they are a demo shortcut: useful in prototypes, controlled pilots, and non-critical environments, but dangerous as the control foundation for enterprise agentic systems. The problem is simple: many current implementations ask the same model that wants to complete the task to also respect a supervision rule expressed in a prompt. That creates a trust threat at the heart of the system. A prompt-level instruction is not the same as policy-bound enforcement, and an LLM should not be trusted to enforce the boundary that constrains its own action. That is like enforcing system security by asking users whether they have the right to enter. These confirmation flows may work as a temporary patch inside closed environments where the organization fully controls the agents, tools, and services involved. But once third-party agents, external tools, or vendor-managed services enter the chain, that trust model collapses. At that point, Zero Trust has no mercy for informal confirmation flows. A prompt is not a policy engine. A popup is not governance. A friendly confirmation message is not an audit control. Real approval policy, evidence, and enforcement must live in the governance layer that controls identity, access, and execution. Human-in-the-loop is not outside identity and access management. It is one of the ways IAM should govern supervised agent action. As I argued in Human Approvals Are Not the AI Bottleneck - It Is Revealing the Bottleneck , HITL does not merely slow agentic workflows down. It reveals where the real bottleneck lives. The same is true here: weak HITL implementation is not just a supervision problem. It exposes the absence of a proper identity and policy layer. Identity does not stop at the first actor. Once agents act on behalf of humans, call tools, or delegate work to other agents, the enterprise needs an identity chain, not a single misleading username in a log. Do Not Borrow Human Identity One of the most dangerous shortcuts is allowing agents to act only through human identities. This usually begins innocently. The user is already authenticated. The agent is helping the user. The agent needs to call a tool. The easiest implementation is to let the agent act through the user’s session. That may be acceptable for narrow delegated actions if the agent’s role is clearly recorded and scoped. But it becomes dangerous when the agent’s independent behavior disappears behind the human’s identity. Audit logs that say “Maria changed the record” may be misleading if Maria delegated a task to an agent, the agent selected the record, the agent generated the change, and Maria never directly reviewed the final field update. The problem is not only accountability. It is also operational visibility. Even when human approval is explicit, the user may not see the agent’s intermediate choices: which tool it selected, why it selected that tool, whether it ignored cheaper or safer alternatives, whether it repeatedly called the same service, or whether its prompt and context pushed it toward expensive, overloaded, or risky behavior. Without traceability, the organization cannot diagnose whether the problem came from the human, the agent, the prompt, the tool, the policy, the context, or the service being called. It also cannot improve the system intelligently. Maybe the agent needs a better prompt. Maybe it needs narrower tool access. Maybe a paid tool should require approval. Maybe a service needs rate limits. Maybe the agent’s role should be changed. Borrowed human identity hides all of that behind the user. Delegation is acceptable and governable. Impersonation is dangerous. Borrowed human identity breaks blast-radius control and destroys least privilege in both directions. A privileged user may want to use an agent with narrower scoped rights precisely to reduce risk. The agent should not inherit root-level access simply because the human has it. The reverse can also be true. A normal user may delegate a task to an agent that is allowed to run one specific administrative service under strict policy, approval, and audit controls. That does not mean the user should receive broad administrative access. Human access and agent access should not be treated as identical. Delegation should preserve the authority chain while still allowing the agent’s permissions to be narrower, more specific, or differently governed than the human’s permissions. Delegation preserves the human, the agent, and the authority chain. Impersonation collapses them into one misleading identity. When an agent operates on behalf of a human, the audit trail should preserve the chain: human authorized → agent acted → policy evaluated → tool executed → evidence retained. A simple attribution chain could look like this: human_principal = user-maria agent_identity = contract-review-agent-v1 runtime_instance_id = worker-12 access_record_id = access-20260620-184739-7f3a9b delegation_state = user-authorized supervision_state = approval-required policy_decision = allow-after-approval action = update-contract-clause This identity chain also enables compound policy rules. The enterprise can enforce not only whether an agent is allowed to perform an action, but whether a specific human is allowed to delegate that action to that specific agent under that specific supervision mode. For example: user Maria may be allowed to use ContractReviewAgent for contract-clause updates, but not PaymentReleaseAgent ; or ContractReviewAgent may be allowed to act for the legal team but not for finance. Without the identity chain, those rules collapse into a vague question of whether “Maria” was allowed to do the action. This is the difference between delegation and impersonation. The agent may operate on behalf of a human, but it should not disappear into the human. Without that distinction, the organization is not auditing autonomy. It is auditing shadows. Preserve Identity Across Agent Chains Human-to-agent delegation is only one part of the problem. As agentic systems become more complex, one agent may call another agent, helper component, retrieval component, workflow component, remediation component, or specialized tool agent. That handoff should not break attribution. The important question is whether the secondary component is only a resource of the primary agent, or whether it is an actor with its own identity. If a secondary component does not have its own identity, does not act independently, and only operates as an internal resource owned by the primary agent, then the primary agent remains the accountable actor. The audit trail should still record the component call, but the component does not become a separate autonomous identity. If the secondary component has its own identity, makes decisions, calls tools, accesses resources, or acts independently, then it becomes an actor in the chain. In that case, identity must be preserved across the handoff. Identity propagation is not only for audit after the fact. It is also for policy enforcement before the action happens. The enterprise should be able to decide whether the primary agent is allowed to call the secondary agent, whether the secondary agent is allowed to use a specific tool, and whether the handoff requires human approval, narrower permissions, or additional logging. A simple attribution chain could look like this: human_principal = user-maria primary_agent_identity = security-triage-agent-v2 primary_runtime_instance_id = replica-47 secondary_agent_identity = remediation-agent-v1 secondary_runtime_instance_id = worker-19 access_record_id = access-20260620-184739-7f3a9b delegation_chain = user-maria → security-triage-agent-v2 → remediation-agent-v1 tool_called = account.disable supervision_state = approval-required policy_decision = allow-after-approval The secondary agent should not automatically inherit the primary agent’s permissions. Each actor in the chain should be evaluated according to its own identity, role, context, supervision state, and allowed actions. This distinction matters. A component without its own identity is a resource of the primary agent. A component with its own identity becomes an accountable actor. Agent-to-agent delegation without identity propagation creates the same problem as human impersonation: the final action may be visible, but the chain of accountability is broken. Runtime Instance Identity and Context Lineage A stable agent identity is not enough for runtime attribution. If ten replicas of the same agent are running, the enterprise may need to know which replica acted. If an agent failed over from one region to another, the enterprise may need to know which runtime instance executed the action. If an agent behaves unexpectedly, engineering and security teams need to trace which agent instance acted, under which context, under which delegated authority, under which policy state, and against which resource or tool. Dynamic replica agents benefit from unique runtime identifiers. Representing runtime instances in the identity and access management layer can have benefits, but it does not always require a permanent directory account per replica. In many environments, the stable agent identity is enrolled in the enterprise identity system, while runtime instances receive workload identities, signed attestations, short-lived certificates, scoped tokens, or runtime identifiers linked back to the stable identity for scalability reasons and technical constraints. The key is traceability. The logs should not say only: agent-invoice-processor-v2 accessed invoice database They should be able to say: agent_identity = agent-invoice-processor-v2 runtime_instance_id = replica-47 access_record_id = access-20260620-184739-7f3a9b resource = invoice-database policy_decision = allow supervision_mode = autonomous_bounded Context refreshes need similar lineage. A context refresh can change what the agent knows, what it ignores, what it remembers, and what it is able to justify. The enterprise should know not only that the context changed, but who or what changed it: a user, another agent, a retrieval system, a memory layer, a tool response, a policy update, or the orchestration layer itself. That is why preserving the identity chain is essential for governance. That means context refreshes should not be invisible runtime behavior. A material context refresh should create a traceable context version, context hash, session record, or updated temporal instance record linked back to the same agent identity. For example: agent_identity = agent-contract-review-v1 runtime_instance_id = agent-contract-review-v1-worker-12 access_record_id = access-20260620-184739-7f3a9b context_version = ctx-20260620-184812-d91c2e context_hash = sha256:... policy_snapshot = policy-20260620-v14 In highly regulated or high-risk environments, stronger models may be justified. The rule remains: Every meaningful agent instance needs attributable identity. Every meaningful access event needs a traceable record. What This Part Establishes This part shows that supervision and delegation must be treated as governance concerns, not merely workflow steps or prompt instructions. It explains why agents should not disappear behind human identities, why agent-to-agent handoffs must preserve attribution, and why runtime and context lineage are necessary for accountable delegated action. Previous: ← Part 2: Building the Layered Identity Model Next in the series: → Part 4: Deterministic Control, Revocation, and MCP Enforcement