Identity Lifecycle for AI Agents - Registration, Delegated Authorization, Access Review, and What Retirement Leaves Behind

First Published: 2026-08-21
Last Updated: 2026-08-21

Most teams remember the day they put their first agent into production. The authorization design took time. The scope was narrowed, the token lifetime was shortened, and the audit logs were confirmed to appear. The second agent went out by the same steps. By the third there was a runbook, so it went faster.

The twelfth agent is about to go out. The runbook is working well. What it does not answer is who finds the permissions the first agent still holds.

The person who built the first one moved to another team. Two of the users that agent acted for have left the company. The agent itself is running. No one calls it any more. No one holds a reason to stop it, so it has not stopped.

Vendors compete to write the procedure for adding agents. The explanations of the authorization protocols are thorough as well. How to assemble delegated token exchange is already held by Section 5.2 of Agent Interoperability Architecture on AWS, and this article does not re-explain that mechanism. OWASP Top 10 for Agentic Applications Mapped to AWS Controls holds the mapping of the threat classification onto AWS controls.

No one has written the procedure for the other direction. That is what this article covers. When the full run from registration to retirement is followed through, who decides at each stage, what is recorded, and what is left at the end? Answering retirement head-on is the axis.

Here are several preliminary clarifications. Amazon Bedrock AgentCore Policy Implementation Guide holds the Cedar policy grammar, and Amazon Bedrock AgentCore Implementation Guide Part 2 holds the implementation steps for AgentCore Identity and Gateway. AWS IAM Access Analyzer Deep Dive holds how to use IAM Access Analyzer, and this article only adds what those tools can and cannot answer about an agent. MCP Server Implementation Reference holds how to implement MCP authorization, and Model Context Protocol Specification Version Timeline holds the specification versions and the migrations between them. Agent Sandboxing and Blast-Radius Isolation on AWS covers how to choose an agent's execution boundary. AI Agent Engineering Glossary holds the term definitions, so this article carries no glossary section. Agent-based payments fall outside the scope of this article.

This article does not prioritize AWS documentation as the primary source material. Instead, the focus is on the specifications themselves. These include IETF RFCs and Internet-Drafts, W3C recommendations, the Model Context Protocol specification, and publications from the Decentralized Identity Foundation. This article reaches for the AWS documentation only to confirm that a mechanism the specification describes really exists on the AWS side. All verifications within this article were conducted on August 21, 2026.

One last limit on scope. Principals on AWS fall into three kinds: human identities, workload identities, and agent identities. This article covers agent identities only. Identity-Aware Data Access on AWS takes the path a human identity travels from the corporate directory down to the data layer. AWS IAM Inbound Workload Federation takes the paths through which external workload identities enter AWS.

1. What Breaks When One Agent Becomes Twelve
2. Is an agent identity a third class?
3. Registration — Who Approves, and Where the Approval Is Recorded
4. Delegated Authorization — Recording the Chain and Deciding the Scope
5. Access Review — What Differs from Reviewing People
6. Retirement — What You Delete, and What Remains
7. Where the Standards Are Right Now
8. Where the Primary Sources Disagree with Each Other
9. The Smallest Operation You Can Put in Place Tomorrow
10. How This Fails in Practice
11. What This Design Still Cannot Answer
12. Frequently Asked Questions
13. Summary
14. References

1. What Breaks When One Agent Becomes Twelve

1.1 The Runbook Only Covers One Direction

The process for adding an agent typically involves the following steps: create a workload identity, configure authorization, define the necessary scope, verify functionality, and implement monitoring.

This procedure lacks a concluding section. It does not describe the process for removing an agent. This omission is not due to negligence; when the first agent was created, the need to remove it had not been anticipated.

When scaling from one to two agents, this asymmetry does not present a problem, as everyone remembers all of them. The issue arises when the number of agents exceeds what individuals can realistically keep track of. That number varies from person to person, but it almost certainly becomes problematic when it surpasses ten.

1.2 What Is Lost as the Number Grows

Three things are lost.

The first is the information about who owns it. When the person who created it moves on, that agent ends up without an owner. It continues to function, so no one is inconvenienced. Because no one is inconvenienced, no one takes responsibility for it.

The second is the reason those permissions were granted at all. The permission itself remains, but the reason disappears. Because the reason is lost, there will be no one to determine whether it can be removed.

The third is the material for judging whether it is still needed. This one weighs the most. With a human identity you ask the person. There is no asking an agent.

1.3 The Cycle This Article Covers

This article takes the following four stages in order.

Stage	What it decides	Who decides
Registration	What the agent may act for, and who owns it	The approver
Delegated authorization	On whose behalf and with which scope	The delegator
Access review	Whether it is still needed	The owner and audit
Retirement	What gets deleted	The owner

Four stages of the agent identity lifecycle and who decides

These four stages are not a cycle. Retirement is the final stage. If a retired agent is wanted again, the process starts over from registration. The diagram does not draw them as a cycle for that reason. Drawing a cycle invites the reading that going around is itself a sign of health. A state that keeps going around is indistinguishable from a state where retirement has never once happened.

2. Is an agent identity a third class?

2.1 The Claim

An agent identity is a third class, neither a human identity nor a service account identity. This is the backbone of the article.

This argument is not based on a preference for categorization. Getting the class wrong throws the whole operational design off. Treating an agent identity as a human identity implies an operational model that accounts for events like employee termination. Conversely, treating it as a service account assumes a scenario where there is no principal being represented. Neither of these assumptions applies to agent identities.

The argument earns its ground by showing, one at a time, what does not hold for a human identity and what does not hold for a service account.

2.2 What Does Not Hold for a Human Identity

The operation of human identities follows a pattern known as "joiner-mover-leaver." AWS IAM Identity Center Complete Setup Guide holds the design of that shape, so this article writes no procedure for it. Instead, it will focus on the underlying assumptions.

There are three key assumptions.

First, one human being stands behind the identity, and an authoritative source records that person's employment status. A departure entered in the HR system sets off a chain that takes the permissions away. Something else pulls the trigger.

Second, it must be possible to query that individual. During a review it is possible to ask whether the permissions are still needed. The answers may not always be accurate, but a person exists who can provide them.

Third, there is only one subject, the person. When someone operates with their own identity, no second identity waits behind them.

These three assumptions do not hold true for agents. Agents have no employment status, and there is no authoritative source that records events equivalent to a departure. The trigger must be pulled manually. There is no one to ask either. The person who built it may no longer be around. And a second identity always waits behind the agent.

2.3 What Does Not Hold for a Service Account

Service accounts have long been used as identifiers for non-human entities. They run batch processes, call APIs, and operate without human intervention. Up to this point, they appear similar to agents.

The key difference lies in the origin of their permissions. Service accounts operate using their own assigned permissions. The permissions granted to that account directly define the upper limit of what it can do. The identity that initiated the operation does not affect this limit.

Agents, on the other hand, function using the permissions delegated to them. The range the same agent reaches changes between a call from user A and a call from user B. If the scope remains the same regardless of who calls it, then that agent is not acting on anyone's behalf.

This difference changes the shape of the review. Reviewing a service account gets by on checking whether its permissions are too broad. Reviewing an agent has to add a second question: is it still acting for anyone. If an agent is no longer acting on behalf of anyone, its permissions may remain valid but become unnecessary.

2.4 The Same Distinction Exists in the Specification

Everything so far has been an observation of operations. The same distinction, however, is defined explicitly on the specification side. RFC 8693, a Standards Track document defining token exchange for OAuth 2.0, was published in January 2020. This document divides the scenarios in which one entity acts on behalf of another into two categories.

The first is impersonation.

When principal A impersonates principal B, A is given all the rights that B has within
some defined rights context and is indistinguishable from B in that context.

The second is delegation.

With delegation semantics, principal A still has its own identity separate from B, and
it is explicitly understood that while B may have delegated some of its rights to A,
any actions taken are being taken by A representing B. In a sense, A is an agent for B.

The last sentence is the one to notice. This RFC, published in 2020, refers to entities operating in a delegation capacity as "agents." The subject this article treats had already been given a name on the specification side, before large language models became practical.

These two definitions directly correspond to the observations made in Section 2.3. An operation that treats an agent as a service account has taken the shape of impersonation. The party that executes cannot be told apart from the delegator. Conversely, treating an entity as an agent must adhere to the delegation model, where the executing entity maintains its own identity while acting on behalf of another.

What the third-class claim amounts to is holding both of these at once. A human identity holds only itself. A service account holds only itself. An agent holds its own identity and the identity of the party it acts for. A subject that holds both at once fits neither of the existing operational shapes.

2.5 Placing the Three Side by Side Shows the Operational Difference

When translating claims into operational terms, the following table emerges:

Question	Human identity	Workload identity	Agent identity
What triggers retirement	A change in employment status	The workload is shut down	Nothing. You have to build one
Who can be asked whether it is needed	The person	The operating team	No one is defined
Whose permissions does it act with	Their own	Its own	The delegator's. It changes with the caller
What unused means	The person has not signed in	No calls are arriving	No delegator is left. It can become unnecessary while still running
What the audit record has to hold	Who did what	What did what	On whose behalf what did what

How access review differs across the three kinds of principal

Only the entries in the rightmost column cannot be derived from either of the existing operational processes. The four stages of this article exist to fill that column in.

2.6 The Distinction Does Not Always Apply

Not every agent lands in the third class. There are agents that do not act on behalf of anyone. Processes that start on schedule and complete using only their own permissions count as service accounts in the operation of identity, even though they function as agents.

The dividing line is not autonomy and not the presence of a model. It is whether a delegator exists. If there is a delegator, the third-class operation is what it needs. If there is none, the existing workload identity operation is enough, and AWS IAM Inbound Workload Federation covers that design.

Writing this distinction on the first line of the ledger makes the three stages that follow much easier.

3. Registration — Who Approves, and Where the Approval Is Recorded

3.1 What Registration Has to Decide

Registration is not the act of issuing an identity to an agent. Issuing one takes a single API call. What registration decides is the information the three stages after it refer back to.

What it decides	Why it matters later
Owner	This becomes the party to ask at review time, and the party that decides on retirement
The range it may act for	This becomes the upper bound on the scope at delegated authorization
The delegators it expects	This becomes the starting point for detecting that the delegators are gone
The review deadline	This sets the review cycle. A registration with no deadline drops out of the review

None of the four can be reconstructed afterward. Looking at a running agent will not tell you who owns it.

3.2 A Place to Record Approvals That Exists on AWS

A mechanism for leaving a record of approval does exist on the AWS side. It is AWS Agent Registry, offered through Amazon Bedrock AgentCore. As of August 21, 2026, it is in preview. AWS describes it as a privately controlled catalog and discovery layer for agents, tools, skills, MCP servers, and custom resources within an organization. Currently, availability is limited to five AWS Regions. The August 2026 AgentCore release notes state that the same registry is available in nine Regions, which does not agree with the Supported AWS Regions page.

The registry has moved to a different namespace. On August 6, 2026, AWS moved it out of the bedrock-agentcore namespace into a dedicated agent-registry namespace. The migration guide states that the old namespace shuts down on September 17, 2026, and that anyone without an existing registry or record as of August 6, 2026 cannot reach the service through the old namespace. Endpoints, the IAM action prefix, resource ARNs, SDK clients, and the CLI namespace all change, and the API schema carries changes that break backward compatibility. The API references this article cites for the registry are the ones in the new namespace.

Only the registry moves. The same guide states that workload identity and OAuth credential provider resources stay in the bedrock-agentcore namespace. Of the three places of registration in Section 3.4, the second and the third are not affected by this move.

This registry incorporates an approval workflow. According to the API reference, a record's status can take on one of nine possible values.

DRAFT | PENDING_APPROVAL | APPROVED | REJECTED | DEPRECATED | CREATING | UPDATING | CREATE_FAILED | UPDATE_FAILED

There are two operations to advance the status. SubmitRegistryRecordForApproval moves a record from DRAFT to PENDING_APPROVAL. UpdateRegistryRecordStatus approves, rejects, or deprecates a record.

The second of those carries a property you cannot overlook, seen as a record of approval. It requires the statusReason parameter, which can contain up to 255 characters. The API reference explains that this field should provide the reason for the status change, such as why a record was approved or rejected. It is not possible to approve a record without providing a reason.

AWS CloudTrail logs access to the registry and the administrative operations on it, so who approved what and when can be pulled from there.

3.3 Auto-Approval Leaves No Approver Behind

The SubmitRegistryRecordForApproval API documentation includes the following statement:

Depending on the registry's approval configuration, the record is either auto-approved
or set to PENDING_APPROVAL for a curator to approve or reject.

Auto-approval makes the operation lighter. It also creates a state in which the approval stage has formally been passed and no human made a judgment. To an auditor, a record that was approved and a record that arrived at approved without an approval look identical on the record itself.

AWS does not say what statusReason holds when auto-approval fires. Because AWS does not say it, this article does not say it either. What it can say is that anyone reading an approval record has to check, alongside it, whether the registry has auto-approval enabled.

3.4 Registration Happens in Three Places

This is easy to get wrong. Within AWS, the registration that concerns an agent happens in three independent places.

The first is the catalog. A record in AWS Agent Registry is metadata about a resource. The CreateRegistryRecord API documentation states that these records describe a discoverable resource such as an MCP server, an agent, an agent skill, or a custom resource, and it defines four values for the required recordType.

MCP | AGENT | CUSTOM | SKILL

Note that the workload identity is not included in this list.

The second is that workload identity. The resource an agent uses as its own identity sits on the AgentCore Identity side. It is created using CreateWorkloadIdentity, read with GetWorkloadIdentity, and deleted with DeleteWorkloadIdentity.

The third is the credential provider. This is the configuration that lets an agent reach an external service, and CreateOauth2CredentialProvider and CreateApiKeyCredentialProvider create it. The AgentCore developer guide describes this resource as an intermediary that manages the relationship between the agent, the identity provider, and the resource server, and notes that it is deeply integrated with the token vault.

There is no mechanism within AWS to correlate these three elements. Even if you deprecate a catalog record, the workload identity will remain. Even if you delete the workload identity, the credential providers will remain.

The correlation has to be held on the operations side. What the ledger in Chapter 9 carries is exactly this joining of the three.

3.5 When Registration Is Complete

Registration can be called complete when these four are in place.

The ledger names a team as the owner, not a person.
The reason for approval is left in readable form.
One line of the ledger joins the three items in Section 3.4.
A review deadline is in the row.

Naming a team rather than a person is what stops the first of the losses in Section 1.2. Register under an individual's name and the owner goes unknown the moment that person moves.

4. Delegated Authorization — Recording the Chain and Deciding the Scope

4.1 The Triple That Has to Be Recorded

When an agent makes a downstream call, that call must contain three pieces of information: which agent is making the call, who the agent is acting on behalf of, and the scope of the call.

Drop any one of them and the stages that follow do not hold. If the agent is missing, there is no telling which agent to stop. If the delegator is missing, there is no way to pull the blast radius when that delegator leaves the company. If the scope is missing, there will be no basis for limiting permissions.

Section 5.2 of Agent Interoperability Architecture on AWS holds the machinery that carries this triple across hops, treating token exchange as the mechanism that moves an identity from hop to hop without asking for consent again. This article will not re-explain that mechanism. What this article takes up is how the triple that gets carried is recorded, and how a review can use it.

4.2 The Specification Defines How to Express the Chain

RFC 8693 §4.1 defines how to express a chain of delegation inside a JWT. The act claim is what does it.

The "act" (actor) claim provides a means within a JWT to express that delegation has
occurred and identify the acting party to whom authority has been delegated.

The chain is expressed by nesting. The same section states it as follows.

A chain of delegation can be expressed by nesting one "act" claim within another. The
outermost "act" claim represents the current actor while nested "act" claims represent
prior actors.

The nesting direction is the opposite of what might be intuitive. The same section explicitly states this.

The least recent actor is the most deeply nested.

The example provided in the specification is as follows:

{
  "aud":"https://service26.example.com",
  "iss":"https://issuer.example.com",
  "exp":1443904100,
  "nbf":1443904000,
  "sub":"user@example.com",
  "act": {
    "sub":"https://service16.example.com",
    "act": {
      "sub":"https://service77.example.com"
    }
  }
}

This structure reveals two key aspects. First, the sub claim remains the original principal throughout the entire chain. Regardless of how many levels of delegation occur, the original identity does not change. Second, tracing the act claim from the outside inward walks back from the current actor to the previous ones.

4.3 The Chain Is an Audit Record, Not an Authorization Input

The nesting must not be used to make an authorization decision. The same RFC states this with a requirement keyword.

For the purpose of applying access control policy, the consumer of a token MUST only
consider the token's top-level claims and the party identified as the current actor by
the "act" claim. Prior actors identified by any nested "act" claims are informational
only and are not to be considered in access control decisions.

What authorization may use is the token's top-level claims and the current actor, and nothing else. A prior actor is information only.

This section also explains the purpose of nested chains.

The nested "act" claims serve as a history trail that connects the initial request and
subject through the various delegation steps undertaken before reaching the current
actor.

A history trail, then, is the position it holds. Among the four stages of this article, the nesting matters at access review and at retirement, not at delegated authorization. At delegated authorization, only the current actor and the sub claim should be considered.

Failing to distinguish between these two uses can lead to implementation errors. Authorizing based on past actors violates the specification's MUST requirements. Fail to keep the nesting and what a review would have traced is gone. The correct approach is to store them but not use them for authorization.

4.4 Who May Act on Behalf Is Expressed by a Different Claim

Section 3.1 said that registration decides the range an agent may act for. The same RFC also defines how to express that decision inside a token. This is the may_act claim.

The "may_act" claim makes a statement that one party is authorized to become the actor
and act on behalf of another party.

The difference between act and may_act lies in the tense. act states who acted on behalf of someone, and may_act states who is allowed to act on behalf of someone. The former represents a record of a past action, while the latter represents prior authorization.

The same section gives an example of its use: an authorization server can read the may_act claim in a token presented on a token exchange request, and decide from it whether the other party is eligible to engage in the delegation or impersonation being requested.

This mechanism connects back to the registration process. If the registration process defines who is permitted to delegate to this agent, and that decision is represented as a may_act claim, the authorization server can make that determination. Whether to take this route, though, is decided by the authorization server's implementation. The specification only defines the format of the representation; it does not mandate its use.

4.5 Where the Chain Is Recorded and Where It Is Not

Riding in a token and being readable later are two different things. A token is short-lived and expires. A review happens months afterward. To read the chain later, a copy has to sit somewhere other than the token.

Where the copy lives depends on the operation. CloudTrail keeps the calls that close inside AWS. When an agent calls an external service, nothing stays on the AWS side. The implementation decides whether the chain on that outbound path gets recorded at all. If it has not been explicitly configured, it will not be recorded.

This record matters most at the retirement stage. As Chapter 6 shows, without the record of the chain there is no way to pull what has to be stopped when a delegator leaves the company.

4.6 Treating the Scope as the Intersection of Two Permissions

From here on, this is a design decision of this article. No specification defines it this way.

The judgment reads as follows. An agent should exercise downstream only what falls inside both what the agent is allowed and what the delegator is allowed.

The two bands at the top of the diagram stand for what the agent is allowed and what the delegator is allowed. They overlap partway along the horizontal. The three boxes underneath are that overlap and the two ranges that sit outside it. The middle is the only range that should be exercised. Look at one band alone and the range beside it opens.

Look only at the agent side and the agent can exercise permissions the delegator never had. The delegator gets the agent to do what the delegator cannot. This is not acting on behalf of someone. It is privilege escalation.

Look only at the delegator side and the reach extends to what you never meant to give the agent. The breadth of the delegator's permissions overwrites the scope you narrowed when you designed the agent.

Why does no specification define this? An authorization protocol defines how a token travels, not which scope belongs on it. Whether to take the intersection is left to the design of the side that performs the authorization.

4.7 The Implementation Holds the Delegator Side. It Does Not Hold the Agent Side

Consider, for example, the AgentCore Identity credential provider. The handling differs significantly between the two sides.

The implementation holds the delegator side. The AWS developer guide states the following.

A successful call to a credential provider does not mean credentials are automatically
returned. The credentials a workload retrieves are scoped to the user identity in its
workload access token. For OAuth2 (3LO) providers, the end user must have completed
authorization before any credentials exist to retrieve for that workload identity and
user combination.

The credentials that can be retrieved exist for a specific combination of workload identity and user. If the user has not completed authorization, there are no credentials to retrieve in the first place. The implementation carries the delegator-side narrowing in this shape.

The agent side is different. A note on the same page makes this explicit.

The IAM role you assign to an agent controls which credential providers the agent can
call. The service does not enforce additional binding between workload identities and
credential providers in the same account.

Inside one account, nothing the service enforces ties a workload identity to a credential provider. What decides which providers an agent can call is the IAM role you gave it, and nothing else.

The same page also provides an example of how to adhere to the principle of least privilege. It lists the ARN of the workload identity and of the credential provider explicitly in the Resource block, and avoids *.

One side of the intersection, then, does not exist unless you write it. An agent whose IAM policy leaves Resource unnarrowed can call every credential provider in that account. Credentials still come back empty unless the user has authorized, but that is the delegator-side narrowing doing its work. The agent side is open.

4.8 Where the Intersection Is Actually Taken

The place to take the intersection is the side that guards the downstream resource, not the agent side. Narrowing inside the agent itself is self-declaration, and it does not hold if the agent is compromised.

On AWS, that place is the IAM policy from the previous section and, on top of it, the Cedar policy attached to the AgentCore Gateway. Amazon Bedrock AgentCore Policy Implementation Guide holds the syntax and the design of those policies, so this article does not cover how to write them. What a review has to look at is whether that policy references both permissions. A policy that conditions only on the agent identity is not taking the intersection.

5. Access Review — What Differs from Reviewing People

5.1 What Reviewing People Assumes

An access review of people runs in the following shape. Produce a list of the subjects. Look at the last-used time of each one. Make the unused ones candidates. Confirm with the owner. Delete the ones that are not needed.

Of these five steps, only the first one holds for an agent.

5.2 The List Can Be Produced

It is possible to obtain a list of AgentCore Identity workload identities. ListWorkloadIdentities does this, and the API reference says it returns every workload identity in the account. The maximum number of entries per page is 20.

The returned data includes only two items:

name | workloadIdentityArn

The last used time is not returned. Calling GetWorkloadIdentity one identity at a time adds three fields and no more: allowedResourceOauth2ReturnUrls, createdTime, and lastUpdatedTime. lastUpdatedTime is when the configuration changed, not when the agent last ran.

So the second step does not hold. The list can be produced, but nothing in it tells you which ones are unused.

5.3 What the IAM Mechanisms Can Answer

IAM provides two mechanisms for reviewing resources. AWS IAM Access Analyzer Deep Dive holds how to use both, so this article writes no procedure. What this section looks at is what they can answer about an agent.

The first is the unused access analyzer. The IAM user guide describes the detected information as follows:

The findings highlight unused roles, unused access keys for IAM users, and unused
passwords for IAM users. For active IAM roles and users, the findings provide
visibility into unused services and actions.

The second is last accessed information. The same user guide describes the scope as follows:

As an administrator, you might grant permissions to IAM resources (roles, users, user
groups, or policies) beyond what they require.

Both rest on the same premise: the subject has to be an IAM principal. The unused access analyzer generates its findings for the IAM entities inside the account or the organization you select.

If an agent is accessing AWS resources via an IAM role, both mechanisms will provide information about that role. Neither answers for the part that does not go through a role. Of the three places in Section 3.4, these two mechanisms answer only for the IAM role attached to the workload identity. The catalog record and the credential provider are out of their reach.

5.4 What the IAM Mechanisms Do Not Answer

Four areas go unanswered. The user guide is explicit about all of them.

First, it concerns the actions of data plane operations.

Action last accessed information is not available for any data plane event.

This limitation applies to information about actions, but not to information about services. Getting the two mixed up does real damage, so they are separated here.

The user guide names two types of last accessed information you can view for an IAM identity, allowed AWS service information and allowed action information. For action information it says the data covers service management actions accessed by IAM identities, and then places the sentence quoted above. On what a management event is, it says these are the service management events that CloudTrail logs, sometimes called control plane operations.

Type	What it answers about a data plane call
Service information	That an attempt was made against that service
Action information	Not which action it was

Most of what an agent does is on the data plane. Invoking a model. Reading an object. Writing an item. A management plane operation is close to an exception in an agent's work.

So what a review can do splits in two. Removing a permission on the grounds that a service has never been used holds. Service information carries that judgment. Removing a permission on the grounds that an action has never been used does not hold. Data plane actions never appear in action information, so not having used one is indistinguishable from having no record of it.

Second, it concerns permissions granted through a session policy. The user guide lists the policy types that last accessed information does not include, and session policies are among them. The same list drops resource-based policies, access control lists, AWS Organizations SCPs, and permissions boundaries. Narrowing an agent's permissions with a session policy on every invocation is a recommended design, and what that narrowing achieves is invisible from the review side.

Third, it concerns the iam:PassRole action. The user guide states plainly that this action is not tracked and is not included in IAM action last accessed information.

Fourth, it concerns attempts that were never authenticated. The user guide says last accessed information does not include unauthenticated attempts. Authenticated attempts, on the other hand, include the ones that were denied. The same section adds that service last accessed data covers every attempt against an AWS API, not only the successful ones, and that the CloudTrail logs are the authoritative source on all API calls and whether each one succeeded or was denied.

There is also a range in the timing of when tracking began. According to the same section, the period for which service information is tracked is a minimum of 400 days, depending on when the service began tracking information about specific actions. Tracking of information for Amazon S3 began on April 12, 2020; for Amazon EC2, IAM, and Lambda, it began on April 7, 2021; and for all other services, it began on May 23, 2023.

5.5 So what do you look at?

The answer is not straightforward. An access review of an agent falls back on reading CloudTrail rather than on a mechanism built for it. The fourth point in the previous section provides the rationale for this, drawing from primary source data.

Here is a breakdown of what to look for:

What to look at	Where to pull it from	What it tells you
Whether the agent ran	CloudTrail	The nearest thing to a last-used time
On whose behalf it ran	The record of the chain	Whether the delegator is still with the company
What it used	CloudTrail and last accessed on the role	Whether the scope can be narrowed
Whether it is still needed	Asking the owner named in the ledger	The retirement decision

The second row exists for neither reviewing people nor reviewing workloads. The questions specific to an agent concentrate here. An agent whose delegators are all gone has appropriate permissions, is running, and is unnecessary all the same.

5.6 What a Single Review Actually Reads

Put into concrete steps, one agent is read in this order.

Open a record in the ledger and verify the owning team and review deadline.
Compare the results of ListWorkloadIdentities with the ledger to check for any workload identities that are not listed in the ledger.
Using CloudTrail, retrieve the most recent activity associated with that workload identity, focusing on the roles.
From the record of the chain, list the users delegated to most recently and confirm that they are still with the company.
Read last accessed on the role to see whether any service is unused.
Confirm the necessity with the owning team.

Skip step two and an agent the ledger never listed never enters a review at all. The operations side writes the ledger, so something always goes unwritten. So run the comparison from the list side.

What step five lets you drop is a service that has never been used. It cannot decide anything about an individual action. As the first item in Section 5.4 shows, a data plane action never reaches action information. To drop at the granularity of an action, back it with CloudTrail.

Section 9.3 takes up the cycle.

6. Retirement — What You Delete, and What Remains

6.1 Building the Trigger

A human identity has a trigger. An agent has none. So you build one.

There are three triggers that can be established.

The first is a deadline. Set a review deadline at the time of registration. When it arrives, ask the owner. If no confirmation comes back, move to retirement. Leave the deadline out and this trigger is never pulled.

The second is the absence of a delegator. If every user the agent acted for is gone, there is no one left to act for. With the record of the chain from Section 4.5 in place, this trigger can be pulled mechanically.

The third is the absence of an owner. This is the case where the owning team disbanded, or where no one can trace the owner any more. This trigger carries the greatest weight. An agent with no owner also has no one to make the retirement decision.

6.2 An Emergency Stop Is Not a Retirement

Before the procedure that follows a pulled trigger, two things have to be kept apart. Stopping it now and retiring it are separate operations.

An emergency stop is performed when an agent is exhibiting unexpected behavior. Speed is the priority, and data consistency can be addressed later. Chapter 7 of AWS IAM Inbound Workload Federation holds the move that invalidates every session already issued for a role. The granularity is the role, so every other agent using the same role stops with it.

Retirement is what you do when an agent is no longer needed. The consistency of the records comes first, and speed is not required. Write the two into one runbook and the emergency turns slow, because someone reaches for the retirement procedure instead of stopping the thing.

The practical reason for keeping them apart is that the retirement procedure does not run after an emergency stop. Once it is stopped the crisis is over, so the work ends there. An agent that is merely stopped stays on the books as an agent that was never deleted. After an emergency stop, raise the retirement procedure as a separate item.

6.3 What to Do When a Delegator Leaves

The second trigger, as outlined in Section 6.1, has two stages. It is important to distinguish between a delegator leaving and all delegators leaving.

When one delegator leaves, what retires is not the agent. It is that one delegation. Concretely, delete the credentials held for that user. Revoke the consent that user gave on the third-party service. The agent itself keeps acting for its other users.

In most organizations this operation is nowhere in the offboarding procedure for people. Offboarding is built out as far as disabling the corporate directory account and reclaiming SaaS licenses. The delegation that person gave to an agent appears nowhere in it.

When all of them are gone, the agent moves to retirement, and the procedure from Section 6.4 onward starts there.

In both cases the starting point is the record of the chain. Without the record in Section 4.5, there is no pulling which agents the departing user had delegated to. When it cannot be pulled, that delegation stays forever.

6.4 What You Delete

List the items to be deleted as part of the retirement process. The order is significant.

Authorization downstream — the Gateway policy, and the client you registered with the external service
The credential provider — DeleteOauth2CredentialProvider and DeleteApiKeyCredentialProvider
IAM permissions — the permissions policy on the role, and the role's trust policy
The workload identity — DeleteWorkloadIdentity
The execution infrastructure — the runtime, the Gateway target, the browser and code interpreter resources
The catalog record — DEPRECATED through UpdateRegistryRecordStatus, or gone through DeleteRegistryRecord

Delete the reach first and the identity after. Items 1 through 3 are the reach, item 4 is the identity, item 5 is the execution infrastructure, and item 6 is the record. Delete the identity first and you are left with authorization whose subject nobody can read. At the next review they stay on as items whose purpose is unknown and whose safety to delete cannot be judged.

The catalog record comes last because the catalog doubles as the record of the work. Clear it first and, if the work stalls halfway, nothing is left to tell you what has already gone.

6.5 What Remains After You Delete

This is the center of the article. Even after all six above are gone, the following remain.

6.5.1 Tokens Already Issued

A credential already issued runs until it expires. Delete the identity and a token that is already out at that moment does not turn invalid. The moment retirement completes is not the moment the delete operation ran. It is the expiration of the last token that was issued.

Similar delays can occur in other pathways. Chapter 7 of AWS IAM Inbound Workload Federation covers what is left behind when a certificate is revoked on the IAM Roles Anywhere path.

6.5.2 Consent Left on the Third-Party Service

The AgentCore Identity token vault holds the token a tool issued, and it holds it from the moment the user consents. According to AWS's FAQ:

For OAuth 2.0 compatible tools and services, when a user first grants consent for an
agent to act on their behalf, AgentCore Identity collects and stores the user's tokens
issued by the tool in its vault, along with securely storing the agent's OAuth client
credentials.

Delete the vault side and the copy it holds goes with it. What does not go is the consent the user gave on the third-party service itself. That consent lives in the account settings of that service. An AWS delete operation does not reach it.

AWS says nothing about this. Because it says nothing, this article does not state what happens either. What can be said is that unless the retirement procedure includes revoking consent on the third-party service, that consent stays.

6.5.3 Secrets Stored in AWS Secrets Manager

A credential provider can hold its secret in either of two ways. The AgentCore developer guide shows the form that passes a reference to a client secret already sitting in AWS Secrets Manager: set clientSecretSource to EXTERNAL and write the secret's ARN into secretId. The API key credential provider has the same form.

Choose that form and the secret is a separate resource on the Secrets Manager side. The credential provider's ARN and the secret's ARN are different things, and AWS does not state whether deleting one reaches the other.

So the retirement procedure needs a step that checks which form was used. The responsibility for deleting the secret rests with the party that initially provided it.

6.5.4 Deprecation Is Not Deletion

The UpdateRegistryRecordStatus state values include DEPRECATED. The API reference describes this operation as one that allows you to approve, reject, or deprecate records.

Deprecating is a change of state, not a deletion. The record stays. A separate operation, DeleteRegistryRecord, does the deleting. Which one you pick is a judgment: deprecate to keep it as an audit record, delete to make it gone. If you do not document your choice in the ledger, the next reviewer who sees a deprecated record cannot tell whether it is retired or still mid-way.

6.5.5 Registration with the Signature Directory

Amazon Bedrock AgentCore Browser provides the mechanism that lets an agent present a cryptographic identity as it browses the web, under the name Web Bot Auth, which is currently in preview as of August 21, 2026. AWS states that turning the feature on registers that agent's signature directory automatically with the providers that do the verifying.

AWS does not say what becomes of that registration when the browser resource is deleted. So this article says neither that it goes nor that it stays. What it can say is that the registration sits outside the AWS account, which means the retirement procedure does not close inside AWS. Section 7.4 has the detail.

6.5.6 What the Agent Left Behind

Whatever an agent made while it was running outlives the agent's retirement. This includes data written to memory, resources created, messages sent, and records updated.

These are supposed to remain. Do not delete them. What does need deciding is who owns them once the agent is retired. Leave that undecided and ownerless resources pile up.

6.5.7 Audit Logs

The CloudTrail record stays. That is also correct. It is the only record that can prove retirement completed.

6.6 When Retirement Can Be Called Complete

The following five conditions must be met:

All six in Section 6.4 are gone.
The last credential issued has passed its expiry.
For consent on the third-party service, there is a record of whether it was revoked or deliberately left in place.
For a secret you brought in yourself, there is a record of whether it was deleted or kept because it is used elsewhere.
Someone owns whatever the agent left behind.

The most common operation declares completion without waiting for the second one. Record completion at the moment the delete succeeds and there is still a window in which the thing can act.

6.7 Retirement Is Terminal

The reason Section 1.3 gave for not drawing a cycle in the diagram becomes concrete here.

If a retired agent is wanted again, start over from registration. You do not put back what you deleted. There are three reasons for this. The owner has changed. The delegator has changed. And the reason for approval has gone stale.

Restore instead, and an agent comes back alive having never once passed through the approval stage. This is the same state as described in Section 3.3 regarding automatic approval. On the surface it reads as approved, and no human ever made the judgment.

7. Where the Standards Are Right Now

7.1 Treating Drafts as Drafts

Most of what this chapter covers is still on its way through standardization. Being on the way is not a defect. The defect appears when something on the way gets built into a design as if it had arrived.

Therefore, throughout this chapter, it is essential to clearly document the version and status of each document. An Internet-Draft carries an expiry date, and it expires once that date passes. An expired draft is sometimes replaced by another draft. This article reflects the state of these documents as of August 21, 2026.

7.2 Decentralized Identifiers

Decentralized Identifiers (DIDs) are a specification for identifiers that do not require a central registration authority. According to the W3C definition:

A globally unique persistent identifier that does not require a centralized
registration authority and is often generated and/or registered cryptographically.

It is essential to specify the version when referencing this specification, otherwise, the intended meaning may not be clear. This is because two different versions of the document currently exist. https://www.w3.org/TR/did/ refers to Decentralized Identifiers (DIDs) v1.0, the W3C Recommendation published on July 19, 2022. In contrast, https://www.w3.org/TR/did-1.1/ refers to v1.1, a Candidate Recommendation Snapshot published on March 5, 2026.

The Status of This Document for v1.1 states:

The W3C Decentralized Identifier Working Group has published this document as a W3C
Candidate Recommendation and is requesting that software developers and DID Method
specification authors provide experimental implementations designed to test the
implementability of all of the features in this document.

Version 1.1 is at the stage of asking for implementations, not at the stage of a settled Recommendation. If a design puts decentralized identifiers on an agent identity, it has to decide which of the two versions it implements against.

7.3 An Identity and Delegation Layer for Agents

A proposal to lay an identity and delegation layer on top of the Model Context Protocol has been contributed to a standards body. The recipient is the Decentralized Identity Foundation.

The DIF's official blog, dated March 5, 2026, mentions both the donation and the name change.

Vouched is formally donating KYA-OS to the Decentralized Identity Foundation (DIF),
an organization dedicated to decentralized identity-related specifications and
open-source code development.

The name has changed. The same article explains the reasons for the name change.

Note: this was originally published with the name that had been used by Vouched, which
was MCP-I. As we discussed this in DIF, we have renamed the specification to KYA-OS as
a more widely applicable Agentic Identity Solution which can be used for MCP as well as
other Agentic AI frameworks.

Searching under the name MCP-I will not reach the current work. The same article also describes the organizational structure after the name change.

At DIF, the KYA-OS specifications will be further developed as a community-driven open
standard under the Trusted AI Agents Working Group, through a dedicated KYA-OS task
force.

The work is at the stage of a dedicated task force inside a working group. It is not at a stage where a design can build on it. Holding it as a position on the map is the appropriate treatment.

7.4 A Cryptographic Identity for Bots

When an agent browses the web, Web Bot Auth is the mechanism that shows cryptographically what it is. AWS describes this as a draft IETF protocol, and its description aligns with the status on the IETF side.

However, the document's structure is subject to change. As of August 21, 2026, the current draft is draft-meunier-webbotauth-httpsig-protocol, titled "HTTP Message Signatures for automated traffic." Version 02 was submitted on August 18, 2026, and expires on February 19, 2027.

It is important to read the document's positioning carefully. As the identifier does not begin with draft-ietf-, this is not a working group document but rather an individual submission. On the datatracker, neither an RFC stream nor the intended RFC status has been assigned. However, the beginning of the draft's main body declares its intended status as "Standards Track." This is a statement of the author's intent and does not mean that the IETF has made that determination.

This draft replaces two previous documents: draft-meunier-web-bot-auth-architecture and draft-meunier-webbotauth-httpsig-directory. Both of these are no longer valid on the datatracker.

This Internet-Draft is no longer active.

The document that goes by the name Web Bot Auth is that expired architecture draft. Follow the name and you arrive at a document that is no longer active.

The signing itself is not a draft. By AWS's account, the signing follows RFC 9421, HTTP Message Signatures. That part is a settled standard.

AWS has implemented this in two directions. AWS WAF handles the verifying side, and picked up support on November 21, 2025. AWS History and Timeline regarding AWS WAF holds that date. AgentCore Browser handles the signing side, and that one is in preview.

7.5 A Compliant Server Can Still Be Unprotected

The Model Context Protocol specification governs authorization on the path an agent takes to call a tool. The way it is written carries an operational consequence.

The current version of the specification is 2026-07-28. On the Authorization page of that version, the Protocol Requirements section says the following.

Authorization is **OPTIONAL** for MCP implementations. When supported:

* Implementations using an HTTP-based transport **SHOULD** conform to this specification.
* Implementations using an STDIO transport **SHOULD NOT** follow this specification, and
  instead retrieve credentials from the environment.
* Implementations using alternative transports **MUST** follow established security best
  practices for their protocol.

Read the requirement keywords in order. Authorization itself is OPTIONAL. That an implementation on an HTTP transport conforms to this specification is SHOULD, not MUST.

So an HTTP server that implements no authorization at all violates none of the specification's MUST requirements. It is possible for a server claiming compliance to lack authorization.

Further down the same page, the specification lines up the requirements that apply once authorization is implemented, and it states them in strong keywords. An authorization server MUST implement OAuth 2.1. An MCP server MUST implement OAuth 2.0 Protected Resource Metadata as defined in RFC 9728. An access token MUST be validated as having been issued for that server as the intended audience.

The strong keywords line up only after authorization has been implemented. Whether to implement it at all stays OPTIONAL.

The operational consequence narrows to one thing. For a server an agent calls, knowing that it conforms to the specification does not settle whether authorization happens. Separate from the claim of conformance, a step is needed to confirm that the server implements authorization.

This article does not detail the methods for performing such verification. It only highlights the necessity of verifying authorization.

7.6 Where Each One Fits in the Cycle

The following sorts out where each one could fit among the four stages.

Mechanism	Which stage	Where it stands
Decentralized identifiers	Registration	v1.0 is a Recommendation, v1.1 a Candidate Recommendation
KYA-OS	Registration and delegated authorization	Work in progress in a DIF working group
Web Bot Auth	Delegated authorization	An individual submission draft; the signing part is an RFC
The `act` and `may_act` claims	Delegated authorization and access review	Settled as RFC 8693

The last row is the only settled one. That is why Chapter 4 puts the RFC 8693 claims at its center. The other three are positions to know about, not things to build into a design today.

8. Where the Primary Sources Disagree with Each Other

Reading the primary sources against each other turned up four places where they disagree. Each one can only be resolved on the reader's side, so they are recorded here as they stand.

8.1 One Page References Two Versions of the Same Draft

The Authorization page, dated MCP 2026-07-28, references the OAuth 2.1 draft. The Standards Compliance section states:

OAuth 2.1 IETF DRAFT (draft-ietf-oauth-v2-1-13)

Every other reference on the page points to that same version 13. This includes the Roles section, the Access Token Usage section, and the Scope Challenge Handling section.

However, there is one exception. The Refresh Tokens section contains a link to version 14. The bullet reads as follows.

MUST keep refresh tokens confidential in transit and storage as specified in
OAuth 2.1 Section 4.3

The link on that OAuth 2.1 Section 4.3 points at draft-ietf-oauth-v2-1-14. It is the only reference to version 14 anywhere on the page.

Currently, the IETF version is version 15. It was submitted on March 2, 2026, and expires on September 3, 2026. OAuth 2.1 has not yet become an RFC. As a document of the OAuth working group, submission to the IESG sits on a December 2026 milestone.

For the reader, this means deciding for yourself which version to follow. Section numbers shift between versions, so following one without knowing which version you are in can land you in a different section.

8.2 The Donor and the Recipient Use Different Names

The rename in Section 7.3 never reached the announcement on the donor's side. Vouched's announcement, dated March 5, 2026, says MCP-I in both the headline and the body.

Vouched Donates MCP-I Identity Framework to the Decentralized Identity Foundation to
Advance Trust and Security for AI Agents

The DIF blog carries the same date, uses KYA-OS, and states the rename outright. Two primary sources published on the same day call the same thing by different names.

For the reader, this means that searching under only one of the names will not give the whole picture.

8.3 Two Drafts Have Become One

The AWS WAF FAQ says the following about the specifications Web Bot Auth rests on.

This approach relies on two IETF draft specifications:

The two the FAQ goes on to name are a directory protocol, for bots to publish their public keys, and a signing protocol, defining how a bot attaches a cryptographic identity to an HTTP request.

On the IETF side the two are now one. As Section 7.4 showed, the signing draft replaced the directory draft. The directory content did not disappear. It moved into a single document.

For the reader, this means that looking for the two documents turns up one of them as an expired document.

8.4 The Phrase DID Specification Can Point at Two Documents

As Section 7.2 showed, W3C carries a Recommendation at v1.0 and a Candidate Recommendation at v1.1 at the same time. Both are official, and neither is the old one. v1.0 is a settled Recommendation. v1.1 is a document asking for implementations.

For the reader, this means that the phrase DID specification on its own does not settle whether the subject is a specification that has been finalized or one that is still asking for implementations.

8.5 The General Rule

One thing runs through all four. What is wrong is not the content of the documents but the way they are identified. The version differs. The name differs. The number of documents differs.

So the remedy is one thing as well. When you cite a specification, write down the version, the publication date, and the status with it. Cite it by name alone and you land on the shapes in Section 8.2 and Section 8.3.

9. The Smallest Operation You Can Put in Place Tomorrow

9.1 One Line in the Ledger

The first thing to put in place is a ledger. No dedicated system is needed. A spreadsheet does it, and so does a file in a repository. What matters is not the format but what goes on one line.

The items to include in each line are as follows:

Item	Why it is needed
The name of the agent	What people call it. Needed separately from the ARN
The ARN of the workload identity	The first of the three in Section 3.4
The identifier of the catalog record	The second of the same three
The ARN of the credential provider	The third of the same three. If there are several, all of them
The owning team	Not an individual's name
The type of delegator	Who the agent acts for. If it acts for no one, follow Section 2.6
The approver and the date	If it was auto-approved, write that
How the secret is held	If a secret was brought in, its ARN
The review deadline	A line left blank here drops out of the review
The retirement method	Deprecate the record, or delete it

Of these ten items, only the identifiers of the resources can be retrieved later via the API. Each of the three has its own list API: the workload identity, the catalog record, and the credential provider.

What no API returns is that those three belong to the same agent, along with the remaining items a person decided. The owning team, the delegator type, the approver and the reason, how the secret is held, the review deadline, and the retirement method have to be written at registration time. Otherwise, recovering them later means hunting down whoever handled it.

9.2 Do Not Let One Person Approve Alone

Put approval in one person's hands and no one can explain the approval history once that person moves on. Approve as a team, write the reason, and keep the reason somewhere it can be read later.

When using AWS Agent Registry, the designated location for providing this explanation is the statusReason field. As Section 3.2 showed, it is a required parameter, so there is no forgetting it. The 255-character limit is worth keeping in mind. It is short for holding the full background of a decision, so if the detail lives elsewhere, put a reference to it in the field.

9.3 Set the Review Cycle by How Fast Delegators Turn Over

The number of agents is not what sets the cycle. How fast the delegators turn over is.

The reason sits in the second row of the table in Section 5.5. The most common reason agents become obsolete is when the person they represent leaves. Therefore, a review cycle that is slower than the rate of personnel changes will inevitably leave agents behind.

For organizations where personnel changes occur quarterly, it is most practical to align the review cycle with that same period. Folding the agent review into the same meeting as the review of people is what sticks. If done separately, one process is likely to fall behind.

9.4 Implement All Three Retirement Triggers

Implementing only one trigger is insufficient.

Implement only the deadline and an agent that stopped being needed inside the window sits there until the deadline. Implement only the absent-delegator trigger and agents configured to act for no one fall outside it. Implement only the absent-owner trigger and unnecessary agents that still have an owner stay.

Of the three, the deadline is the lightest to implement. A workable order is to start with the deadline and add the second one once the record of the chain is in place.

9.5 Add One Line to the Offboarding Procedure for People

The most cost-effective approach is to add a single step to an existing process.

Every organization already has a process for handling employee departures: disabling accounts in the internal directory, recovering SaaS licenses, and collecting company-issued devices. Add one line to that list: revoke the delegations that person gave to an agent.

No new meeting and no new machinery are needed. What makes it work is that this procedure is already proven to run reliably. As Section 6.3 showed, handling one departing delegator is a different operation from retiring the agent. Being a different operation, it does not have to wait for the agent review cycle.

The addition has one prerequisite. It has to be possible to pull which agents that person had delegated to. The record of the chain from Section 4.5 is what does the work here. Without it, only the line can be added, and what it tells you to do stays undecided.

9.6 What This Covers, and What It Does Not

What the five above cover is keeping the owner and the reason from being lost as agents multiply. The first two of the three things in Section 1.2 stop here.

What it does not cover is the third one, the material for judging whether an agent is still needed. That falls back on reading CloudTrail. As Section 5.4 showed, the IAM review machinery returns no answer for most of what an agent does.

10. How This Fails in Practice

Five shapes show up in practice. In none of them is a stage missing. The stages are there and are not connected to each other.

10.1 The Catalog Is Deprecated and the Identity Remains

The three places of registration in Section 3.4 are the cause. Set a catalog record to DEPRECATED and the agent stops being discoverable. However, the workload identity remains active. Any paths that are already calling that agent will continue to function.

Joining the three on one line of the ledger prevents this. If they are not linked, no one will notice if only one of them is removed.

10.2 Recording Completion Immediately After Deletion

This is the shape where the second condition in Section 6.6 is missing. The delete operation succeeds. The audit log records the deletion. However, at that point, any tokens that were active will continue to function until their expiration date.

When this occurs during incident response, the reported completion time and the actual time the operation was stopped may differ. If something happens based on the incorrect reported time, the report will be inaccurate.

10.3 Growing Without Narrowing `Resource` in the IAM Policy

This is the shape from Section 4.7. The IAM role assigned to the agent grants permissions without listing the ARN (Amazon Resource Name) of any credential provider. As a result, the agent can access any credential provider within that account.

Initially, when the first agent is created, there is only one provider, so the issue is not immediately apparent. However, as more providers are added, the scope of access for all existing agents silently expands. This expansion is not recorded as a change to any agent's configuration.

10.4 Widening the Delegators Without Taking the Intersection

This is the shape where the design decision in Section 4.6 was never implemented. It only restricts the agent's scope and does not reference the delegator's authority. With this configuration, the range of delegators is expanded to include administrators.

Nothing in the agent's own configuration changed, and its reach widened. Because no record of the change is kept on the agent's side, it can be difficult to trace the root cause later, potentially leading to misidentification of where to look for the issue.

10.5 Facing an Audit with Auto-Approval Still Enabled

This is the shape from Section 3.3. Every record in the registry says APPROVED, and the approval workflow ran to the end. However, no individual has made a determination.

Audits focus on the determination, not simply the status. While showing only the status confirms that something has been approved, it does not reveal who made the approval or what justification they used.

11. What This Design Still Cannot Answer

Running the four stages still leaves questions unanswered. Writing down that they remain is what keeps them from being read as resolved.

11.1 What to Do About What an Agent Creates Itself

A design in which an agent starts another agent is not unusual. In that case, who is taken to have registered the identity of the agent that was started? This can lead to the creation of entities that have not undergone the proper authorization process.

The act claim in Section 4.2 gives a way to record the chain. Being able to record it and being able to bring it under approval are separate things. How an approval made before run time covers a principal born at run time is not something the four stages of this article answer.

11.2 The Boundary Between Having a Delegator and Having None

The second trigger condition outlined in Section 6.1 requires that all designated delegators have been removed. The number of individuals considered "all" can vary depending on how the records are maintained.

Does the system count a user who was designated as a delegator only once as part of that total? If so, the trigger will not be activated as long as that user remains active. If not, a clear justification is needed to define that boundary. Ultimately, each organization must determine this boundary for itself.

11.3 How to Show Positively That Something Is Unused

As Chapter 5 showed, the AWS review mechanisms return no last-used time for an agent. While CloudTrail logs may show activity records, the absence of such records cannot be distinguished from a resource that has simply never been used.

When records are deleted after their retention period expires, and when a resource has never been used, they appear the same. Increasing the retention period expands the scope within which distinctions can be made, but it does not eliminate the range where distinctions are impossible.

11.4 Designing Before the Standards Settle

The three in Chapter 7 are not settled. Waiting for them to settle leaves the agents multiplying right now outside the scope. Building them in early means rebuilding once they settle.

This article does not offer a solution to this choice. All that can be stated is that only the final row in the table in Section 7.6 is currently confirmed. A design that leans on that row survives whatever the unsettled ones do next.

12. Frequently Asked Questions

Should agent identities be treated as service accounts?

It depends on whether there is a delegator. If an agent operates solely with its own permissions, without acting on behalf of anyone else, its identity is a workload identity in operational terms, and the existing mechanisms handle it as it stands. When there is a delegator, different users invoke the same agent and the range it reaches changes with them. That is not something service account operations can express.

Is the third-class claim written in a specification?

No. The claim itself belongs to this article. The distinction it rests on, however, is written in RFC 8693. That RFC defines impersonation as the form in which the acting party becomes indistinguishable from the party being acted for, and delegation as the form in which the acting party keeps its own identity while acting for another. Section 2.4 quotes both.

Is treating the scope as the intersection of two permissions a specification requirement?

No. This is a design decision made for this article. As stated at the beginning of Section 4.6, the authorization protocol defines how tokens are handled, but it does not specify which scope should be included. Whether to take the intersection is left to the design of the side that authorizes.

Does AgentCore bind a workload identity to a credential provider?

No. The AgentCore developer guide explicitly states that the service does not enforce additional associations between workload identities and credential providers within the same account. Only the IAM role assigned to the agent determines which providers it can access. Section 4.7 quotes it.

Can IAM Access Analyzer review agents?

Partially. If the agent reaches AWS through an IAM role, the analyzer produces unused access findings for that role. What it cannot answer for is everything else. It generates unused access findings for IAM entities, so an AgentCore workload identity itself falls outside them.

Why does it matter that data plane operations are invisible?

The vast majority of agent actions occur on the data plane. The IAM user guide explicitly states that action last accessed information is unavailable for data plane events. Model invocations and object reads are both data plane calls, so the part you most want to see, which action was used, is the part that does not appear.

At the granularity of a service, though, it is visible. The restriction falls on the action information. Removing a permission on the grounds that a service has never been used does hold. Section 5.4 carries a table that separates the two types.

Can the workload identity list show which ones are unused?

No. ListWorkloadIdentities only returns the name and ARN. While GetWorkloadIdentity provides the creation time and last updated time, lastUpdatedTime is when the configuration changed, not when the agent last ran.

Does deleting an agent stop it immediately?

No. Existing credentials will continue to function until their expiration date. The time when the agent is fully retired is not the time you performed the deletion; it's the expiration date of the last issued credential. This aligns with the second condition outlined in Section 6.6.

Does deleting on the AWS side revoke consent given to a third-party service?

AWS does not explicitly state this. Therefore, this article does not state whether it will be removed or remain in effect. What is certain is that unless the retirement procedure includes revoking consent on the third-party service, that step never happens.

When a delegator leaves, should the agent be deleted too?

If that person was the last delegator, delete it. If other users still delegate to the agent, what you delete is only that person's delegation. Specifically, this involves deleting the credentials associated with that user and revoking any consent they provided to third-party services. Section 6.3 splits this into two stages.

When you want to stop an agent, should you run the retirement procedure?

No. Emergency stops and retirement are separate procedures. When prioritizing stopping an agent, the focus should be on invalidating existing sessions, and data integrity can be addressed later. As Section 6.2 sets out, raise the retirement procedure as a separate item after stopping it. An agent that has only been stopped stays on the books as an agent that was never deleted.

Can a retired agent be brought back?

Not by putting back what you deleted. Start again from registration. As Section 6.7 sets out, any of three things may have moved since the agent was retired: the owner, the delegator, and the reason for approval. Restoring a previously deleted agent could result in an agent that operates without ever having gone through the approval process.

When can you start using AWS Agent Registry?

As of August 21, 2026, it is in preview. It is available in five AWS Regions. Preview status changes the premises a design can rest on, so confirm the availability state before putting it into a production operation. The old bedrock-agentcore namespace also shuts down on September 17, 2026.

Does an MCP-compliant server implement authorization?

Not necessarily. The Authorization section of MCP 2026-07-28 explicitly states that authorization is OPTIONAL, and that an implementation on an HTTP transport SHOULD conform to the specification. Servers that do not implement authorization can still operate without violating any of the specification's MUST requirements. Section 7.5 quotes the passage.

Where should I read the Web Bot Auth specification?

Read draft-meunier-webbotauth-httpsig-protocol. As of August 21, 2026, version 02 is the one in force, and it expires on February 19, 2027. Searching by name turns up draft-meunier-web-bot-auth-architecture, which is no longer active. The current draft replaced it.

What happened to MCP-I?

It was renamed KYA-OS, and the work continues in a dedicated task force under the Trusted AI Agents Working Group at the Decentralized Identity Foundation. The DIF blog states the rename explicitly, dated March 5, 2026. The donor's own announcement carries the same date and still says MCP-I, so reading only that one leaves the rename invisible.

If there is no capacity for all four stages, where do you start?

The ledger and the deadline. Of the ten items in Section 9.1, only the identifiers for each resource can be retrieved later via the API. Therefore, starting with the currently registered agents will minimize potential losses. If you set a deadline, you can address the remaining three stages when that deadline arrives.

13. Summary

An agent identity is neither a human identity nor a service account identity. It holds its own identity and the identity of the party it acts for at the same time. This is the shape RFC 8693 defines as delegation, and the RFC keeps it separate from impersonation.

Taking that shape as the premise settles the four stages of the operation. Registration decides the owner and the range the agent may act for, and leaves the reason for approval behind. Delegated authorization records which agent uses which scope on whose behalf. Access review examines not only whether permissions are overly broad, but also whether the agent is still acting on behalf of anyone. Retirement deletes the reach first and the identity after.

Of the four stages, retirement is the one that gets the least attention. Vendors write the procedure for adding. No one writes the procedure for removing.

The most frequently overlooked aspect of retirement is the existence of resources that persist even after deletion. Issued credentials remain active until their expiration date. Consent given on a third-party service is out of reach of an AWS delete operation. Imported secrets remain as independent resources within Secrets Manager. Catalog deprecation is not a deletion. The successful completion of a deletion operation does not equate to the completion of retirement.

AWS's review mechanisms provide limited visibility into agent activity. Findings related to unused access target IAM entities. Action last accessed does not cover data plane events. Permissions granted through session policies are out of scope as well. The majority of an agent's operations fall outside the scope of these action-level checks.

Registration happening in three places, with nothing to join them, tells as well. Catalog records, workload identities, and credential providers are independent. Only the ledger can provide this connection.

Standardization is still in motion. For decentralized identifiers a Recommendation and a Candidate Recommendation stand side by side, KYA-OS sits inside a working group after a rename, and the Web Bot Auth drafts are being replaced one by one. What is settled is the act and may_act claims of RFC 8693, which express delegation in a JWT, and nothing else.

What you can put in place tomorrow is the ledger and the review deadline. The API returns the identifier of each resource and nothing more. That those three belong to the same agent, and what a person decided, survive only if registration wrote them down. On top of that, add one line to the offboarding procedure for people. Handling one departing delegator is a different operation from retiring the agent, so it does not wait for the review cycle.

14. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi