Agents need identity, authorization, and audit in the same place
FusionAuth 1.69 adds an AI agent entity type and lifecycle webhooks. Whether that answers the question your auditors ask depends on whose events they are.
Six months after you ship agent features, someone's security team will ask which agent read a specific document, on whose authority, and under what scope. That answer only exists if the system issuing an agent's credentials also recorded what the agent did with them. On most stacks those are two different systems, and the join between them was never built.
FusionAuth's 1.69 release, published August 25, names the pressure directly: "AI didn't create most of these problems. It removed the speed limit." It backs the claim with a number. In FusionAuth's 2026 State of AI & Identity Report, 88% of technology leaders said AI deployment is outpacing their identity and security infrastructure. An agent can operate continuously and exercise delegated authority thousands of times faster than the person whose authority it is using. That diagnosis is right, and it is the same reason we built agent registration into AuthKit.
What FusionAuth 1.69 actually ships
FusionAuth 1.69 gives agents a place to exist in the identity provider. There is an AI Agent entity type, so agents are distinguishable from other non-human entities, and there are entity lifecycle webhooks for create, update, and delete events.
It would be easy to describe that as a bare registry row and leave it there, and it would be wrong. FusionAuth's webhook system is mature. It covers more than fifty authentication lifecycle events, supports unlimited listeners, offers tenant-level granularity and transactional events, and can stream to Kafka as well as HTTP. FusionAuth also already ships an audit log covering administrative actions, readable through its API, and an event log for system and asynchronous events. If your objection to a hosted identity provider is that you would have to build the delivery layer yourself, FusionAuth is not the product that proves the point. The delivery layer is there.
The rest of 1.69 is careful work of the same kind. RFC 9207 issuer identification is on by default, and FusionAuth is straightforward that the client still has to validate the issuer identifier against the authorization server it intended to use. Signature verification key selection lets an application control which keys it accepts, and the release notes flag that verification is now strictly scoped to configured keys, so anyone running external JWT or SAML providers or active key rotation should read the 1.69 migration guide before upgrading. DPoP is not part of 1.69, though it belongs in the same picture: server-side support has been there since 1.63, and React, Angular, and Vue SDK support shipped on August 5, which brings sender-constrained tokens to browser apps without hand-written JOSE. Your API still has to validate the DPoP proof at the protected resource.
Strong primitives, assembly on you at the edges. That is the trade self-hosted identity always makes, and for teams that want to own the infrastructure it is the right one.
Whose events are they?
Here is the distinction that actually matters, and it is not about whether a pipeline exists.
Every event surface described above is scoped to what happens inside FusionAuth. Entity lifecycle webhooks describe the agent as a configured object: it appeared, its configuration changed, it was removed. The audit log covers administrative actions taken in FusionAuth. The authentication lifecycle events cover logins, group changes, MFA activity, and the rest of the identity provider's own domain.
None of that is a shortcoming. It is the correct scope for an identity provider. But the question your auditor asks is about a resource in your application: which agent read this document, at 3am on Tuesday, on whose authority. Reading the document did not happen in FusionAuth, so no FusionAuth event describes it. Between "agent created" and "agent deleted" sits every tool call and every resource the agent touched, and those are events your application emits or nobody does.
So the work that remains is not building a delivery pipeline. It is building the place your application's own agent events land, giving them a schema, giving them retention your auditors accept, and making sure the identifier in those events is the same identifier the credential was issued against. That last part is the whole thing. The join key between the credential and the action is the entire answer to every question you get asked during an incident: which agent, acting for which human, under which grant.
Registration, scopes, and audit want to sit in one place for that reason, and for no other.
Registration the agent drives itself
WorkOS took the other route. Agent Registration was announced on August 4 and uses auth.md, the open protocol for agent registration now built into AuthKit. Enrolling in the dashboard generates an auth.md file that agents read and use to register for scoped, short-lived credentials.
The agent finds it without documentation. Discovery follows the chain defined by RFC 9728: your API returns a WWW-Authenticate header with a resource_metadata parameter, that points at /.well-known/oauth-protected-resource, and the authorization server metadata it names carries an agent_auth block with the registration endpoints. A skill field in that metadata points at the generated auth.md, a step-by-step guide with curl commands already filled in for your environment, which the agent follows directly.
Registration supports three identity types:
The discovery metadata advertises anonymous and service_auth as the types an agent chooses between; refresh is the rotation path for a registration that already exists.
Those map onto two trust levels. An anonymous registration is untrusted before a claim ceremony, with limited scopes suitable for exploration, and trusted after one, with the full scopes you configured in the dashboard. An unclaimed agent becomes a real state with real, narrow permissions rather than an edge case you patch in later.
Registering anonymously is one call:
The response carries an identity.assertion the agent exchanges for a limited, untrusted credential, a claim.token it holds until a user shows up to take ownership, and the scopes.pre_claim and scopes.post_claim lists so the agent knows what it can do now and what claiming would unlock.
The claim ceremony works like the OAuth device flow. The agent presents a verification URI, the user signs in, the page reveals a short code, and the user reads that code back to the agent. The full loop is discover, register, explore, claim, act, with a human needed for one short moment in the middle. The onboarding instruction to a person is a single line pointing their agent at your auth.md URL. We walked through building that end to end in Teaching your API to onboard AI agents, so I won't repeat the wiring here.
The credential carries the delegation
What registration hands back is what makes the audit trail cheap later. An agent access token from WorkOS carries these claims:
The act claim follows the RFC 8693 delegation pattern and is present only after a claim ceremony has bound a user to the registration. Identity, organization, granted scope, and delegated authority all travel with the request, so your API never has to take an agent's word for who it is acting for.
Say the validation cost plainly. Short-lived access tokens can be checked locally by verifying the signature and expiration, which avoids a network round trip on every request, but local validation cannot see a revocation that happened before expiry. If you need that, call the validate credential endpoint. API keys must be validated server-side against the same endpoint. Credential type and lifetime are configured per environment, so the tradeoff between token lifetime and revocation latency is yours to set. The dashboard's Registrations tab lists every registration against the environment, its status (unverified, verified, expired, or revoked), the associated user, and the organization.
Audit arrives as a managed stream
Audit Logs records your application's events in the same platform that issued those credentials. Every event carries what kind of action was taken (action), who performed it (actor), what resources it affected (targets), and when and where it happened. The docs are explicit that this is a paper trail of sensitive actions kept for compliance and security, not a monitoring and alerting feed. We drew that same distinction in Why AI agent audit logs are different from application logs.
Because your application emits these events, the agent's sub and the authorizing user in act can be the actor on the record. That is the join.
Filtering the audit log by the agent registration ID answers the auditor's question without correlating across two systems.
Getting events out is configuration rather than code. Log Streams deliver to seven destination types: Datadog, Splunk, AWS S3, Google Cloud Storage, Microsoft Sentinel, Snowflake, and a generic HTTPS endpoint. Your customer's own IT contacts can set up a stream themselves through the Admin Portal with a setup link, without a ticket landing on your team. Streams report state as Active, Inactive, Error for retry-able failures, or Invalid for bad credentials or configuration, and move between those states automatically based on delivery outcomes. Events can also be exported as CSV, and WorkOS streams from a fixed set of IP addresses you can hand to a customer running an allowlist.
The setup cost is real. You configure allowed event schemas in the dashboard before you can emit anything, defining the action and its targets, and every event is scoped to an organization. Deciding which agent actions deserve an audit event is design work no platform does for you. What you skip is the delivery layer: idempotency is built in through an idempotency-key header, and if you don't send one, WorkOS derives it from the event content so a network retry doesn't duplicate the record.
Pick based on whose events you need
Both approaches give you a first-class agent identity and a way to move events. Neither one is missing a pipeline.
The difference is the boundary. FusionAuth gives you an agent entity, lifecycle webhooks, and a well-built streaming layer for events about the identity provider's own domain, on infrastructure you operate, and expects your application's agent activity to be recorded somewhere you build and join yourself. WorkOS gives you registration, scoped short-lived credentials, and an audit log your application writes to behind one API, with the same subject identifier on both sides, and expects you to accept a hosted dependency in your identity path.
That dependency cuts both ways, and it is fair to say so. If WorkOS is unreachable, your agents cannot register or rotate credentials, and the runbook for that is ours rather than yours.
If your team already runs the log pipeline, the storage, and the retention policy, and self-hosting is a requirement rather than a preference, the FusionAuth route fits the shop you have, and 1.69 makes agents legible in it in a way they weren't before. If it doesn't, the thing to compare isn't the feature list. It's what happens when that security team's question arrives, and whether you answer it by filtering one stream on the agent's sub and the authorizing user in act, or by joining two systems that were never designed to be joined.
Agent Registration has to be enabled for your environment, so check with your WorkOS account team first. After that it's dashboard enrollment, a generated auth.md, and a URL you hand to an agent.