Agent Identity and Custody
Agent identity and custody is the governance principle that every AI agent operating in a service estate carries an identity in the same identity system as the people it works beside, resolves to an accountable human owner, holds a permission set derived from the documented processes it is authorized to execute, and accumulates a measured reputation. All of this is established before the agent is delegated any work. The principle has three parts: identity before delegation, the paper trail is the control, and reputation is measured, not assumed. It is the fifth stage of the agentic journey map, and the custody attribute is what the agent overseer role is anchored to. AI Workforce Governance Frameworks owns the organizational accountability chain — the principle that every AI decision must trace to a human, and the audit framework around it; this page concerns the attributes an individual agentic node must carry for that chain to be operable.
Identity before delegation
Everything an agent does — communicate with a customer or supplier, transact, act on a system of record — presupposes an identity, and the identity must resolve to an organization and a person. The argument is well established for human users of digital systems: an identity is an assertion of who is acting, and the assurance a counterparty can place in an action is bounded by the assurance behind the identity.[1] The design argument for agents runs the same way from the network side. Trust on the internet originates in domains: a sender on an organization's domain is presumed to be that organization's delegate, and the trust a collaboration tool places in a user derives from the organizational identity used to enroll. An agent that carries an organizational identity therefore inherits that trust rather than having to build it. The policy literature on identifiers for AI systems reaches a compatible conclusion: the ability to attribute a system's actions to an accountable party is a prerequisite for most other governance mechanisms, and an identifier should carry enough information for a counterparty to decide whether to interact.[2]
For a service operation the operational form is a set of attributes on the agentic node's record:
| Attribute | What it holds | Where it comes from |
|---|---|---|
| Identity | An entry in the same identity provider as human staff, on the organization's domain | Identity and access management, provisioned like a joiner |
| Owner | The named overseer the agent resolves to; the "end manager" a counterparty can be told about | The overseer role |
| Permissions | The systems and actions the agent may use, derived from the tools column of the step tables of the processes it is authorized to run | The L0–L3 step table |
| Eligibility | The work the agent may not touch: contractually barred, regulated, or above a stakes threshold | The placement constraint register |
| Reputation | Catch rate, reliability under repetition, exception rate, and the throttles applied | The catch-rate program |
The permission attribute is the important one. An agent's permission set is not a policy someone wrote; it is derived from the documented processes it runs. An agent with permissions broader than its step tables require has permissions nobody can justify, and that gap is where the documented failure modes of delegated agents live: instruction injection through content the agent reads, and unbounded enrollment or action on third-party services, are both failures of an agent holding more authority than its task needed.
Where an operation wants agents to enroll in third-party services on their own, the standard mechanism is federated sign-in on an open identity protocol, so that the agent's organizational identity is what the third party sees and the organization's controls travel with it.[3]
The paper trail is the control
Every action an agent takes produces a record its overseer can read, in one place. Email has historically played this role for people because nearly every action on the internet produces a message — a receipt, a confirmation, a reply — and the inbox becomes the system of record of what was done. The same design logic applies to an agent, whatever channel carries its records.
An operation does not need email to get the property. It needs one record per run, one per exception and one per band change — the trigger log and the exception queue proposed in the handover gate — readable by the overseer and auditable by the placement function. Three things follow. The overseen phase's catch rate can be computed rather than estimated. Test five of the gate — reversible and logged — is cheap to pass. And when a counterparty disputes an agent's action, the answer is a record rather than a reconstruction.
Reputation is measured, not assumed
Appropriate reliance on automation requires that its reliability be measured and that trust be calibrated to the measurement; over-trust and under-trust are both failures of calibration.[4] For an agentic node the measurements are the catch rate per process, the reliability-under-repetition figure the gate's third test produces, and the exception rate. They are held as attributes on the node's record, not in a policy document, and the throttles that follow from them — what the agent may do without an overseer's sign-off, how many actions per period, which counterparties — are governance objects that the placement function can read.
The same logic can be applied at platform level as a design choice: a reputation score per agent identity, a mapping to the human who created it, and caps enforced at the interface — so many enrolments per human, so many actions per service. The operational form is that an agent's throttles tighten when its measured reputation falls and loosen when the catch rate has been stable for a defined period, and both movements are logged.
The antipattern
The principle exists to prevent one specific outcome. Several heritages, or several teams, each deploying their own agents with their own identities, permissions and records, produce an estate in which no agent's authority can be stated, no action can be traced to an accountable person, and no two agents' reliability can be compared. This is the agentic form of shadow automation: the condition in which employees run unmanaged tools on their own accounts, reproduced with agents instead of tools. The standardization stage is the governed layer that prevents it; identity and custody are the part of that layer that concerns agents specifically. The accountability chain that AI Workforce Governance Frameworks sets out at organizational level is only enforceable when each node carries the attributes above.
Maturity Model Position
Identity and custody are established at Level 4, when the first agentic node enters the placement register and needs an owner. At Level 5 the reputation attributes drive the throttles automatically within the operating loop. AI Workforce Governance Frameworks and Generative AI Governance for Workforce Systems cover the wider governance landscape; this page concerns the attributes an agentic node must carry to be planned and placed at all.
See Also
- The Agent Overseer — the owner the custody attribute names
- The Agentic Handover Gate — where the paper trail and the reputation measures are used
- Standardize Before You Automate — the governed layer this principle belongs to
- AI Workforce Governance Frameworks — the wider governance landscape
- Generative AI Governance for Workforce Systems — governance of generative systems specifically
- The Agentic Journey Map — the stage sequence
References
- ↑ National Institute of Standards and Technology (2025). Digital Identity Guidelines (NIST Special Publication 800-63-4). Gaithersburg, MD: NIST. doi:10.6028/NIST.SP.800-63-4.
- ↑ Chan, A., Kolt, N., Wills, P., Anwar, U., de Witt, C. S., Rajkumar, N., Hammond, L., Krueger, D., Heim, L., & Anderljung, M. (2024). "IDs for AI Systems". arXiv:2406.12137. (Preprint.)
- ↑ Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., & Mortimore, C. (2014). OpenID Connect Core 1.0. OpenID Foundation.
- ↑ Lee, J. D., & See, K. A. (2004). "Trust in Automation: Designing for Appropriate Reliance". Human Factors 46 (1), 50–80. doi:10.1518/hfes.46.1.50_30392.
