Static API Keys vs OAuth vs JWT vs Scoped Mandates: Where Should AI Agent Authority Live?

Why I wrote this: the question that broke my default answer

For most of my career, the answer to “how should this service authenticate?” has been reflexive. Server-to-server? API key in a header. Third-party access to a user account? OAuth. Internal microservice? JWT. That mental model has served me well.

Then, over the last twelve months, I started shipping autonomous agents — LangChain-style ReAct loops, browser agents, Telegram bots wired into LLMs. And the mental model started to leak. The agents were reading my email, hitting my Stripe, calling internal admin endpoints. Every credential I handed them was still, technically, my credential. If the model got prompt-injected, the credential moved. If the vendor got breached, the credential moved. And I had no way, sitting at my desk, to say “stop that specific action, right now, in flight.”

What I discovered is that four categories of solution — static API keys, OAuth 2.1, JWT, and participant-held scoped mandates — solve subtly different problems, and the AI agent wave has finally pushed the fourth into being genuinely necessary. This is my attempt to compare them fairly, explain why a credential is not authority, and share what I saw when I actually built an agent on the MOI Network Agent Launchpad.

1. The problem with giving AI agents credentials

Every mainstream auth mechanism assumes the thing holding the secret is either (a) a human who understands consequences, or (b) a piece of software you wrote and control. AI agents are neither. They are stochastic decision-makers, driven by natural-language input, and any string in their context window can influence what they do next. That is a categorical break with the assumptions baked into API keys, OAuth, and JWT.

Consider the practical failure modes:

• API keys are long-lived, high-entropy secrets with no built-in scope beyond what the issuing provider lets you configure. If the agent leaks one — via logs, a compromised vector store, or a screenshot uploaded for debugging — the attacker gets what you got.
• OAuth access tokens are short-lived, but the refresh tokens behind them are not. And OAuth scopes are defined by the resource server, not by you. If the only scope Gmail exposes is gmail.modify, that is what your agent gets — even if you only wanted it to draft a single reply.
• JWTs are self-contained claims. The instant they are minted, they are fossilised. Revocation in a JWT world is famously hard, which is why most implementations settle for short TTLs and pray.
• Bearer credentials in general assume that whoever presents the token is entitled to the underlying authority. That is the exact assumption that breaks when the “whoever” is a model executing tool calls suggested by a webpage it just fetched.

Add to this the prompt injection problem. Recent red-teaming research on ReAct-style agents suggests tool-channel prompt injection succeeds at somewhere between 56% and 70% under adversarial conditions. In other words: the agent’s decision to use its credential can be hijacked by the very data it is asked to process.

And the ambient statistics are grim. According to industry security reports on non-human identity sprawl, non-human identities now outnumber humans 144:1 in cloud-native environments. 28.65 million new hardcoded secrets reached public GitHub during 2025 alone, of which 1,275,105 were AI-service secrets. Perhaps most damning: 64% of secrets confirmed valid in 2022 were still exploitable in January 2026. Credentials, once out, tend to stay out.

2. What does “authority” actually mean?

Three words get conflated in almost every agent-security conversation. Untangling them is the whole game.

Authentication and authorization are properties of a system: they tell the system whether to accept a request. Authority is a property of a relationship between a participant and an agent: it tells the world what the agent is permitted to do on someone’s behalf, and it can change the moment the participant changes their mind.

The MOI cornerstone essay puts it in a way that stuck with me: a credential is information; authority is value. Information can be copied at zero cost — that is what defines it. Value cannot fork or silently vanish; if two copies exist, one is counterfeit. The reason API keys, OAuth tokens, and JWTs feel wrong for autonomous agents is that they behave like information (freely copyable, freely cached, freely presented) while we want them to behave like value (existing in exactly one place, changing the instant we change our minds).

“A credential is a snapshot of intent taken at issuance. Authority is the intent itself, still live, still yours.” — my paraphrase after reading the MOI mandate essay.

3. Static API keys

How they work

A static API key is a long-lived opaque string, generated by the provider, presented in an Authorization header or query parameter. The provider looks it up against an internal record and either accepts or rejects the request.

Where they’re appropriate

• Machine-to-machine, single provider, with IP allow-listing.
• Read-only integrations where blast radius is bounded (a weather API, a market-data feed).
• Development/testing, where rotation is cheap and no user data is at stake.

Where they break for agents

• No per-action scoping. The key can do everything the account can do.
• Revocation is coarse — you kill the key and hope nothing legitimate was mid-flight.
• No expiry unless you build a rotation pipeline yourself.
• Multi-system: you end up with N keys the agent must juggle, each with independent blast radius.

4. OAuth 2.1

OAuth 2.1 is the current consolidated draft that folds in a decade of security lessons from OAuth 2.0 (mandatory PKCE, no implicit flow, no password grant, tighter redirect URIs). It solves a very specific problem beautifully: letting a third-party app act on a user’s behalf against a specific resource server, without ever seeing the user’s password.

What OAuth gets right for agents

• Delegated access with user consent at issuance.
• Access tokens are short-lived (minutes to hours).
• Scopes let the resource server carve up permissions.
• PKCE closes the code-interception gap for public clients.

Where OAuth stops being enough

• Scopes are provider-defined. If Google or Slack ships a scope that reads all your DMs, you cannot ask for “only DMs with vendor@example.com in October.” You get the shape the provider chose.
• Refresh tokens are long-lived credentials in disguise. Steal one and you have durable access.
• Cross-provider composition is your problem. An agent that touches Gmail, GitHub, and Stripe holds three unrelated OAuth relationships with three unrelated consent surfaces.
• Revocation is asynchronous. Access tokens keep working until they expire, even if you revoked the grant thirty seconds ago.

None of that makes OAuth wrong. In the specific case of “my agent needs to draft replies in my Gmail,” OAuth is still the correct answer, and I would not recommend replacing it. It’s when the agent is orchestrating across systems and moving value that OAuth’s single-provider frame starts to strain.

5. JWT (JSON Web Tokens)

Defined in RFC 7519, JWTs are compact, URL-safe, cryptographically signed claim sets. In an agent context they usually show up as the actual access token OAuth hands you, or as the internal service-to-service token in a mesh.

Strengths

• Self-contained. The resource server can validate the token without a round-trip to an auth server.
• Cryptographic integrity. Tampering is detectable.
• Structured claims. You can pack sub, aud, scope, exp, custom claims — all machine-readable.

Limitations for autonomous agents

• Revocation is essentially unsolved without introducing a check-in step, which negates the point of stateless tokens.
• The token is a snapshot. If your mandate changes at 14:00, a JWT minted at 13:59 with a 15-minute TTL keeps working with the old mandate.
• Any claim structure is your convention. There is no widespread standard for “this agent may spend up to $X on instrument Y through date Z, and here is the participant’s current revocation state.”
• Prompt-injection compatibility: the JWT is a string in the agent’s memory. Once exfiltrated, it works anywhere until exp.

6. Participant-held mandates (the MOI approach)

The fourth approach flips the ownership question. Instead of the agent holding a credential the participant issued, the participant retains the authority and the agent carries only a witness that its next action is currently valid. This is what MOI calls participant-centric authority, and it maps onto seven live constraints that together define a scoped mandate.

The seven constraints of an MOI mandate

1. Agent — which specific agent identity is bound to this mandate. Not “any bearer,” one named agent.
2. Scope — the class of actions permitted (e.g. “send email,” “transfer stablecoin”). Not the union of everything the underlying account can do.
3. Limit — a value ceiling for actions that move value. Once hit, the mandate stops accepting more.
4. Payment instrument — which specific account, card, or wallet the agent may draw on. Not “all my instruments.”
5. Expiry — a hard time bound after which the mandate lapses without any need to revoke.
6. Data access — read limits on sensitive fields (how many times, which fields).
7. Revocability — the participant can withdraw the mandate instantly, and in-flight actions become invalid.

(MOI’s own long-form article actually enumerates eight properties, splitting out “bounded sub-delegation” — the ability for a spawned sub-agent to receive a provably narrower slice — as a separate item. For the four-approach comparison in this article I fold that into the scope/limit dimension, but if you are designing multi-agent orchestration, treat sub-delegation as a first-class concern.)

The key move here is architectural, not cryptographic. The mandate is not a token the agent carries around and presents. It is a stateful relationship that lives with the participant and is checked at execution. The agent’s claim to authority is only ever valid against the participant’s current state. If you revoke, the witness stops verifying. That is why MOI describes the mandate as behaving like value rather than information.

7. The head-to-head comparison

Here is the comparison I wish someone had handed me when I started shipping agents:

The honest reading of this table: the first three columns are excellent at what they were designed for. They were designed for human-driven or predictable-machine access to specific systems. The fourth column exists because autonomous, cross-system, value-moving agents are a new shape of client, and none of the first three were designed with that client in mind.

8. I built an MOI Agent Launchpad agent

Reading essays is one thing; deploying is another. Here is what I actually did during MOI’s beta testnet (September 2026).

What MOI Agent Launchpad is

The Agent Launchpad is a hosted flow inside the MOI ecosystem that lets you configure an AI agent, bind it to a participant-held mandate, and run it against a local runtime you download to your own machine. During beta it is free to use. New accounts receive 100,000 MOI for test gas. The Launchpad exposes 10 agent types at the time of writing, and control happens over Telegram via commands like /agents (list your agents) and /talk 1 (send instructions to agent #1).

Important framing before I go further: MOI is an identity and authority layer for AI agents. It is not a general-purpose smart-contract platform, and I am not comparing it to Ethereum or Solana anywhere in this article, because that is not the axis it competes on. MOI Beta Mainnet launched 2 October 2025 and runs on more than 2,000 nodes. Agent Launchpad specifically is still in beta testnet.

My setup

• Agent type chosen: [INSERT AGENT TYPE]
• LLM provider: [INSERT LLM PROVIDER] (I supplied my own API key — MOI does not proxy this)
• Runtime host: local machine, macOS/Linux [INSERT MY OS/HW]
• Control surface: Telegram

Deployment experience

[INSERT MY OBSERVATION on how long deployment took, whether the runtime installed cleanly, and any prompts encountered]

The Telegram control loop

[INSERT MY OBSERVATION on latency, quality of responses, and how the agent behaved when I asked it to do something outside its scope]

Kill Switch / revocation test

This is the part I wanted to see with my own eyes, because it is the whole thesis of participant-held authority. I deleted the agent from my account mid-task.

Per the campaign documentation, deleting an agent stops the local runtime and removes it from Telegram — the authority relationship ends and the compute is no longer permitted to run on my behalf. [INSERT MY OBSERVATION on how instantly this happened and whether any in-flight action survived]

9. MOI vs Nava: prevention vs interception

The most common question I got when I started writing this piece was “isn’t this the same thing as Nava?” The short answer is no, and the difference is actually the most useful mental model in the whole agent-safety space right now.

These are complementary. If you only prevent (MOI-style) and never intercept, an agent that stays technically inside its mandate but does something contextually weird can still cause harm. If you only intercept (Nava-style) and never constrain up front, you are relying on runtime checks to catch every possible misuse — a much larger surface. A production-serious deployment probably wants both: a tight mandate at the authority layer, and interception at execution for the anomalies that a static mandate cannot foresee.

I don’t think of Nava as a competitor. I think of it as the runtime cousin of what MOI does at the mandate layer.

10. What about Lit Protocol, Kite AI, DIDs, and KYA-OS?

The identity-for-agents space in 2026 is crowded, and it’s tempting to reduce every new project to “an MOI alternative.” That framing loses information. Most of these are adjacent infrastructure, not head-to-head substitutes.

• Lit Protocol — programmable, distributed key management. Useful for holding an agent’s key material in a way no single node can extract. Complements a mandate model by giving the agent a hardened key custody story.
• Kite AI — agent-focused chain with payments and identity primitives. Overlaps with MOI in the “agent-native infrastructure” frame, but their emphasis on payment rails vs. authority mandates is different enough that they can coexist.
• KYA-OS (“Know Your Agent”) — reputation and provenance for agent identities. Answers “who is this agent, historically?” rather than “what may this agent do right now?”
• W3C DID Core and the Decentralized Identity Foundation — the underlying identifier and verifiable-credential standards a lot of the above sit on top of. DIDs are the plumbing; mandates are the semantics you attach to them.
• Nanda — MIT-originated project on agent networks, more research-flavored, useful reading if you care about how agents discover and negotiate with each other.
• mem0 — long-term memory for agents. Orthogonal to authority, but relevant because “what the agent remembers about you” is often the thing that should be constrained.

The pattern I see: DIDs + verifiable credentials give you identity; Lit and hardware TEEs give you custody; MOI-style mandates give you authority; Nava-style interception gives you runtime enforcement; KYA-OS gives you reputation. Real-world deployments will stack several of these, not pick one.

11. Agent frameworks: where any of this actually plugs in

The auth mechanism is downstream of the framework you’re building on. If you’re shopping frameworks, these reviews cover the ones I refer to most in this space:

12. What MOI doesn’t solve yet

This is a Beta Testnet. Anyone telling you it is production-ready is selling something. Honest limitations:

• It’s beta. The mainnet launched in October 2025 and runs on 2,000+ nodes, but Agent Launchpad specifically is still in beta testnet. Expect breakage.
• Ecosystem gravity. None of the SaaS providers your agent actually talks to natively understand MOI mandates today. In practice you still translate a mandate into whatever downstream credential the target system expects. That is a real engineering surface.
• 10 agent types is a starting menu, not a universe. If your use case doesn’t fit, you’re either bending it to fit or waiting.
• Local runtime. Running the runtime on your own machine is the right architectural choice — but it’s also more setup than “paste an API key.”
• Documentation gaps. [INSERT MY OBSERVATION on which parts of docs I bounced off]
• Nothing here fixes prompt injection at the model layer. A tight mandate limits blast radius; it does not make the underlying LLM immune to being talked into misusing what authority it does have. That is why MOI is complementary to, not a replacement for, runtime interception approaches like Nava.

13. My verdict, by situation

Frequently asked questions

Is OAuth 2.1 obsolete for AI agents?

No. For single-provider delegated access on behalf of a specific human user, OAuth 2.1 is still the right tool. It becomes insufficient — not wrong — when the agent starts spanning systems, moving value autonomously, or needing revocation that beats the token TTL.

Can I use JWT to express a participant-held mandate?

You can use JWT as the encoding, but the mandate itself has to live somewhere the participant controls in real time. A JWT alone is a snapshot; a mandate is a live relationship. You will end up needing an out-of-band check, which is exactly what MOI’s architecture provides.

Is MOI a blockchain?

MOI is a base protocol with an on-chain participant layer. It is deliberately not framed as a general-purpose smart-contract platform. If your mental map is “blockchain = Ethereum-alike,” you will misread it. Think of it as an identity and authority substrate.

Do I need MOI to build a safer agent today?

Not necessarily. You can move a long way with tight OAuth scopes, short-lived JWTs, per-action approval gates, and Nava-style runtime interception. MOI becomes compelling specifically when you want participant-held authority as a first-class property — and when you want it to travel across systems.

Does the seven-part mandate stop prompt injection?

It doesn’t stop the injection; it limits what a successful injection can accomplish. That is a meaningful and specific improvement, not a silver bullet. Combine with runtime interception for defence in depth.

Conclusion: credential is not authority

If I could hand my past self one sentence before I started shipping autonomous agents, it would be this: a credential tells a system who or what is presenting access; authority defines what an agent is actually allowed to do on your behalf — and only one of those two things is still under your control after issuance.

Static API keys, OAuth 2.1, and JWT are three excellent answers to the credential question. They will remain load-bearing infrastructure for a long time, and I am not suggesting anyone rip them out. But they do not, on their own, answer the authority question — and the authority question is exactly the one that autonomous agents force you to answer. Participant-held mandates, as implemented in MOI’s Agent Launchpad, are the first mainstream attempt I have used that treats authority as a live relationship rather than a copyable string. Whether that becomes the default for agent authority in the next few years depends less on any single project and more on whether the ecosystem finally accepts that agents are a new shape of client, and that the auth mechanisms we designed for humans and predictable machines were never asked to carry this weight.

Build the mandate. Keep the credential. Layer the interception. That is the stack.