TLDR: Right now, agents walk into systems that have no idea they’re there. They act under human identities those systems verified once and trusted indefinitely. When something goes wrong, the system can’t tell you who was really responsible. Building agent-aware systems means creating a policy surface that doesn’t currently exist - and doing it before regulation forces the point.

This is Part 3 of a three-part series. Part 1 covers the NIST IAL/AAL identity framework for agents. Part 2 covers securing the browser session - prompt injection, dry runs, and action-time assurance.

The Receiving End Has No Idea

If an agent logs into your system using a valid session token, you don’t know. The token is valid. The IP might be a cloud provider you haven’t blocked. The user-agent string says Chrome. The form is filled out correctly. Everything looks fine.

This is the fundamental problem for system owners: your threat model for credential misuse assumes unauthorized access - someone who shouldn’t be there at all. An agent acting on behalf of an authorized human is authorized by definition. The signals you’d use to detect stolen credentials don’t apply.

And yet the risk is real. An agent with unconstrained scope can do more in a session than a human - faster, more systematically, without the natural hesitation a person would feel before a consequential action. If your system has IAL2 requirements, those requirements were placed on a human at enrollment. The agent that shows up afterward never had to meet them. Your system has no way to know the difference, and no policy surface to act on it even if it did.

The Transparency Layer

The first thing a system needs to handle agents is a way to detect them - or more precisely, a way for agents to declare themselves.

Detection alone is the wrong frame. Force detection and agents will spoof it. A better model is disclosure with incentive: build a mechanism where declaring agent identity unlocks smoother access - appropriate rate limits, known scope, cleaner audit trails - and where undeclared agent sessions face additional friction. Teams deploying agents will disclose honestly when it helps them. This creates the policy surface organically rather than through enforcement you can’t reliably do.

Concretely: a session with agent-like behavioral patterns but no declared token gets shorter session timeouts, step-up prompts before writes, and tighter rate limits on data endpoints. A session that declares an agent token with valid scope gets purpose-calibrated limits - more permissive on reads within scope, more restrictive on writes, with step-up hooks on consequential actions. The declared session is easier to work with. The undeclared session is progressively harder. Legitimate teams deploying agents respond to that gradient. Malicious use doesn’t announce itself, but raising the cost of undeclared access is still worth doing.

What a transparency layer needs to carry:

• Agent identity - what agent is this, and who is responsible for it?
• Human principal - who authorized this agent? At what IAL/AAL did that human authenticate before granting authorization?
• Declared scope - what is this agent authorized to do in this session? Which endpoints, which actions, which data?
• Delegation chain - if this agent was spawned by another agent, what’s the full chain back to the human? Scope should only narrow at each hop, never expand.
• Authorization timestamp - when was this delegation granted, and when does it expire?

The OAuth ecosystem already has most of the primitives. The act (actor) claim in JWT allows expressing “this token is being used by X on behalf of Y.” The scope claim limits permitted actions. Adding agent-specific claims - agent identifier, delegation chain, step-up requirements - is an extension of existing infrastructure, not a replacement.

Where the Standards Work Stands

Two IETF efforts are directly relevant to building this infrastructure:

Transaction Tokens for Agents (draft-araut-oauth-transaction-tokens-for-agents) extends OAuth transaction tokens to carry agent context through a call chain. The key constraint it enforces: scope narrows at each delegation hop. A sub-agent can only do less than the agent that delegated to it, never more. This is the enforcement mechanism most current deployments lack entirely - and it’s the right model for multi-agent systems where an orchestrator spawns worker agents across different systems.

HDP (Human Delegation Provenance) (arXiv 2604.04522, also filed as an IETF draft) proposes a cryptographic chain of custody from the authorizing human to every downstream agent action. The full delegation trail is encoded in a compact, signed token. Verifiable fully offline - no central registry, no network call at verification time. A reference TypeScript SDK is available on GitHub. This addresses the multi-agent chain problem that transaction tokens alone don’t solve: proving that a specific consequential action traces back to a specific human authorization event.

Neither is an accepted RFC. But the patterns they describe are implementable today with existing JWT and OAuth infrastructure. Building toward these models now puts you ahead of the compliance requirement rather than scrambling to catch up.

Policy Surfaces You Need to Build

Once you know an agent is there - or have created incentive for it to declare itself - you need something to do with that information.

Scope-bound access control - rather than granting agent sessions the same access as the human, evaluate the agent’s declared scope claim and grant only what’s declared. If the agent claims it can read but not write, enforce that at the system boundary, not by trusting the agent to self-limit. The scope claim becomes an authorization contract.

Important: agents can’t self-declare arbitrary scope. The scope in the token needs to be constrained by what the authorizing human was actually permitted to delegate when they granted authorization. If agents can declare any scope they want, they’ll declare maximum scope and the control is meaningless. The binding between human authorization and agent scope claim is the critical piece - and it’s exactly what the Transaction Tokens for Agents draft is trying to formalize.

Step-up requirements for consequential actions - high-stakes endpoints (submit, modify, delete, pay) require a fresh human signal before executing. Not just a valid token - evidence that a human was present at the moment this specific action was requested. A cryptographic signature, a biometric confirmation, an explicit out-of-band approval. The system enforces this regardless of what the agent claims about its authorization.

Differentiated rate limits for agent sessions - agent sessions can be significantly more systematic than human sessions. Rate limits calibrated for human browsing patterns may be either too restrictive (blocking legitimate agent work) or too permissive (allowing agents to hammer endpoints that would naturally throttle under human use). Agent-declared sessions get different rate limit policies - potentially more permissive for read operations, more restrictive for write operations.

Audit trail differentiation - human actions and agent actions should be distinguishable in the audit log. This is the minimum viable change for most legacy systems: add a flag or claim to log entries that indicates agent involvement, even if you can’t enforce scope yet. When something goes wrong, you need to reconstruct whether a human or an agent took the action - and under whose authorization.

Graceful disclosure incentives - this bears repeating as a design principle. If an agent declares itself and its scope, reward it with smoother access. If a session exhibits agent-like patterns without a declaration, apply additional friction - shorter session timeouts, additional step-up prompts, tighter rate limits. This creates pressure toward the disclosure model without requiring enforcement you can’t reliably do.

The Legacy System Problem

Most government systems weren’t built for any of this. They’re running on frameworks that don’t support custom token claims, have hardcoded session models, and were authorized to operate under assumptions that predate browser-use agents. Rewriting them isn’t the answer.

The realistic path is layering policy enforcement in front of systems rather than inside them.

API gateway and reverse proxy enforcement - put the agent policy layer in front of the system. The gateway inspects token claims, validates declared scope, enforces step-up requirements for consequential endpoints, and applies differentiated rate limits. The legacy system sees a validated session that already had agent policy applied.

One thing to be realistic about: inserting a new reverse proxy in front of a legacy federal system can require an ATO amendment, network architecture review, and security assessment. For some systems that’s a multi-year undertaking. Start by inventorying which systems already have API gateway infrastructure in place - those are your first targets. For systems without it, this belongs in the modernization roadmap, documented as a known gap in the interim.

Step-up redirect flows - for consequential actions, the gateway intercepts the request and redirects the agent to a human step-up flow before allowing it through. The human completes the confirmation. The gateway releases the action. The legacy system only ever receives the confirmed, authorized request.

Audit log enrichment - a sidecar service that correlates agent session signals (known agent IPs, declared agent tokens, behavioral patterns) with existing audit logs and adds agent attribution fields. Not ideal, but substantially better than nothing while the underlying system modernizes.

Agent registry - a centralized registry of known, vetted agents that have been authorized for specific system access. New agents can’t access sensitive systems until registered. The registry gives system owners a policy handle they don’t otherwise have: you can revoke an agent’s access, scope its permissions, and track its activity across sessions. Think of it like a software supply chain manifest - but for the agents acting in your systems.

The governance questions don’t have easy answers: who runs it, who does the vetting, what happens when an agent ships a new version, and what’s the revocation process when one is compromised? These are the same problems that have made centralized PKI hard for decades. Worth building toward - but define the governance model before deployment, or the registry becomes a checkbox rather than a control.

This is the model that makes agent-aware infrastructure tractable for government without requiring every legacy system to be rebuilt: enforce at the edge, enrich at the log, register at the registry.

What Teams Should Do Right Now

For teams that own systems agents might access:

1. Audit your token issuance - do your access tokens carry enough context to distinguish agent access from human access? Add claims, even informally. JWT custom claims are parseable and enforceable today without waiting for a standard.
2. Define your agent policy, even informally - which agent patterns will you allow? What scope? What step-up requirements for consequential actions? Document it. When an agent deployment team comes asking, you’ll have an answer.
3. Separate agent actions in your audit log schema - even if you can’t detect agents reliably today, create the schema that will support differentiation when you can. Retrofitting log structure after an incident is hard.
4. Build step-up hooks on your consequential endpoints - identify your high-stakes actions. Add the infrastructure to require a fresh human signal at those endpoints. This is valuable for human sessions too - it’s not agent-specific overhead.
5. Get into the WIMSE and Transaction Tokens drafts now - not to passively monitor, but to understand the token claim model well enough to implement it before it’s mandated. Map which of your existing token issuance flows would need to change. If your team has hands-on OAuth transaction token experience, the working groups are open to comment - practical input from government system owners is thin and genuinely useful.

The Bigger Picture

Right now, agents walk into systems that have no policy surface for them. They act under human identities those systems verified once, extended indefinitely, and will attribute forever if something goes wrong.

The identity assurance work that went into IAL and AAL - proofing, authentication, binding - is being short-circuited by a layer of software those systems were never designed to account for.

The answer isn’t to stop deploying agents. It’s to build the infrastructure that makes agent access legible - to the system, to the auditor, to the person whose identity is being borrowed.

That infrastructure doesn’t fully exist yet. The standards are drafts. The implementations are early. The compliance requirements haven’t caught up.

Three questions are worth asking about any system agents might access: Does it know when an agent is there? Can it express what that agent is allowed to do? Can it hold someone accountable when the answer to either is no?

If the answer to all three is no today, that’s your roadmap. Pick one and make it concrete. The systems that have partial answers before a compliance requirement lands will be in a very different position from the ones that don’t - and in government, the compliance requirement will come in the form of an incident first, then a memo, then a mandate. The sequence is predictable. The timing isn’t.

Thinking through agent access policy for a government or regulated system? I’d love to compare notes. Reach out.