Use AID agents in a system you already run
Your company has a CRM, an ERP or a point-of-sale. You want an AI agent to work in it, without sharing a human's password and without building an agent identity server. This page says how that works, and for which systems it does not.
The rules are in the AID Federation Profile (draft 0.1), now merged into main as a draft (pull request #24). It is not a released part of the protocol and it can still change.
The idea
The agent is a named user in the system you already run. Acme creates a user, say “lola”, in its CRM, with the permissions Lola should have, enforced by the CRM's own permission model. The CRM's audit log then says what Lola did, not what “the integration” did.
An AID issuer (for example 23blocks) registers the agent and proves it is really Lola: the agent signs with its Ed25519 key and receives a short-lived token meant for that system. The issuer does not decide what Lola may do.
Acme keeps the final authorization. Which issuers it trusts, which agents may enter, and what they may do all stay Acme's data. Entry is deny by default: an agent from an issuer Acme has not configured is refused before any network call, and an agent from outside Acme's own tenant needs an explicit grant naming a sponsor at Acme. Scopes from the issuer are an input to Acme's decision, never a copy of it, and can only be narrowed.
Who this works for
It does not make an old system modern. Which of three kinds your system is decides everything.
Takes the token itself
Works, no gateway needed.
The system can accept an OAuth 2.0 / OpenID Connect access token from an outside identity provider on its API: it validates a signed JWT (RS256) against the provider's published keys (JWKS), checks iss, aud and exp, and maps a claim in the token to one of its own users.
Acme registers the issuer as a trusted identity provider in the system, creates the user, and maps the token to it. The system itself is unchanged.
Only has its own credentials
Works with a gateway in front, and the gateway is a real risk.
The system has an API, but it only knows its own credentials (an API key, basic auth, its own OAuth client) and cannot check an outside token.
A gateway checks the agent's token, then calls the system as Lola using a credential it holds for her. The old system never learns a token was involved. The cost: the gateway holds the credentials. See below.
No usable API
Not covered.
Screen-and-password logins only, or only older protocols (SOAP with its own security, EDI, file drops). This version of the profile has no answer for these. They need changes: add an API, add token validation, or put a connector in front.
Two things that are not enough: a system that only offers browser single sign-on (SAML or OIDC login pages) does not by that accept a token on its API, and a system that checks tokens only from its own login server cannot trust another issuer until it can be pointed at one.
If you need a gateway (kind B), weigh this first
A gateway holds your credentials for the old system.
Anyone who compromises the gateway host and gets its master key can act in the old system as every agent user it holds a credential for. Encryption at rest protects a stolen vault file, not a stolen running host. This is the central risk of the design, and the gateway documentation says so in the same words.
The mitigations the reference gateway documents, 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 in the old system. A stolen credential is then worth only that.
- Prefer systems where the credential is an OAuth client, so what travels is a short-lived access token.
- One process, one data directory and one master key per tenant.
- Let the old system accept the agent users only from the gateway's address, and alert when one acts from anywhere else.
Whatever the gateway does, the old system's own permissions for the agent user are the ceiling. The gateway can only narrow them.
What is a draft, what was verified, what was not
- The profile itself (draft 0.1), merged as a draft and open to change.
- The status events format (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.
- An issuer has to add things before this is safe for agents from outside a company, such as a token whose audience is the specific service.
- The reference verifier: 42 tests.
- The reference gateway: 69 tests.
- Two runnable demos: an agent in a system that takes the token (kind A) and an agent in a system that only knows API keys, through a gateway (kind B).
- One end-to-end run against a real issuer, 19 checks, on its test environment.
- No independent security review of the gateway.
- No production deployment, of anything here.
- Status events were only delivered on localhost, over plain http.
- No load testing. The gateway is a single process with in-memory limits.
Read more
The same story told as a walk-through for a company with an existing CRM, ERP or POS.
Verification steps, configuration, staying current, and what an issuer must add. Merged into main with the profile.
Credential vault, request flow, threat model and security checklist, including what still needs an independent review.
Where the profile, verifier, gateway and demos were reviewed and merged. Comments welcome.