Agent API security: FAPI 2.0 is the floor

The software calling your APIs used to be a browser or a mobile app. More and more, it is an AI agent, acting for a person and making calls on its own, without anyone watching each step. That is a problem for the way most API security works today, and it means a route check and a bearer token are no longer enough on their own. The standard that already closes this gap came out of open banking.

Key takeaways

AI agents are becoming primary consumers of APIs, and they act for a user who is not watching each call.
A gateway checking routes and bearer tokens cannot tell whether a specific action, for a specific user, is one an agent should take.
The fix is not relocating checks: it is retiring plain bearer tokens for tokens cryptographically bound to the caller, on top of the gateway you already run.
Agents are unpredictable by design, so there is no fixed list of calls to approve in advance.
Financial-grade API (FAPI) 2.0, the standard built for sharing consumer data with third parties across banking, insurance, telco and energy, is the proven floor for this, and SecureAuth is a certified FAPI 2.0 provider.
Agent Authority adds both halves: a cryptographic identity for each agent, plus the runtime enforcement to back it. An inline broker holds the downstream credentials and decides allow, deny or step up on every call, with every decision logged.

Why a gateway and a bearer token are not enough

Most APIs sit behind a gateway that checks the route, plus an API key or a bearer token that grants access. That was already weak for human traffic. For agents it falls apart.

Regular software is predictable. Give it the same input and it does the same thing, so you can write down what it is allowed to call and block the rest. An AI agent does not work that way. Ask it the same thing twice and it may take different steps, because it decides what to do as it goes. There is no fixed list of calls to approve.

An agent also acts for a user who is not there to approve each request, so what the user agreed to has to travel with every call rather than be assumed at login. And an agent can be tricked by the content it reads, so any token sitting in its memory can be coaxed out of it.

A gateway checking a route and a bearer token cannot see any of this. It cannot tell whether this action, for this user, within these limits, is one the agent should be allowed to take.

None of this means replacing the gateway. It keeps routing and rate-limiting exactly as it does now. What has to change is the credential it is checking, and that change is additive. The authorization server stops handing out plain bearer tokens: it makes the client prove itself with a key instead of a shared secret, issues tokens cryptographically bound to the caller that are narrow and short-lived, carries the consent the user actually gave, and gives the agent an identity of its own instead of borrowing the user's. The API then verifies that binding on every request. That is more than basic OAuth was built to do. It is also something a proven standard already covers.

What financial-grade API security is

That standard is FAPI, the Financial-grade API profile from the OpenID Foundation. It was built for the high-stakes case of a consumer's data being shared with a third party: bank accounts and transactions, but equally insurance, telco and energy usage. That is why it is strict. Tokens are tied to the app they were issued to. The caller has to prove who it is with more than a password. And with Message Signing, every request and response is signed, which leaves a record no one can dispute.

Those are the exact things agent traffic needs. A tied token cannot be lifted out of an agent and used somewhere else. A signed request proves what an agent did when no person was watching. Strong caller identity means the agent has to prove it is itself on every call. The rules written to protect a consumer's account or usage data fit an AI agent making an API call, because the situation is the same. Something is acting on your behalf, and a stolen token or a faked request would be costly.

A bearer token can be replayed by an attacker, but a FAPI 2.0 sender-constrained token fails without the client's private key

SecureAuth is certified to that standard

SecureAuth is a certified FAPI 2.0 provider, for both the Security Profile Final and Message Signing Final, listed on the OpenID Foundation's public register as of 23 July 2026. Our certification post covers what the profile requires and why we tested all of it. What matters here is that the server which passed those tests is the same one you would put in front of your agents. Tied tokens, scopes, consent, and signed messages are there today, at the point where the agent actually calls. This is running and conformance-tested, not a roadmap item.

An identity for each agent, and something that enforces it

Financial-grade controls answer whether a request is valid, permitted, and provable. They do not answer which agent is making it, whether that agent should be running at all, or what to do about it mid-flight. That is what Agent Authority adds, and it is worth being precise that it does both halves: the identity and the enforcement.

The identity half is the one people expect. Every agent gets a cryptographic identity, so each one signs in as itself, carries only the access it was given, and can be told apart from other agents and from the person it works for.

The enforcement half is what makes it a runtime control, and it is the part that decides whether a given call runs. Agent Authority sits inline at the boundary as a broker, so the agent never holds the downstream credentials at all. It presents a short-lived ticket per request instead. Every call is checked against policy before it reaches the system behind it, and the outcome is allow, deny, or step up. Every decision is written down, and a blocked call explains itself. Because the credentials live in the broker rather than on the agent's machine, revoking access is one change in one place: the next ticket simply fails.

Put per-agent identity together with FAPI-grade tokens and signing, and the decision happens right where the action does, on every call. It is made by something you operate, not inferred from a token minted hours ago.

FAQ

Why can't my existing API gateway handle agent traffic?

A gateway checks routes and tokens. It cannot tell whether a specific action, for a specific user, within specific limits, is one this agent should take. You do not replace it. You keep the gateway and stop relying on plain bearer tokens, so every request carries a token bound to the caller and to the consent it was granted under, and the API verifies that on each call rather than trusting a decision made once at sign-in.

What is FAPI, and what does it have to do with AI agents?

Financial-grade API (FAPI) is the OpenID Foundation's hardened profile for OAuth: tied tokens, strong caller identity, and signed requests and responses. Those are the same properties you want when an AI agent is the caller, so it is a natural floor for agent-to-API security.

What is a certified FAPI 2.0 provider?

It means the platform has run the OpenID Foundation's FAPI 2.0 conformance tests against a named deployment and passed, with a dated public entry to show for it. SecureAuth passed for both the Security Profile Final and Message Signing Final, so the same server your agents call is the one that was tested. The certification post has the full detail.

Is SecureAuth actually certified?

Yes. SecureAuth is on the OpenID Foundation certification register for FAPI 2.0 Security Profile Final and Message Signing Final, dated 23 July 2026, SaaS deployment.

How is this different from just giving the agent a token?

A token sitting in an agent's memory can be leaked or coaxed out. Agent Authority does not give the agent that token: it holds the downstream credentials itself, hands the agent a short-lived ticket per request, and decides allow, deny or step up on every call. Add FAPI-grade handling, which keeps tokens tied to the caller and requests signed, and an agent can act without ever holding power it could be tricked into misusing.

Your agents are already calling your APIs. What decides each call?