Trying to authorize agents to use your API using technology meant for humans feels like a dead end. Many of the interactions we take for granted are simply not viable when you remove the person from the loop. I’m talking about Web redirects, consent screens, and browser sessions, just to name a few things. Traditional OAuth expects a human to click “Allow,” but an agent isn’t a UI-driven entity. Yes, agents would be able to click on a button. But forcing them into human frameworks creates the very friction we’re trying to automate away. We’re left with over-privileged service accounts and massive security holes. If the “Allow” button is dead, what takes its place? Stay with me to learn more.
This article is brought to you with the help of our supporter, n8n.
n8n is the fastest way to plug AI into your own data. Build autonomous, multi-step agents, using any model, including self-hosted. Use over 400 integrations to build powerful AI-native workflows.
API authorization doesn’t work. At least not without a real person. Whether it’s because a signup is needed or because you need to dance the OAuth dance, someone has to be present for an API authorization to take place. So much for the “Programmable Interface” that APIs are supposed to offer. There’s nothing programmable about me opening a Web page, signing up, and copying an API key. Or, having to manually give consent to an app to consume an API on my behalf. Yes, API authorization has inherently been making humans a required part of the process. By doing that, it’s somehow been giving us the feeling that we’ve been in control. And we have, until now. So, what has changed? Well, now we have AI agents widespread, basically. If we want them to act on our behalf, they need to access APIs for us, don’t they? Some people noticed this as well and have been working on potential solutions. Let’s look at what’s available.
There is no generic solution to agentic authorization. Instead, there’s a spectrum of options that can give agents more or less autonomy during the API authorization process. The current contenders include the OAuth 2.0 Dynamic Client Registration Protocol, AAuth, Agent Auth, and x402. Let’s see what the pros and cons of each one are and what it would take you to implement them.
The OAuth 2.0 Dynamic Client Registration Protocol, or DCR, is the oldest of all the available options. RFC 7591, which defines it, was published in July 2015 after about three years of drafts and revisions. MCP itself proposes DCR as the preferred alternative to manual client registration. According to the MCP official documentation, “the client can use DCR to dynamically register itself with the authorization server.” Being the registration method suggested by the most popular AI tooling protocol is a big deal. But how does it work? In practice, DCR is quite simple and involves only one request. The client, in our case an AI agent, sends a Client Registration Request sharing metadata such as its own name, logo, contacts, scopes, and OAuth grant types. The server will then process the information and, if everything is correct, register the client. A successful response includes an OAuth client ID, an optional client secret, and expiration information. This information should be sufficient for the client to attempt to authorize users and then make service requests. This all sounds great because agents can register themselves. However, even with DCR, humans are still needed to provide specific authorization.
And that’s exactly why AAuth was created. The Agentic Authorization OAuth 2.1 Extension is an IETF draft that was first created in May 2025. It’s now in its version 01 and provides a solution where AI agents can identify their users and, in turn, use their identification to obtain OAuth access tokens. So, while DCR automates the registration of a new client, AAuth automates the process of obtaining authorization. How does it do that without introducing any loss in security? The authors of the draft thought of using a clever approach. In their view, agents can identify humans using Personally Identifiable Information, or PII. During the interaction between an agent and a human, the agent requests certain pieces of PII that it can then use to obtain an authorization. Examples of PII include obvious data like the user’s name, email address, and age, but also other domain-specific information, such as a credit card number, an IMEI number, and a medical record ID. The goal is that having those details about a user will be sufficient to provide a valid proof of identity. All these exchanges are done as part of the new Agent Authorization Grant that issues low-privilege, user-specific access tokens. The system can also escalate and ask for a human to intervene in situations where there’s a high risk potential. As you can see, even with AAuth, sometimes humans need to intervene. It’s hard for agents to be fully autonomous when obtaining an authorization.
Agent Auth, a recent proposal by Dick Hardt, one of the creators of OAuth 2.0, attempts to make agent authorization fully autonomous. By shifting to a protocol-driven identity model, this approach allows agents to prove their identity and obtain scoped permissions programmatically. How? Agents can progressively obtain a broad set of permissions from users. Initially, an agent can ask a few questions to a user to obtain an initial group of basic permissions. Over time, it can grow its permissions by asking more questions. Then, the agent can choose which permissions to use to be able to perform specific requests to specific services. The agent first makes a self-signed request. The service then asks the agent to provide any missing scopes. The agent makes a new request with all the required scopes. And, finally, the service generates a token and binds it to the agent’s public key. All subsequent requests will use the signed JWT with proof that the agent has the required permissions. What happens if there’s a required permission that the agent doesn’t have yet? In that situation, there’s an out-of-band, or OOB, interaction asking the user to authorize the operation. An example of an OOB interaction is an SMS message sent to a mobile phone asking for confirmation. It works in a way similar to payment authorizations, where the need for a manual approval depends on factors such as the risk of the operation.
Speaking of payments, let’s look at x402, the final contender in our original list at the top of the article. The idea behind x402 is that each API request is metered and can be exchanged for a specific monetary value. This is in contrast to the usual SaaS-style subscription plans, where you pay a monthly fee. The name x402 comes from the HTTP status code 402, which means that a payment is required to perform a request. How does it work in practice? Well, every time someone makes a request, the server replies with an HTTP 402 header with information such as the price of the request and its wallet address. The consumer then signs a “transfer authorization” locally with USDC and then makes the request again with the payment information. The server receives the payment information and uses a facilitator such as Coinbase to verify if the funds have been received. Behind the scenes, it uses the EIP-3009 standard, a cryptographic contract interface that enables transferring fungible assets via a signed authorization. And that would be it. If you notice, there’s no need to sign up to use the API, and you don’t even need an API key or a JWT token to perform requests. But, how would an agent know what operation it can consume on your behalf? x402 uses the concept of mandate to let humans define what operations the agent can access and how much it can spend on their behalf. Additionally, API servers can obtain proof of identity via attestations. These are cryptographically signed claims from trusted sources such as employee records and government-issued IDs.
All these options sound amazing. But are they already available to implement? Let's start with DCR. What you want is to implement a /register endpoint that will do the dynamic registration. Fortunately, you have different options depending on the programming language you pick. The Node.js oidc-provider module, for example, offers a standards-compliant DCR feature out of the box. If Python is your thing, you have the Django OAuth Toolkit, or DOT, and, if you prefer Go, there's the Ory Hydra headless OAuth 2.0 server. AAuth doesn't have that many options because it's still an IETF draft. However, the same Node.js and Go libraries can give you enough functionality. With Python, I'd use Authlib instead of DOT, though. Agent Auth open-source support is even smaller, unfortunately. The best approach is Solo.io's agentgateway, which, as the name implies, acts as a specialized ingress for AI agents and MCP. Finally, x402, which is now on version 2, has plenty of support. Take, for instance, x402/express for Node.js, x402[fastapi] for Python, or the x402 Go implementation from Coinbase. Here's a minimal example of an x402-protected resource that charges $0.01 USDC to anyone who wants to access it:
import express from 'express';
import { paymentMiddleware, x402ResourceServer } from '@x402/express';
import { ExactEvmScheme } from '@x402/evm/exact/server';
const app = express();
// 1. Set up the server logic to accept Base Sepolia (EVM)
const server = new x402ResourceServer()
.register('eip155:84532', new ExactEvmScheme());
// 2. Define the payment requirement
const routes = {
'GET /data': {
accepts: {
network: 'eip155:84532',
payTo: '0xYourWalletAddressHere',
price: '$0.01'
}
}
};
// 3. Apply middleware (uses the public x402.org facilitator by default)
app.use(paymentMiddleware(server, routes, { url: 'https://x402.org/facilitator' }));
app.get('/data', (req, res) => {
res.json({ info: 'Payment verified!' });
});
app.listen(3000);The implementation uses Base Sepolia, the official x402 test network for Base. It’s an Ethereum L2 blockchain developed by Coinbase. The middleware is responsible for verifying if there’s a valid payment before giving access to the protected /data resource.
What if writing code isn’t your thing? In that case, you can pick from existing commercial products. Let me suggest one vendor for each type of authorization so, at least, you have a starting point. For DCR, I recommend Auth0 because it offers one of the best Software Statement Assertions in the market. If AAuth is what you want, then I’d recommend Bitwave as they’re behind the IETF draft and have deep knowledge about the OAuth 2.1 plugin. Similarly, I’d recommend Hellō, the company founded by Dick Hardt, because they’re the ones behind Agent Auth. Finally, I’d recommend the Coinbase Developer Platform for implementing x402 because they provide the most robust facilitator. There are more solutions, but these seem to be the best for each particular authorization technology.
As you can see, adopting any of the four authorization technologies always comes with a cost. It doesn’t matter if you implement the solution yourself or buy it from a vendor. Also, the more experimental or bleeding-edge a technology is, the riskier it is to adopt. It’s natural that an unproven technology still has to go through changes. And, many of those changes will break existing solutions. If you jump in too early, you risk having to rebuild your whole solution many times. Also, pay attention to how widespread the technology is. You don’t want to adopt something that nobody uses, do you? Perhaps it’s better to stay with the existing technology instead of trying to remove humans from API the authorization process.
The final decision is yours. You’re the only one who can decide if you want to adopt one of the four open-source agentic authorization alternatives I share here. If you do, you’ll see the benefit of being able to remove humans from the loop. And if you don’t, I totally get you, as the risk of jumping in feels quite high now. In any case, I hope the information I share here helps you make your decision.
I like this framing of OAuth. The phrase "OAuth was built for people" is doing useful work. The missing layer for agents is not just consent, it is purpose-bounded execution. A token that can call an API should also carry the action class, expiry condition and evidence requirement for that specific run.
Good writeup Bruno. It is worth noting what ties all four together: they answer one question, can this agent get a token to call the API. Registration, consent, or payment, it is all authorization at the access boundary.
None of them touch the question that actually caused the headlines: once an agent is authorized, what is it allowed to do, and who approved this specific action. A correctly authenticated agent with a valid token is exactly what wiped a production database during a code freeze at Replit last year, after being told not to act without approval. Authorization was never the failure.
That gap has names now: OWASP LLM06 Excessive Agency, AISVS C14 Human Oversight, and Article 14 of the EU AI Act. They all point at the same missing layer,,execution-time control over what the agent does, not just access at the door. Graduated trust (the x-agent-trust idea) and a human approval on the risky few percent of actions sit in that layer, alongside these four, not instead of them.
Might be a good follow-up: agentic authorization gets the agent in; agentic authority decides what it can do or break once it is in.