I05 · Identity and authority · 7 min read
Every agent is a governed principal
If an agent can take consequential action, it needs its own attributable identity, a delegator, a purpose, an authority envelope, and an expiry.
By AISDLC Editorial · Published 2026-08-08 · Reviewed 2026-08-09
An agent that acts through a human’s session is difficult to distinguish from the human, difficult to revoke independently, and difficult to govern as its purpose changes. Borrowed credentials collapse accountability. They obscure whether a person, service, model, or policy mechanism selected the action and which authority actually permitted it.
Create identity before granting credentials
A credential proves that a caller possesses a secret or token. It does not explain why the action is legitimate. Agent identity must connect the technical principal to its sponsor, accountable owner, approved purpose, risk tier, deployment, model and harness versions, data classes, tools, review date, and kill authority.
This system record becomes the anchor for policy and evidence. When an agent requests a tool, the policy decision can evaluate not only the credential but the current purpose, resource, action, environment, transaction limit, time window, and required approval. The resulting effect remains attributable to the agent and to the human or service that delegated the work.
The delegation envelope
- Principal
- A unique non-human identity for the agent instance or governed service.
- Accountability
- A named sponsor and operational owner who can answer for purpose, performance, and retirement.
- Purpose
- The approved outcome and data use that justify access.
- Authority
- Allowed actions, resources, limits, environments, approvals, and explicit prohibitions.
- Time
- Start, expiry, recertification, suspension, and revocation conditions.
Protocol compatibility is not permission
Agent protocols make tools and other agents easier to discover and invoke. That expands capability; it does not establish trust. An enterprise authorization layer must still decide whether this principal may perform this action on this resource for this purpose now. Natural-language tool descriptions should never substitute for an enforceable policy decision.
Authority must expire when purpose or ownership does
Agents can become orphaned when a project ends, an owner changes roles, a vendor contract expires, or an integration is replaced. If access survives those events, the technical system has separated authority from accountability. Recertification should therefore trigger on time and on material change: owner, purpose, risk tier, model, harness, tool, data source, environment, or operating outcome.
Identity lifecycle
- Register · Create the system record Name the purpose, sponsor, owner, tier, technical identity, boundaries, and kill authority.
- Authorize · Issue bounded access Grant only the actions, resources, environments, and duration required for the approved purpose.
- Observe · Link action to authority Record policy decisions, delegated chains, tool effects, approvals, and outcomes.
- Recertify · Revalidate the operating envelope Reassess on schedule and whenever material identity, purpose, model, tool, or data state changes.
- Retire · Revoke before archive Stop events, remove credentials and access, preserve evidence, and confirm the system can no longer act.
Minimum agent system record
- Unique agent identity and deployment IDs
- Executive sponsor, accountable owner, and operations owner
- Approved purpose, risk tier, and prohibited uses
- Model, harness, tool, data, and environment versions
- Delegation and approval policy
- Review date, material-change triggers, and status
- Suspend, revoke, stop, and retirement authorities
Primary sources
AISDLC Insights publishes source-informed editorial synthesis and implementation positions. It is reference material, not a standard, certification, legal opinion, or authorization to deploy an agent.