Agentic Authentication & Authorization - Part 7: Operating in Production

Parts 1 to 6 built the controls. This part is about keeping them working once agents are live: recording what happened in a way you can trust, changing policy without breaking everything, noticing when a signal stops arriving, and pulling one agent out without taking its user down with it.

What changes once agents are live

Three properties of agents make operations harder than for human sessions:

They run unattended and for a long time. A human notices when something looks wrong; a background agent keeps going. draft-ietf-wimse-aims asks that long-lived sessions be terminated or downscoped on revocation or risk signals, not left to run to completion.
Their actions fan out. One user request can produce dozens of tool calls across several servers and domains (Part 3). Without correlation, an incident becomes guesswork.
Their failures are quiet. A stalled signal stream or a stale cache doesn’t throw errors. It just lets decisions be made on old facts.

Decision logs that keep user and agent apart

The audit log is where the series’ through-line (who decided, who consented, who executed) either holds or falls apart. draft-ietf-wimse-aims requires durable, tamper-evident audit logs and lists the minimum fields. The table adds the fields from earlier parts that make those minimums useful.

Field	Required by draft-ietf-wimse-aims	Where it comes from
Agent identifier	Yes	Token `client_id` (Part 2)
Delegated subject	Yes	Token `sub`
Resource, action and decision	Yes	The AuthZEN request and response (Part 5)
Timestamp and correlation ID	Yes	`X-Request-ID` echoed by the PDP; Transaction Token `txn` (Part 3)
Posture or risk state	Yes	Signals the PDP holds when it decides
Remediation events	Yes	Revocations and downscoping triggered by signals
Actor chain	Recommended	The `act` claim, including nested prior actors (RFC 8693)
Policy and mapping version	Recommended	Your policy repository; the tool’s `x-authzen-mapping`
Approval evidence	Recommended	`approval` from the Access Request and Approval Profile; CIBA `auth_req_id` (Part 6)

Two details matter. First, RFC 8693 says prior actors are informational only for access control. That is exactly why they belong in the log: the decision ignores them, the investigation needs them. Second, the same draft says operators should be able to reconstruct the full execution chain, including delegated authority and intermediate calls. Test that you can, with a real request, before you need to.

Policy lifecycle

No standard covers how you manage policy, and draft-ietf-wimse-aims leaves policy formats to deployments. What the earlier parts do fix is what can go wrong, which gives four practices.

Treat policy and mappings as code. Policies live in version control with review. So do tool mappings: COAZ-MCP evaluates only what a mapping projects, so a mapping change that drops an argument silently removes a check (Part 5).
Test against real requests. Keep a set of recorded evaluation requests with known-good decisions and run every policy change against them. AuthZEN’s request format is fixed, which makes such a suite portable across PDPs.
Run new policy in shadow first. Evaluate the candidate policy alongside the live one on production traffic and compare decisions before enforcing it.
Make rollback faster than rollout. A bad rule in a central PDP affects every tool behind every PEP at once.

One more source of change is easy to miss. Client ID Metadata Documents are hosted by the client and can change at any time. The OAuth draft lets the authorization server re-evaluate consent or revoke tokens when keys or key-related metadata change. Watch for it rather than finding out from a support ticket.

Signal streams: SSF, CAEP and RISC

Tokens and cached decisions are snapshots. The OpenID Shared Signals Framework (SSF 1.0, Final) is how the snapshot learns it is out of date. draft-ietf-wimse-aims states the consequence plainly: after a revocation or risk notice, cached authorization decisions and tokens that are no longer valid must not continue to be used.

How events travel. Each event is a Security Event Token (RFC 8417), a JWT typed secevent+jwt with the subject in sub_id and the event under events. Delivery is push (RFC 8935, the transmitter POSTs to the receiver) or poll (RFC 8936, the receiver fetches). Subjects use RFC 9493 identifier formats such as email, iss_sub or opaque, or a complex subject combining user, device, session, tenant and group. Receivers manage streams through a configuration endpoint, and add or remove subjects per stream.

Which events matter for agents. CAEP 1.0 defines eight event types; RISC 1.0 adds account-level ones.

Event	Profile	What it means	What to do with agents
`session-revoked`	CAEP	A session for the subject has ended	Stop every agent acting under that session; deny in the PDP
`credential-change`	CAEP	A credential was created, changed, revoked or deleted	Re-check tokens derived from it
`token-claims-change`	CAEP	A claim in the subject’s tokens changed	Refresh cached attributes in the PDP
`assurance-level-change`	CAEP	Authentication strength went up or down	Require step-up for sensitive tools (Part 6)
`device-compliance-change`	CAEP	A device became compliant or non-compliant	Re-evaluate agents running on that device
`risk-level-change`	CAEP	Assessed risk moved to LOW, MEDIUM or HIGH	Downscope, or require approval
`session-established`, `session-presented`	CAEP	A session started, or was seen active	Correlate in logs
`account-disabled`, `account-purged`	RISC	The account was disabled or deleted	Revoke every grant the user gave to agents
`credential-compromise`	RISC	An identifier was found compromised	Treat as an incident (below)

RISC’s own sessions-revoked is deprecated; new implementations must use CAEP’s session-revoked.

Knowing the stream is alive. A stream that stops delivering looks exactly like a quiet day. SSF has the tools to tell the difference. A receiver can read a stream’s status (enabled, paused or disabled) from the status endpoint, and can ask the transmitter for a verification event by posting its stream_id to the verification endpoint. Transmitters may also send verification events unprompted. Request one on a schedule and alert when it does not arrive. That turns a silent failure into a page.

Agent lifecycle

An agent is a piece of software with a lifecycle of its own, separate from the users it serves. Part 2 gave it an identity; operations has to manage that identity from registration to retirement.

The highlighted path is the one most deployments cannot take today. If the agent runs on the user’s own token, the only way to stop it is to stop the user. With its own client_id, its own keys and tokens that name both parties, you can pull one agent and leave everything else running.

Three practices keep the lifecycle manageable:

Keep an inventory. Every agent, its client_id or metadata document URL, its owner, and the tools it may call. draft-ietf-wimse-aims leaves registries to each deployment, so this one is yours to build.
Rotate without re-registering. Keys published through jwks_uri can change while the client_id stays the same. Expect authorization servers following the Client ID Metadata Document draft to re-check consent when keys change.
Deprovision through signals. draft-ietf-wimse-aims asks credential issuers to announce status changes over SSF, so credentials derived from a revoked one are revoked too.

Incident response: containment paths

The right lever depends on what was compromised. The aim is the smallest blast radius that actually contains it.

What was compromised	Contain with	Standards
One agent’s key or credential	Disable the client at the authorization server, rotate its keys, revoke its tokens, and add a PDP deny on its `client_id`	RFC 7009; AuthZEN policy
One user’s account	Revoke the user’s sessions and emit `session-revoked` so every receiver acts; disable the account	CAEP; RISC `account-disabled`
One MCP server or tool	Remove it from the gateway, and deny its resource in the PDP; revoke tokens issued for its audience	COAZ-MCP; RFC 8707 audiences
A pattern across agents, such as prompt injection through a shared data source	Deny the affected action or resource in the PDP for every agent, then narrow it down	AuthZEN policy

Two mechanics decide how fast containment actually happens.

Revocation reaches what it can see. Revoking a refresh token through the RFC 7009 endpoint should also invalidate access tokens from the same grant. But a self-contained JWT stays valid until it expires for any resource server that reads it directly. RFC 7662 token introspection closes that gap by asking the authorization server for the current state, at the cost of a call. Keep tokens short-lived, and introspect on high-risk tools.
The PDP is the fastest switch. One deny rule applies to every call behind every PEP on the next evaluation, provided no cache keeps serving old decisions.

After containment, the decision log becomes the record of what happened: every decision for that agent or user, which approvals it relied on, and which actor chain each call came through.

Operational checklist

The series condensed into what has to be true in production. The priority column is my own judgment, not a standard’s.

Area	Requirement	Priority	Part
Identity	Every agent has its own `client_id`; no shared secrets	Must	2
Identity	Agent credentials issued at runtime, short-lived, kept away from the model	Must	2
Tokens	Every token audience-bound; no token passthrough	Must	4
Tokens	Tokens sender-constrained (DPoP or mTLS)	Should	2
Delegation	Downstream hops use token exchange with `act`, not forwarded tokens	Must	3
Authorization	High-risk tools checked per call by a PDP, failing closed	Must	5
Authorization	Mappings project every argument a rule depends on	Must	5
Human in the loop	Approvals happen on a channel the agent does not control	Must	6
Logging	Audit log has the draft-ietf-wimse-aims minimum fields, plus the actor chain	Must	7
Logging	A full execution chain can be reconstructed from the logs	Should	7
Policy	Policies and mappings in version control, tested, with fast rollback	Must	7
Signals	SSF streams monitored with scheduled verification events	Should	7
Signals	Caches invalidated on revocation and risk events	Must	7
Response	One agent can be revoked without revoking its user	Must	7

Agentic Authentication & Authorization - Part 7: Operating in Production

What changes once agents are live

Decision logs that keep user and agent apart

Policy lifecycle

Signal streams: SSF, CAEP and RISC

Agent lifecycle

Incident response: containment paths

Operational checklist

Sources

Agentic Authentication & Authorization - Part 1: Fundamentals

Agentic Authentication & Authorization - Part 2: Agent Identity

Agentic Authentication & Authorization - Part 3: Delegation