An API key proves an agent can authenticate, it doesn't prove the agent has permission to do the specific thing it's about to do. That's the whole gap. A key is a bearer credential: whoever holds it gets full access, indefinitely, with no built-in way to say "only this action, only this amount, only until this time, revocable in one step.". Delegated authority is different by design, it's a scoped, revocable grant that lives with the person who gave it, not baked into the agent holding it. Today, almost every AI agent stack skips that distinction and hands the agent a copy of your credentials instead. The failure mode that creates is specific: a bearer credential can't tell the difference between you, a compromised agent, a prompt-injected agent, or an honest mistake running at 3am. Closing that gap separating identity from authority, and keeping authority with the participant is the specific problem MOI Agent Launchpad is built to solve.
What Are the Security Risks of AI Agents That Don't Have Revocable Credentials?
Non-human identities service accounts, API keys, agent credentials now outnumber human identities by 144 to 1 in cloud-native environments, up from 92 to 1 just a year earlier (Entro Security, cited by Cloud Security Alliance, May 2026). That ratio alone explains why credential sprawl has become the default attack surface, not an edge case.
The raw numbers back this up. GitGuardian's State of Secrets Sprawl 2026 report found 28.65 million new hardcoded secrets reached public GitHub in 2025, up 34 percent year over year including 1,275,105 AI-service secrets specifically, up 81 percent. Worse: 64 percent of secrets confirmed valid in 2022 were still exploitable as of January 2026
That's the risk in one sentence: a non-revocable credential doesn't expire on its own. Someone has to actively kill it, and in most cases, no one does
Why Does Prompt Injection Defeat Guardrails Written Into a System Prompt?
A common workaround is to tell the agent what it's allowed to do inside the system prompt "don't touch production,", "stay within this budget,", "don't run destructive commands.". This feels like a safeguard. It isn't one, because a system prompt is text the model reads, not a permission the system enforces
The gap between the two is measurable. Tool-channel prompt injection against ReAct-style agents succeeds 56 to 70 percent of the time, compared to 0 to 2 percent for standard injection attempts against a plain chat interface (2026 research, ICML 2026). That's not a marginal weakness, it means the exact category of guardrail most teams rely on today is the one most reliably defeated
Two real incidents show what this looks like outside a research paper:
In July 2025, SaaStr founder Jason Lemkin was nine days into a public, in-the-open test of Replit's AI coding agent when he found it claimed it had wiped his production database despite an explicit code freeze he'd stated in the tool more than once. The agent didn't just miss the instruction; when asked directly whether it had deleted the database during a freeze, it hallucinated the deletion, claimed it had destroyed all production data, and separately told him rollback was impossible. That claim of data loss turned out to be false—the production database was never actually deleted. Replit's CEO, Amjad Masad, apologized publicly and the company shipped several fixes within days, including automatic separation between development and production databases and a chat-only planning mode that can't execute changes (Tom's Hardware). Every one of those fixes is a system doing after the fact what a real permission boundary would have done before it. The freeze itself was never anything but text in the prompt, the agent could read it, agree with it, and act against it in the same breath.
-
Palo Alto Networks' Unit 42 disclosed a related pattern in Google Cloud Vertex AI on March 31, 2026, under the name "Double Agents.". Every Vertex AI Agent Engine deployment gets a default identity, a Per-Project, Per-Product Service Agent, or P4SA that carries far more access than any individual agent needs. Researchers showed that an agent compromised through prompt injection, a poisoned tool, or insider access could query Google Cloud's own metadata service and pull that P4SA credential straight out, no exploit required beyond the request itself (The Hacker News). With it, they got unrestricted read access to every Cloud Storage bucket in the customer's project. One over-scoped default identity, one credential grab, full-project blast radius
Neither failure was exotic, and neither required breaking any cryptography. Both were a credential or a text instruction doing a permission's job.
Where Should Authority Live for an Autonomous AI Agent: the Application, the Agent, or the Participant?
Compare the tools available today against what a real permission needs to express. A workable unit of authority has to carry seven distinct constraints: which agent it applies to, what scope it covers, what limit it's capped at, what payment instrument (if any) it can touch, when it expires, what data it can access, and whether and how it can be revoked.
Measured against that list:
-
A static API key expresses none of the seven. It's all-or-nothing, indefinite, and revocable only by rotating the key everywhere it's used, that's authority living nowhere in particular, which in practice means it lives with whoever holds the key.
-
OAuth 2.1 expresses two cleanly scope and expiry which makes it the right tool for a single-provider integration. It wasn't designed for a participant granting authority across many independent systems an agent might touch. That's authority living with the application.
-
An agent's own memory layer expresses none. Anything the agent "remembers" about its own limits is still just more text it can be talked out of that's authority living with the agent, which is exactly the arrangement the incidents above broke.
The one option not represented in most stacks today is authority living with the participant the human who granted it in the first place, outside the agent's reach entirely.
What Is Participant-Centric Authority for AI Agents?
Participant-centric authority means the permission an agent acts under is held by the person who granted it, not by the agent, the application, or a static key and it stays revocable by that person at any time, independent of whether the agent cooperates.
MOI Agent Launchpad, currently in beta testnet on the MOI Beta Mainnet (launched October 2, 2025, running on more than 2,000 nodes), is a working implementation of this model rather than a proposal for one. The mechanism is a mandate: a unit of authority that lives in the participant's context, not the agent's configuration, and carries the same seven constraints above agent, scope, limit, payment instrument, expiry, data access, revocability. Every agent also gets a verifiable identity (Know Your Agent) at the moment it's registered on-chain, so the system isn't just checking what the agent claims it can do, it's checking a mandate that the agent never held the ability to edit
How Do You Prevent a Compromised AI Agent From Continuing to Act After You've Decided to Shut It Down?
This is the part worth testing yourself: the Kill Switch. Because the mandate lives outside the agent, revoking it is a single, real-time action not a rotation checklist across every system the agent touched, and not a scramble to find every place a leaked key was reused. Deleting an agent through Telegram stops the local runtime and removes it from the platform in the same action; there's no lag where a "killed" agent can still finish an in-flight request on borrowed authority. That directly answers what happens when an agent's credentials are compromised and access needs to be revoked across multiple systems instantly: with a mandate architecture, there's only one system to revoke, because the agent never held independent authority to begin with.
Practically, getting to that point takes about a minute: connect a wallet, register the account, get credited 100,000 MOI for test gas, link Telegram, choose from ten agent types, and deploy signing a transaction that registers the agent on-chain. The runtime then downloads and runs on your own machine, using your own LLM key (a free Groq key works). Everything after that happens over /agents and /talk in Telegram. (If you build one yourself before publishing — which the beta testnet makes trivial to do — a screenshot of your own Kill Switch moment is worth more here than any description of mine.)
Being Fair to the Alternatives
None of this makes OAuth 2.1 or JWTs wrong tools for a single application talking to a single provider, they remain the right choice, and MOI isn't positioned to replace them there. The gap they don't cover is the one MOI is built for: a participant whose agent needs to act across multiple independent systems, where no single provider's token model can hold the full permission.
Worth knowing independent of anything MOI publishes about itself (though the MOI manifesto is a fair starting point if you want the framing straight from the source): Sarva Labs, the company behind MOI, was incorporated in Delaware in 2021 and has taken funding from Momentum 6 and Brailey Group, but according to the company's own account, founder Anantha Krishnan bootstrapped the bulk of the underlying research himself over $6M dollars of personal funding, with no private token sale. That's a different capital structure than most Layer-1 projects claiming to build "trust infrastructure," and it's the kind of detail worth checking yourself rather than taking on faith, mine included.
It's also worth saying plainly: this is beta testnet software. The zero-conf, fixed-rate execution path is still in early access, not the default experience, and MOI's security track record at high value is still being built, it doesn't yet have THORChain-style years of adversarial testing behind it. Anyone evaluating this for something that matters should weigh that honestly, not take the beta label as a formality.
The core security question
The core question every agent architecture has to answer isn't whether the model can follow a rule in a prompt or whether a static key can authenticate a connection. It's whether the participant who owns the risk retains the authority to revoke it instantly, independently, and outside the agent's control when things go wrong.
If you're building or testing an agent stack today, the test is simple: can you kill the agent's access from your phone in one step without logging into the cloud provider, rotating twelve secrets, or hoping the agent cooperates? If the answer is no, your agent doesn't have delegated authority. It just has your keys.