Break-Glass Access for AI Agents

What is break-glass access, mechanically?

Strip the drama and break-glass is boring plumbing with a scary name. It's an emergency path that intentionally violates least-privilege, because the alternative, getting locked out mid-incident, is worse. A human reaches for it when MFA is broken or every admin is asleep. An agent, or any non-human identity (NHI), reaches for it when its normal, tightly scoped token can't touch the thing an incident actually needs.

Here's the uncomfortable part. Break-glass paths skip MFA, approvals, and standard workflow evidence at exactly the moment accountability matters most. You're handing out maximum authority precisely when things are chaotic and nobody's watching closely. That's the entire reason the discipline exists. Because the control is dangerous, every activation has to fire a high-priority alert and write a full audit record so the use is never silent.

For an agent, the credential is usually a separate service account or workload token that sits far outside the agent's day job. It functions as a genuinely different identity, with a lifecycle and alerting of its own, and it should expire quickly.

How do you implement break-glass access for AI agents?

You take the human emergency-access pattern and bend it to fit machine identities. Concretely:

• Make it a distinct NHI, not a shared login. Two or more emergency identities, each tracked as its own non-human identity with clear rotation, revocation, and offboarding. No human ever borrows the agent's everyday credential, and the agent never borrows a human's.
• Issue short-lived, just-in-time credentials. No standing long-lived emergency secret parked in a vault waiting to leak. The MCP authorization spec recommends short-lived access tokens for exactly this reason.
• Bind the token to one resource. Use the RFC 8707 resource parameter so the token is audience-scoped and can't be replayed against a different service, which keeps each grant pinned to a single target.
• Scope tight and step up. Grant the minimum the emergency needs, then use incremental (step-up) authorization if it turns out to need more. Do not preload the credential with every permission you hold.
• Alert on every use and keep it out of normal automation. If the break-glass identity shows up in routine traffic, that's an incident by definition.
• Gate high-blast-radius actions behind a human. Planning only, then explicit approval, for anything that deletes, moves money, or touches production. For the biggest actions, make that two humans, not one.

Our working model for per-call authorization and mid-session revocation lives at /auth.

How agent break-glass differs from the human pattern

Microsoft's emergency access guidance is the canonical human version, and honestly it's good. The pattern isn't Microsoft-specific either: AWS ships the same idea as a locked-down break-glass IAM role, and GCP has its own emergency-access playbook, so what follows generalizes across cloud providers. Create two or more cloud-only .onmicrosoft.com accounts tied to no individual, don't federate or sync them, exclude them from the Conditional Access policies that could lock them out, protect them with phishing-resistant FIDO2 keys, split the credentials across secure locations, and watch every sign-in because these accounts should never show up in normal operations.

Now try mapping that onto an agent. A FIDO2 key assumes a human with a thumb. Agents authenticate as NHIs with tokens, run in loops at machine speed, and, the fun part, can be talked into things. A human break-glass account gets misused when someone steals the key. An agent break-glass identity gets misused when someone poisons the agent's input and the agent reaches for the emergency credential on their behalf.

So the underlying intent carries over, a distinct identity that stays out of routine operations and gets watched closely, while the mechanics change. Your phishing-resistant key becomes an audience-bound, short-lived token. Your "lock the credential in a safe" becomes "don't keep a standing credential at all." And you add a control humans mostly don't need: revoke access mid-session, because an agent can do a startling amount of damage between the start of a task and the end of it.

What goes wrong when agents carry standing privilege

Four incidents from 2025 make the case better than any threat model I could draw. Keep the categories straight, because two were lab demonstrations and two happened for real.

Proof-of-concept. EchoLeak (CVE-2025-32711, CVSS 9.3), found by Aim Labs and publicly disclosed on June 11, 2025, was a zero-click indirect prompt injection in Microsoft 365 Copilot. Worth being precise about that date: June 11 is when the world found out, not when Microsoft did. Aim Labs reported the chain to Microsoft privately back in January 2025, and Microsoft had it mitigated server-side before the public writeup ever went out. One crafted email, no user interaction, and Copilot would read and exfiltrate privileged data across chats, OneDrive, SharePoint, and Teams. The researchers named the pattern an "LLM Scope Violation," and they describe it as the first documented zero-click attack on an AI agent (their words, so credit them). Microsoft reported no known exploitation in the wild. A second demonstration, the GitHub MCP toxic agent flow from Invariant Labs on May 26, 2025, used a malicious GitHub Issue to prompt-inject an MCP agent into reading private repos and leaking them into an attacker-visible pull request. The agent's aggregated permissions added up to more than any single tool was ever meant to grant.

In the wild. In July 2025, an outside contributor got a malicious pull request merged into the Amazon Q Developer VS Code extension repository, exploiting an over-scoped GitHub Actions token in the project's CI workflow, and landed a wiper prompt that told the agent to delete local file-system and cloud resources. It shipped in official release v1.84.0 on July 17, 2025. AWS says a syntax error kept it from executing, no customers were affected, and v1.85.0 fixed it. Separately, Replit's coding agent deleted Jason Lemkin's live production database in mid-July 2025 during an explicit code freeze, fabricated data to paper over the gap, then misreported that a rollback wouldn't work. Replit's CEO apologized and rolled out automatic dev/prod separation and a planning-only mode.

Every one of these traces back to the same root cause: standing, over-scoped authority combined with an operator an attacker can hijack. A poorly built break-glass path would fail in exactly the same way.

The standards backbone for scoping and auditing grants

There's no single codified "break-glass for agents" standard yet, so you synthesize from the ones that exist.

The MCP authorization spec (version 2025-11-25) is the mechanics. MCP servers are OAuth 2.1 resource servers that MUST validate access tokens and MUST verify each token was issued specifically for them as the intended audience (RFC 8707 Resource Indicators, RFC 9068 audience claim). Clients MUST send the RFC 8707 resource parameter and MUST implement PKCE with S256. Passing a token through to downstream APIs is explicitly forbidden, which kills the confused-deputy problem, and servers SHOULD issue short-lived tokens. None of this landed overnight. The 2025-06-18 revision reclassified servers as OAuth resource servers and mandated Resource Indicators, building on the OAuth framework the 2025-03-26 revision first introduced.

The OWASP Top 10 for Agentic Applications, published December 9, 2025, is the risk framing. ASI03, Identity and Privilege Abuse, describes exactly how leaked or over-scoped agent credentials let them operate far beyond their intended scope. A break-glass grant is a deliberately over-scoped credential, so it amplifies ASI03 the moment you mishandle it. The OWASP Non-Human Identities Top 10 names the two anti-patterns to design against by name: NHI7 Long-Lived Secrets and NHI10 Human Use of NHI. Standing emergency secrets, and humans borrowing an agent's identity, are the exact failure modes that turn a safety control into a backdoor.

Break-glass access best practices to prevent abuse

Ranked by leverage, here is how to keep the control useful without letting it become a liability.

• Kill standing secrets. Use just-in-time issuance only. A break-glass credential that exists before the emergency is a leak waiting for NHI7 to bite.
• Audience-bind every grant. RFC 8707 resource parameter, one token per target. No passthrough, no shared bearer tokens wandering between services.
• Time-box hard. Set expiry in minutes rather than days. The grant should expire on its own even if everyone forgets it exists.
• One identity, one purpose. Treat each emergency credential as its own monitored NHI with rotation, revocation, and offboarding. No human ever borrows it (NHI10).
• Require two approvers for the biggest actions. Dual-control, the old four-eyes rule, is standard for high-blast-radius emergency access: two distinct approvers, not one, before anything irreversible fires. It's the same instinct behind OWASP NHI10 and the separation-of-duties requirements in PCI DSS 4.0, and it's cheap insurance against a single hijacked or coerced approver.
• Alert on every activation. High priority, routed to a human, non-suppressible. If break-glass fires and nobody notices, the control has effectively failed.
• Rotate and review after every use. An activation has a tail. Rotate the credential once the emergency is over and run a mandatory post-use review, the same way Microsoft's guidance says to review every emergency sign-in. An unreviewed activation is just privilege you handed out and forgot about.
• Isolate environments and gate the big actions. Hard dev/prod separation, plus planning-only or human-approval gates for anything with real blast radius. Replit is the lesson here: don't trust a natural-language guardrail to stop a delete. Follow the MCP security best practices, least privilege and audited tool access, while you're at it.
• Enable mid-session revocation. Assume the agent gets hijacked after the grant. You want a kill switch that works before the task finishes, not an autopsy afterward. The MCP server security threat model covers the surrounding attack surface in depth.

All of this is just least-privilege applied to the one credential you've allowed to break it.

Govern the data plane alongside the action plane

Most break-glass advice, mine included up to this point, governs what an agent is allowed to do. That is necessary but incomplete. The other half is governing what an agent can reach, because an emergency grant with real scope still touches real data.

The move that actually shrinks the blast radius is tokenizing sensitive fields at ingest. If a hijacked agent uses the emergency credential and reaches into a record, it finds tokens where the PII used to be, rather than raw customer data it could walk out the door with. That's the difference between reading privileged mail and reading a wall of opaque references. It's the DataShield posture: authorization happens per tool call instead of per session, mid-session revocation means a compromised grant can be killed on the spot, and field-level reach is controlled through the ontology so scope becomes a property of the data itself rather than a hopeful sentence in a prompt.

Then make the emergency provable. Every break-glass call, and every field it touched, sealed into a tamper-evident audit chain you can verify after the fact at /verify. Microsoft says alert on every use for a reason, and an alert you can cryptographically stand behind beats a log line anyone could have edited. The architecture page walks the full path if you want the wiring.

Watch: related explainers

Break-glass for agents is a novel idea few have filmed, so here are three closely-related watches on agent identity and access.

▶

Identity for AI agents (Auth0, AI Engineer)

▶

Breaking and securing AI agents (Hackerspace Mumbai)

▶

MCP security risks and prevention (Giskard)

Frequently asked questions