Agents Are Just Identities. The Boundary Hasn't Moved.

Two camps are selling federal agent strategy in 2026. One is mostly wrong.

The wrong camp is selling a new IAM tier. New agent-identity platforms, new agent-IAM control planes, new agent-account types. The pitch is that agents are a third actor class, neither human nor service, and federal IT shops need new tooling to handle them.

The right camp is quieter. It says federal IT has run identity, authorization, lifecycle, and audit for three decades on a control catalog that doesn’t distinguish actor classes. The boundary already knows how to hold a new actor. The work isn’t to build new infrastructure. The work is to apply existing discipline with more rigor, at machine speed.

This is the case for the second camp.

Same primitive: agents are identities

The IAM model federal programs run on isn’t actor-agnostic by accident. It’s actor-agnostic by design. NIST 800-53 controls AC-2 (account management), AC-3 (access enforcement), AC-6 (least privilege), AU-2 (auditable events), and IA-2 (identification and authentication) scope, authorize, and audit accounts without specifying what kind of entity sits behind the account. A human’s PIV card and a service principal’s certificate are both managed under AC-2. An agent’s account is the same primitive.

The LLM is a capability. The identity is an account. Conflating them is the original sin of the agent-platform market.

The model that generates an agent’s behavior is a capability bound to an account, the same way a software workload’s runtime is a capability bound to a service account. The identity that executes the agent’s actions is just an account. Once you separate them, the rest follows. The account gets a scope. The scope gets a policy. Every action lands in an audit log under the account’s name. Existing controls. Existing implementation. Existing audit posture.

The right camp uses the existing identity primitive directly, sometimes through a thin authorization layer that binds new actors to it. The wrong camp replaces it.

Workload identity standards like SPIFFE and SPIRE were designed for exactly this class of non-human, scope-bound, audit-attributed account.

What changes at agent velocity

What’s genuinely new about agents isn’t the identity primitive. It’s the operating envelope.

Budgets. Humans have implicit budgets via salary and hours. Services have known cost shapes, SLA-bound and predictable. Agents have open-ended cost variability. A misconfigured agent can burn a quarter’s worth of tokens or compute in an afternoon. The ideal is for the IAM platform to manage agent budgets natively. Where it doesn’t yet, the practical substitute is the rate-limit layer at the API gateway. Rate limits aren’t budgets, but they’re the next-best ceiling.

Rate limits and discrete actions. A human user might call an internal API a dozen times an hour. An agent can call it ten thousand. No allow-alls. No catch-all permissions. Every action an agent takes should be a discrete, named operation with a discrete, named scope. “Read tickets in queue X” is a permission. “Read tickets” without a queue scope is a liability. The same discipline holds at the OS layer. An IAM policy that whitelists which commands an agent may run forecloses both destructive operations and horizontal or vertical privilege escalation paths.

Focused responsibilities. The Single Responsibility Principle applies to agents the way it applies to microservices. An agent that logs into two systems, pulls data from one, writes to the other, and decides between three downstream workflows is doing the work of three agents wearing one badge. Federal CTOs should push back on vendor pitches for general-assistant agents. Generality is where audit posture breaks. Three focused agents are easier to govern than one general one.

The supporting stack

The identity primitive doesn’t change. The stack around it does.

Lifecycle. Joiner / Mover / Leaver applies to agents at agent velocity. An agent is provisioned when its task is approved, rescoped when its responsibility narrows, and deprovisioned the day the task is done. Quarterly access certifications, the standard federal IAM ritual, run against agent accounts the same way they run against human accounts.

Observability. Agent actions arrive faster than a human auditor can read them. The audit log has to be human-digestible at agent velocity. OpenTelemetry traces, identity-attributed, ingested into the SIEM that already carries the program’s audit-integrity discipline. Each agent action is one span. The reviewer’s question is the same as it always is: who did this, what were they authorized to do, did they stay inside the lines.

Where the IAM platform falls short. Existing IAM platforms don’t all support agent-specific budget tracking, action-level scope enforcement, or token-bound lifecycle. Where they don’t, an agnostic agent-extension layer can carry the gap. It’s a thin middleware that binds agent accounts to the existing IAM and adds the controls the platform doesn’t yet expose. It’s the kind of architectural insertion that warrants a Change Request and a Risk Acceptance, not a quiet rollout. That formality is the right level of scrutiny for putting anything between an authorizing official’s IAM and a new actor class.

The architectural payoff: model swap without re-ATO

The payoff for treating agents as identities, not as a new class, is in the ATO economics.

Frontier models version every month. ATO cycles take six to twelve months minimum. If your agent’s identity is fused to the model, that is, if “agent” and the specific model name are the same line in your boundary diagram, every model swap is a re-ATO. The program becomes hostage to model release cadence.

If the agent’s identity is stable and the model is abstracted behind it, the calculus inverts. The model becomes a swappable capability. The identity, scope, and audit posture survive the swap. The authorizing official re-evaluates the new model’s behavior; the boundary doesn’t re-architect.

This pattern holds within an accreditation envelope. A new model from a new vendor, or a substantially different model from the same vendor, still warrants accreditation review. The pattern reduces the frequency of re-ATO; it does not eliminate it.

This is the single most consequential architectural decision in federal agent delivery in 2026.

What to ask

A federal CTO, IPT lead, or GS-15 evaluating an agentic AI offering in 2026 should be able to ask four questions and get four direct answers:

1. How does each agent’s identity land in our existing IAM control plane? Show me the account record, the scope expression, the lifecycle hooks. If the answer is a separate identity store, that is the new IAM tier you’re being sold. Ask why.
2. What does one agent action look like in our SIEM? Show me one span, identity-attributed, OpenTelemetry-native, ingestible without translation.
3. Where do budgets live? In the IAM platform, in an extension layer, or in the rate-limit gateway. Whatever the answer is, the cost ceiling has to be auditable.
4. What is the path to swapping the underlying model? If the answer requires re-ATO, the architecture is fused to a vendor’s release cadence. That is a procurement problem.

Agents are not a new actor class. They are identities, scoped and audited like every other actor the boundary already knows how to hold. The new work is governance at machine speed. The old work is what it has always been.