Field Notes on Agent Identity: The Missing Control Plane for Machine Workers

An AI agent that drafts text is a feature. An AI agent that reads customer records, updates a ticket, issues a refund, or opens a pull request is an actor. That distinction is forcing identity infrastructure to answer a question it was not designed around: who, exactly, is acting when software exercises judgment on behalf of a person?

The familiar answers are insufficient. A shared API key identifies an application, not an individual agent run. A user token can grant the agent everything the user can do, even when the task requires only one narrow action. A service account persists long after the temporary assignment that justified it.

The emerging design is agent identity: a control layer that binds a particular machine worker to a human principal, an approved task, a set of tools, a time window, and an evidence trail. The idea is still taking shape, but its practical implications are already visible.

What changed: agents crossed the boundary from content to authority

Earlier AI integrations mostly transformed information. A model received a prompt and returned a summary, classification, or draft. Security teams could treat the model as a component inside an application whose permissions were determined elsewhere.

Tool-using agents alter that arrangement. The model may select an action, construct arguments, inspect the result, and decide what to do next. It can traverse several systems during one assignment. A support agent might search an account, inspect an order, consult policy, update a case, and initiate a refund.

This creates an authority chain rather than a single request:

1. A person or system assigns an objective.
2. An orchestrator starts an agent run.
3. The agent chooses a tool.
4. An authorization layer decides whether this run may use that tool for this purpose.
5. The target system performs the action and records the result.

The important change is not that AI has become a legal person or employee. It has not. The change is architectural: dynamic software is now making consequential choices inside delegated authority. Identity must therefore describe more than the calling application.

The emerging object: an identity scoped to one assignment

A useful agent identity is not a new username with a whimsical name. It is a structured statement about delegated authority. At minimum, it should connect six elements.

This resembles workload identity, delegated authorization, and capability-based security, but the combination matters. Conventional workload identity answers which service is calling. Agent identity must additionally express why this particular execution is calling and how its authority relates to the assigned task.

The strongest pattern is to mint short-lived credentials after policy evaluation rather than placing durable secrets in the agent’s environment. The model can request a capability; it should not retrieve a master credential and decide its own limits.

What it means in practice: authorization moves closer to the action

Coarse permissions are poorly matched to agents because agents interpret context at runtime. Giving a service account general refund access leaves the crucial decision—whether this refund is allowed—inside probabilistic reasoning.

A safer design separates proposal from authorization. The agent proposes an operation with structured arguments. A deterministic policy layer evaluates identity, task state, resource boundaries, and business rules. Only then does an executor call the target system.

A worked refund path

Suppose an agent receives: Resolve the customer’s duplicate charge. It finds two similar transactions and proposes a refund. The authorization service checks that the ticket belongs to the customer, one transaction remains unsettled or refundable under policy, the proposed amount matches the selected transaction, and the run has not already issued a refund.

If every condition passes, the service creates a narrowly scoped, short-lived authorization for that transaction. If the amount exceeds the agent’s delegated boundary, the proposal becomes an approval request rather than an execution.

This design does not require the policy engine to understand natural language. It requires the agent to translate intent into a typed request whose claims can be checked. The identity layer supplies the context that makes those checks meaningful.

Delegation creates a graph, not a chain of API keys

Agents increasingly invoke subagents or external tools. A research agent may ask another process to inspect filings, while a coding agent delegates test execution to an isolated worker. If each component simply inherits the parent’s token, authority expands invisibly.

Secure delegation should attenuate permissions: a child receives no more authority than its parent and preferably receives less. A parent with access to a project repository might delegate only permission to read test files and run a specific test command. The child should not inherit deployment rights merely because the parent possesses them.

The resulting delegation record should preserve provenance:

• which principal initiated the work;
• which agent run delegated the subtask;
• which capabilities were transferred or removed;
• which policy approved the delegation;
• which actions followed from it.

This turns identity into a graph of bounded authority. It also makes incident review possible. Investigators can distinguish an initial assignment from a later tool action instead of confronting a log filled with requests from one undifferentiated service account.

The operational trade-offs are sharper than they appear

Fine-grained identity improves control, but it introduces coordination costs. Every tool call may require policy context. Short-lived credentials need issuance and renewal. Resource-specific constraints must be represented consistently across systems that use different permission models.

There is also a latency trade-off. Evaluating every low-risk read through a remote authorization service can make an interactive agent sluggish. Teams may cache policy decisions, batch capability grants, or issue a task-scoped token covering several related reads. Each optimization widens the gap between current policy and enforced policy.

Another tension concerns observability. Rich audit records help explain behavior, yet prompts, retrieved documents, and tool arguments may contain sensitive data. Recording everything produces a forensic asset and a privacy liability. A durable record may need hashes, references, decision metadata, and redacted arguments rather than complete conversational traces.

Finally, identity cannot compensate for ambiguous business rules. If an organization cannot state when a refund, account change, or deployment is permitted, encoding agent permissions will expose that ambiguity rather than resolve it.

A practical architecture for the next build

Teams do not need a universal agent passport before adopting stronger controls. They can begin with a compact architecture.

1. Create a unique identity for every run. Do not rely solely on the application’s service account.
2. Bind the run to a principal and purpose. Preserve who initiated it and the task identifier that authorizes it.
3. Keep durable secrets outside model reach. Place credential exchange and secret use behind a trusted executor.
4. Represent actions as typed requests. Separate the model’s proposed intent from the actual API invocation.
5. Issue narrow, expiring capabilities. Scope them by action, resource, and time wherever target systems allow it.
6. Require escalation at irreversible boundaries. Payments, publication, deletion, privilege changes, and deployment deserve explicit gates.
7. Record decisions, not only calls. Log the policy version, relevant claims, approval path, and resulting action.

The revealing test is revocation. If an operator cancels an assignment, can the system promptly stop every child process and invalidate its remaining authority? If not, the architecture has task tracking, but not yet task-bound identity.

What remains unresolved

The largest open issue is semantic authorization. Traditional policies evaluate known actions against known resources. Agents operate from goals whose meaning can shift as new evidence appears. Translating help this customer into a safe set of capabilities remains partly a product-design problem, not merely an identity protocol.

Cross-system interoperability is another gap. One platform may support resource-scoped tokens; another may offer only broad API keys. An agent can be precisely authorized at the orchestration layer and still encounter a blunt permission boundary downstream.

Accountability also remains unsettled when several actors contribute: the user supplies the objective, the model selects the action, the developer defines the tools, and an operator approves an exception. A strong audit trail can reconstruct this chain, but it does not automatically decide responsibility.

The deeper opportunity is now clear. The next generation of identity infrastructure will not merely verify that machine traffic is authentic. It will make delegated intent inspectable, authority temporary, and autonomy revocable. As agents become more capable, the decisive advantage may belong not to the system that can do the most, but to the one that can prove why each action was allowed.

This post was drafted with AI assistance and reviewed against our editorial policy before publication. Corrections are made at the source, on the page, with the date shown.