AI agent token hijack exposes the limits of vaulting alone

Editorial analysis by NHI Mgmt Group, based on content published by Unosecur: “Meta Vaulted Muse's Credentials. The Zero-Day Handed Over to the Agent Instead”.

At a glance

What this is: This is an analysis of a Meta Muse zero-day that let a local process steal the agent token and inherit the agent's granted authority.

Why it matters: It matters because IAM and NHI programmes cannot rely on vaulting alone when an agent's real risk sits in the session and its tool-call authority.

👉 Read Unosecur's analysis of the Meta Muse zero-day and agent token hijack

Context

AI agent identity security breaks when teams treat the vault as the boundary instead of the runtime session. In this case, the secret stayed protected while the token that governed the agent's authority was exposed through the client.

For identity programmes, the issue is not only secret storage. It is whether the system can still govern what an already-authorised agent does after a local process or malware captures the token that represents that authority.

The result is a familiar control gap with a new shape. Governance can look intact in the vault and still fail at the exact point where the agent executes actions on behalf of a user.

Key questions

Q: How should teams handle AI agent tokens when a client or local process can hijack the session?

A: Treat the token as a live authority object, not just a stored secret. If a local bug or malware can redirect traffic, assume the attacker can inherit the agent's permissions and act as the user. Restrict the token's reach, bind it to the narrowest possible action set, and revoke any session that shows unexpected endpoint redirection.

Q: Why do vaults not stop AI agent compromise when the session itself is hijacked?

A: Because vaults protect where the secret sits, not what the secret can do once it is in an active session. If an attacker captures the token after the agent is authorised, the attacker inherits standing access across every service that token can reach. The control question is therefore execution-time authority, not secret storage alone.

Q: What are the signs that an AI agent's supporting services are part of the attack surface?

A: Look for helper components that handle token transit, sensitive context, or redirectable endpoints, especially transcription, telemetry, and cloud routing services. If a non-obvious service can influence where credentials go or what data the agent emits, it belongs in the agent identity boundary. Hidden support paths often explain why a clean vault still leaves a usable attack path.

Q: What should security teams do after an AI agent token is exposed or redirected?

A: Immediately assume the agent's standing authority is compromised and review every service the token could reach. Revoke the session, rotate the affected credentials, inspect tool-call history for abnormal actions, and validate whether any helper service redirected traffic or stored copied credentials. Containment has to start before the agent completes another tool call.

Technical breakdown

How a local client bug becomes token theft

The Muse flaw sat in the macOS client, where an unprivileged process could rewrite undocumented local settings. One setting controlled the endpoint used for cloud transcription, so traffic and the account token could be redirected to an attacker-controlled server. That matters because the token authenticates the agent account, not merely a single request. Once stolen, it can be replayed against the agent's services and the systems the agent was already trusted to use. In effect, the client bug did not break the vault. It bypassed the place where the token was handed into the runtime.

Practical implication: protect agent tokens at the handoff point, not only in storage.

Why vaulting does not contain a hijacked agent session

Vaulting secrets outside the runtime is useful, but it only protects the secret at rest and during retrieval. If an attacker can capture the token after the agent is cleared to act, the attacker inherits the authority already attached to that session. That authority can include email, purchases, file writes, phone lookup and other tool-enabled actions. The key failure mode is that the token is not the risk by itself. The risk is the authority the token unlocks once the session is live and the agent is operating with standing access.

Practical implication: govern tool invocation and session authority, not just secret custody.

How supporting services widen the attack surface

The article shows that transcription was not a neutral utility. It became part of the attack path because the agent's supporting services handled sensitive data and token transit. For AI agents, every helper service that touches prompts, outputs, or credentials becomes part of the security boundary. That widens the identity model beyond the headline application and into adjacent services few teams classify as sensitive. In agent deployments, the control problem is often not the obvious tool, but the overlooked side channel that lets an attacker redirect trust.

Practical implication: inventory supporting services as part of the agent identity surface.

Threat narrative

Attacker objective: The attacker aims to inherit the agent's standing authority and use it to perform actions as the legitimate user across the services the agent can reach.

1. Entry occurred through a local macOS client flaw that let a process running as the user rewrite undocumented settings and redirect traffic.
2. Credential access followed when the redirected transcription flow exposed the agent token to an attacker-controlled server.
3. Escalation happened when the stolen token let the attacker act as the agent with the privileges already granted to the account.
4. Impact included file writes, photography, Bluetooth scanning and access to the services the agent could use on the user's behalf.

Breaches seen in the wild

• Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Vaulting is not the control boundary for AI agent identity. The secret can remain protected while the authority tied to that secret is still exploitable in the live session. That is why the real governance problem is not storage hygiene alone, but whether the runtime can still enforce who or what acts after a token is issued. For practitioners, the control boundary has moved from the vault to the session.

Access review assumes a stable grant; autonomous execution collapses that assumption. The review model was designed for access that exists long enough to be listed, recertified, and revoked. When an agent can obtain, use, and discard authority in the span of a session, the review artefact arrives too late to matter. The implication is that identity governance must reason about action-time authority, not only standing entitlements.

Helper services are now part of the identity trust chain. Transcription, telemetry, and other supporting components can carry the same identity risk as the primary AI surface when they transport tokens or sensitive context. In agentic systems, governance has to expand the boundary of what counts as credential-handling infrastructure. Practitioners should map every adjacent service that can expose or relay authority.

What failed here was not secret protection but delegated authority containment. The article shows a concrete governance assumption that breaks under AI agents: if the secret is outside the runtime, the session is safe. That assumption fails because the attacker did not need the vault, only the token that spent its authority. The implication is that access models must be built around execution-time controls, not trust in where the secret sits.

From our research library:

• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Static vs Dynamic Secrets

What this signals

Ephemeral credential trust debt: AI agent programmes often secure the vault while leaving the session authority untouched, which means the highest-risk control is now the place where a token is spent rather than where it is stored. Teams should expect this gap to show up first in supporting services that were never classified as identity infrastructure.

Governance models built for human-paced review cycles cannot reliably observe or certify agent actions once a token can be captured and reused inside the same runtime path. The practical response is to move decision points closer to tool invocation and to treat every adjacent service as part of the authority chain.

For practitioners

• Map agent authority at issuance time Build an inventory of which AI agents can act, what their tokens reach, and which services they can call without further review.
• Constrain tool calls at the moment of action Apply allow, limit, block, or record decisions to each tool invocation so a stolen token cannot freely exercise every granted capability.
• Treat supporting services as sensitive identity surfaces Review transcription, telemetry, and other helper services for token exposure, redirectable endpoints, and hidden credential paths.
• Replace standing grants with expiring permissions Use just-in-time access where the agent must reacquire authority for high-risk actions instead of carrying broad standing access through the session.

Key takeaways

• The incident shows that a secure vault does not eliminate AI agent compromise when the runtime session can be hijacked.
• The exposed token gave the attacker the same standing authority the agent already held, including downstream tool access and actions.
• The limiting control is execution-time governance over tool calls and helper services, not secret storage alone.

Key terms

• Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
• Runtime authority: Runtime authority is the permission an AI system has while it is actively deciding and acting, not just when it is approved. In governance terms, it is the point where access, tool use, and action scope become operational, which is why build-time review alone cannot prove safety.
• Tool Call Governance: Tool call governance is the control of model-initiated actions that reach external systems, data sources, or workflows. It matters because the model is no longer only generating content. It is making a request that can change state, so policy checks must happen before execution continues.
• Supporting Service Attack Surface: The supporting service attack surface is the set of adjacent components, such as transcription or telemetry services, that can expose, relay, or redirect an agent's credentials and data. These components often sit outside the headline threat model even though they can become the easiest path to token theft.

What's in the full analysis

Unosecur's full article covers the operational detail this post intentionally leaves for the source:

• The exact Muse client behaviour that let a local process rewrite settings without elevation.
• The proof-of-concept attack sequence showing how the token was captured and replayed.
• The tool-call governance approach Unosecur uses to allow, limit, block, or record agent actions.
• The practical description of just-in-time access replacing standing grants for agent workflows.

👉 The full Unosecur post covers the proof-of-concept, token path, and runtime governance details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.