An agent called “Finance Assistant” reads an invoice. Who just accessed the record?
The person who typed the request? The application with that cheerful name? The worker running its code? Or the account whose permission opened the door?
All four can appear in the same request. Treating them as interchangeable makes the architecture look wonderfully simple, right up until somebody asks whose access needs removing.
Agent identity architecture needs separate answers for the human initiator, the logical agent principal, the runtime workload and the authority connecting them. This is a proposed design model, not a claim that every platform uses those exact identity types. The important part is making their relationships enforceable.
Four questions that deserve separate answers
The human initiator answers who started the work. In a delegated workflow, that person may also be the subject on whose behalf access occurs. Those roles can coincide, but a click alone does not establish authority over everything the agent can reach.
The agent principal identifies the logical software actor to which policy applies. Think of a deployed invoice reviewer, not its language model, mascot or latest conversation. A stable principal can remain recognisable across releases while configuration and permissions change under separate controls.
The runtime workload is the software currently executing. It might be one isolated process or several replicas of a service. SPIFFE’s workload model explicitly allows multiple running instances. A workload identity can therefore authenticate software without uniquely identifying one conversational run.
Delegation is the relationship that permits an actor to do something for another party. It needs a scope and an enforcement mechanism. It is not a fourth person wearing a different lanyard.
A run identifier belongs alongside these concepts, but it does a different job. It correlates an execution. Knowing which run made a request does not establish that the run was entitled to make it.
A fictional invoice request
Mariam works in the fictional Cedar organisation. She asks an invoice-review agent to explain a discrepancy on invoice INV-204. The agent may read that invoice and prepare a draft. It may not change supplier bank details.
The request enters through an application that authenticates Mariam and establishes her Cedar membership from trusted account data. The application resolves the chosen agent to its registered principal. It creates a bounded work assignment referencing the permitted invoice and a current grant.
A worker receives the assignment. Before providing a tool credential, the broker authenticates the worker and checks whether that workload is allowed to execute this agent in this environment. It also checks whether the assignment and grant belong together. The invoice service still enforces access to INV-204 under Cedar’s boundary.
That is a proposed implementation, not behaviour supplied by the phrase “agent identity”. The broker, assignment service and resource API must actually perform their respective checks.
Now change one field. A model-generated tool argument requests invoice INV-990 from a different tenant. Mariam is still authenticated. The workload certificate is still valid. The agent principal still exists. The request should nevertheless fail because its target lies outside the trusted assignment and resource authorisation.
The lesson is quite dull, which is useful in security: several true identity statements can accompany a forbidden action.
Draw the relationships, not just the boxes
Suppose the invoice agent scales from one worker to three. It does not necessarily need three unrelated business identities. Its runtime instances can share an appropriately scoped workload identity while individual execution references distinguish their activity.
Now suppose the same worker service hosts an invoice reviewer and a supplier-management agent. The first reads invoices; the second can propose supplier changes. A certificate identifying that shared service does not, by itself, distinguish the two application principals.
The broker needs a trustworthy way to bind an assignment to the intended principal. If any code in the shared worker can assert either principal and obtain its credentials, the apparent separation exists only in a diagram. The runtime has effectively inherited the combined authority available through the broker.
Possible responses include stronger process isolation, separate workload identities, or a broker that accepts assignments only through a trusted execution path with constrained credentials. These choices move cost and complexity around. They do not eliminate the need to decide what the runtime is trusted to do.
SPIRE’s attestation model illustrates a concrete boundary: configured conditions determine which workloads receive identities. That helps establish the caller. Your application still needs to decide which assignments and business permissions that caller may use.
Start with the authority mode
Not every agent action has a human sitting behind it. A nightly reconciliation job may operate under an organisation’s explicitly granted service authority. It should not borrow the identity of whoever originally clicked “enable”. People take holidays. Their old browser session should not become infrastructure.
OAuth’s client credentials grant covers confidential clients acting over their own resources or access previously arranged with the authorisation server. That is different from assuming a particular user’s delegated authority.
Make the mode explicit in your design. A user-delegated assignment and a service-authorised assignment can have different approval, access and lifecycle rules. If a delegated grant becomes unavailable, silently switching to a more powerful service account changes the authority of the task. A successful fallback can still be the wrong product behaviour.
Google Cloud’s identity delegation architecture is one concrete example of distinguishing user, agent and delegated contexts. Its implementation choices are provider-specific, not a universal definition of how all agent systems must work.
A practical binding review
For Cedar, I would review one permitted request and three substitutions. Replace the tenant. Replace the agent principal. Replace the authenticated workload with an otherwise valid staging worker. Each substitution should be checked against an explicit rule, not accepted because the original request looked legitimate.
Then try a legitimate replica replacement. The system should allow an approved production worker to continue the assignment without confusing a new process with a new grant. Security design that rejects every change is easy. It also has the unfortunate side effect of rejecting the product.
These are proposed tests, not reported results. They should exercise the actual credential broker and resource boundary in a safe environment. A unit test proving that a string comparison works does not prove that an untrusted caller cannot supply the string.
Keep the administrative agent identity record linked to these relationships. It is useful for ownership and review. Keep the action audit trail linked to the actual checks and outcomes. Neither replaces enforcement.
Choose the boundary you can defend
A dedicated identity for every agent can improve policy separation, but increases provisioning and lifecycle work. A shared identity can reduce that overhead while enlarging the authority available to the shared runtime. Per-run credentials can narrow exposure, but require reliable issuance, expiry and task binding.
There is no prize for the largest identity spreadsheet. Choose granularity according to what must be isolated and what can be trusted together.
NIST’s recent agent identity design tenets call for distinguishable agent identities and risk-sensitive implementation. These are proposed design ideas, not a certification you obtain by renaming a service account.
My test is whether an engineer can point to the component that refuses a broken relationship. If the answer is “the prompt tells the agent who it is”, the identity architecture is still an introduction. The security boundary has not arrived yet.
