Been building agents that touch multiple services and eventually hit the same wall a lot of people building this stuff seem to hit: your agent authenticates fine, has a valid key/token, and none of that tells you whether the specific action it just took should have been allowed.

Broke it down into the 4 approaches people actually use and scored them against 7 things any permission scheme needs to answer which agent, what scope, what limit, which payment instrument, until when, what data access, and can you revoke it:

**Static API key**: anwers none of the 7. It's a bearer secret. Whoever has it can do whatever the key can do, indefinitely, and the receiving service can't tell your agent apart from a leaked copy of the same key. GitGuardian's 2026 report had 28.65M new hardcoded secrets hitting public GitHub in 2025 (+34% YoY), and 64% of secrets that were valid in 2022 were still exploitable as of Jan 2026. People don't rotate these.

**OAuth 2.1**: actually or scope + expiry. If your agent talks to one provider, this is still the right call, don't overthink it. Falls apart once you need spend limits or payment-instrument binding (not in the spec), and revocation means going into that one provider's dashboard does nothing for the other 4 services the same agent touches.

**JWT**: thinner than OAuth on its own. It's a signed claim, not a permission system. Revocation is the classic problem: valid until expiry unless you're maintaining your own blocklist. Doesn't natively express spend limits or data-access boundaries either.

Participant-held mandate this is the model I found more interesting while researching MOI network) the key reframe is: authority doesn't live in the agent's config or the app it's calling, it lives with the person, as an explicit object with all 7 fields filled in. Deleting the agent kills the local runtime and pulls its access in the same action not 5 separate revocations across 5 dashboards.

Why this isn't academic:

- **Replit, July 2025** — an agent deleted a production DB (1,206 execs, 1,196+ companies worth of data) during an explicit code freeze. The freeze only existed as a prompt instruction. Never became an actual permission constraint.
- **Unit 42, March 2026** — one over-privileged, compromised Vertex AI agent could read every Cloud Storage bucket in a project.
- **ICML 2026 research** — injecting instructions through a tool's output (not the user prompt) beat ReAct-style agents 56-70% of the time vs 0-2% for standard prompt injection. A guardrail written into a system prompt is a request, not a control, because it lives in the same channel that gets manipulated.

Also worth being precise about: DIDs / verifiable credentials answer "what IS this agent" identity. A mandate answers "what's it allowed to do" authority. You can have a perfectly verified agent identity that still holds completely unscoped permissions. Different layers, people conflate them a lot.

Not saying rip out OAuth for a single-provider agent it's still fine and simpler. This is specifically about agents that span systems, handle money, or run autonomous enough that you can't manually catch a bad action before it executes.

Curious what others here are actually using in production for this genuinely asking, not just here to plug something.

Static API key vs OAuth vs JWT vs a scoped mandate for agent permissions which are you actually using?