Lola is a user in Acme's CRM: letting an AID agent into a system you already run

Who this works for, up front

Before the story, the limits. Whether an AID agent can work in a system you already run depends on what that system can do today. There are three kinds.

• Kind A: the system can validate a token itself. It accepts an OAuth 2.0 / OpenID Connect access token from an outside identity provider on its API, validates a signed JWT against the provider's published keys (JWKS), and can map a claim in the token to one of its own users. This works, with no extra component.
• Kind B: the system only has its own credentials. It has an API, but it only knows API keys, passwords or its own OAuth client, and cannot check an outside token. This works only with a gateway in front that holds the credential on the agent's behalf. That gateway is a real security risk, discussed below, and you should weigh it before choosing it.
• Kind C: the system cannot do either. No API, a screen-and-password login only, or only older protocols such as SOAP with its own security, EDI or file drops. This is not covered. Using it would mean changing the system or replacing something, and this version of the profile has no answer for it.

A quick test: look in the system's documentation for “external identity provider”, “JWT validation” or “JWKS” on its API. If you find them, you are probably in kind A. If you only find “API key”, you are in kind B. A system that only offers browser single sign-on (SAML or OIDC login pages) is not kind A by that alone.

The Acme story

Acme runs a CRM that has been there for years. It also has an ERP and a point-of-sale. Acme wants an AI agent, Lola, to read and create contacts in the CRM. It does not want to hand Lola a human's password, and it does not want to build an agent registry, a registration flow and a token server just for this.

So Acme creates a user called lola in the CRM, with permission to read and create contacts and nothing else. This is ordinary CRM administration, and the CRM's own permission model enforces it. Then:

• Acme's agents are registered at an AID issuer (for example 23blocks). Lola holds an Ed25519 key and proves she holds it when she asks for a token.
• The issuer gives Lola a short-lived token whose audience is the CRM, not a generic token that any service would accept.
• Lola presents the token. The CRM, or something in front of it, checks it and maps it to the user lola.
• The CRM sees “lola”. Not a shared account, not a human. Its own audit log says what Lola did.

Who decides what

The issuer answers one question: is this really Lola? Everything else stays with Acme.

• The issuer owns agent registration, authentication, the agent's status (active, suspended, deleted), the ceiling of scopes it will put in a token, and its signing keys.
• Acme owns the list of issuers it trusts, which agents it lets in, how the issuer's scopes map to Acme's permissions, the final allow or deny, its audit log, and its kill switch.

Entry is deny by default. A token from an issuer Acme has not configured is refused before any key is fetched. An agent registered in Acme's own tenant can be let in as a group; an agent from anywhere else (a partner, a contractor) needs a grant that names the agent, a ceiling of permissions, and a sponsor, the person at Acme who approved it. No grant, no entry.

The issuer's scopes are an input, not a copy. A scope Acme has not mapped grants nothing, and a grant's ceiling can only narrow what the issuer allows. Whatever the token claims, the permissions on the user “lola” in the CRM are the limit: in the runnable demo, Lola's token carries a delete permission and she is still refused.

Acme can also stop things without asking the issuer. Remove an issuer from its configuration and everything it issued stops. Delete a grant and that agent stops.

Kind A: the system takes the token

If the CRM can trust an outside identity provider on its API, this is the simple case. Acme registers the issuer in the CRM as a trusted identity provider (configuration, not code), creates the user lola, and maps a stable identifier in the token to that user. The CRM is unchanged and nothing sits in front of it.

What the system has to do on its own: accept RS256 JWTs, fetch the issuer's keys from its published JWKS, check iss, aud and exp, and look up its user from a claim.

One limit worth knowing: a system that only validates the token's signature learns of a suspension only when the token expires. Short lifetimes help (the profile recommends an hour or less for an organization's own agents, 15 minutes or less for external ones), and a system that can ask the issuer through token introspection (RFC 7662) before serving a request sees a suspension at once.

Kind B: a gateway, and its risk

If the old system only knows API keys, it cannot check a token. The profile's answer is a gateway in front of it. The gateway checks the agent's token, maps it to the agent's user, applies the company's rules, and then calls the old system as lola using a credential the gateway holds for her. The old system never learns a token was involved, and its own log still says lola.

If you go this way, the documented mitigations, most effective first:

• Run the gateway yourself, inside your network, so the credentials never leave you.
• Give each agent user the least privilege that works. A stolen credential is then worth only that.
• Where the old system supports OAuth client credentials, use them, so what travels is a short-lived access token.
• One process, one data directory and one master key per tenant. The reference gateway has one master key per process.
• Allow the agent users in the old system only from the gateway's address, and alert when one acts from elsewhere.

The reference gateway also narrows what an agent can do (a catalog of allowed requests, a per-agent rate limit, an audit log), but it can only narrow. The old system's permissions for the user remain the ceiling.

Kind C: not covered

If the system has no usable API, nothing here helps. This version of the profile does not pretend otherwise. Making such a system work means changing it: adding an API, adding token validation, or putting a connector in front, and that is outside what has been built.

Draft, verified, not verified

Stating the status plainly matters more here than anywhere, because this is about letting software into systems that hold your business.

What is a draft. The profile is draft 0.1 and is open for review. The format of status events (agent suspended, deleted, reactivated, token revoked) is invented in the profile; it is not a standard. It is meant to be aligned with the OpenID Shared Signals Framework / CAEP, which has no agent profile yet. Issuers also have to add things before this is safe for agents from outside a company, most importantly a token whose audience is the specific service.

What was verified.

• The reference verifier passes its 42 tests, and the reference gateway its 69.
• Two demos run on one machine: the kind A demo and the kind B demo, each of which also checks the refusals (wrong audience, forged token, expired token, unknown agent, suspended agent).
• One end-to-end run against a real issuer (its test environment, on a throwaway database), 19 checks. Running it found and fixed three problems, which are written up next to it.

What was not verified.

• There has been no independent security review of the gateway. Its own checklist lists the review as needed before real use.
• Nothing here has been deployed in production.
• Status events were only tested being delivered on localhost, over plain http.
• It has not been load tested. The gateway is a single process with in-memory limits.

Try it, and tell us what is wrong

The profile, verifier, gateway and demos are in the agent-identity repository (merged in pull request #24). The two demos run with Node 20+ and nothing to sign up for. If you run a system that fits none of the three kinds as described, or a reason the “deny by default” rules are not enough, that is the feedback most worth having. There is also a shorter page, Use AID agents in a system you already run.