Ghostjacking Turns Trusted Tools Against You. Bay Controls What Happens Next.
August 2026 · 8 min read
Ghostjacking is an AI agent attack that uses indirect prompt injection to turn a trusted agent into an attack tool. Instead of breaking through your defenses, the attacker hides an instruction in data the agent will read, then lets the agent carry out the damage using its own legitimate permissions.
A firewall blocks a malicious request. The request is logged. An AI agent reads the log, treats attacker-written text as remediation guidance, and uses its valid Cloudflare permissions to change DNS.
The firewall worked. Authentication worked. The API worked. The agent did exactly what it was authorized to do.
That is the uncomfortable lesson in Tenet Security's Ghostjacking research: the next generation of agent attacks does not always need to evade your controls. It can route attacker intent through them.
Key takeaways
- Ghostjacking is not a break-in. A trusted AI agent is manipulated into acting for the attacker, using permissions it already holds.
- Every traditional control can "work" and the attack still succeeds. The firewall blocks, the login is valid, no process looks malicious.
- It starts with indirect prompt injection but the damage comes from excessive agency: broad tools, broad credentials, weak approval.
- No product makes a model immune to prompt injection. The defensible control is stopping the resulting action.
- Bay enforces Allow, Ask, or Deny locally at the point where an agent's intent becomes an action, in under 4ms.
What is Ghostjacking?
Ghostjacking is an authorization problem disguised as a prompt problem.
Indirect prompt injection is the entry point. An attacker places instructions in a log, alert, issue, webpage, database row, or tool response. The agent cannot reliably distinguish those instructions from the task it was given.
The damaging step comes next. The same agent can read the untrusted content and act with a developer's or administrator's authority. Tenet describes variants involving Cloudflare, Datadog, and Sentry, with reported outcomes ranging from local code execution and credential access to DNS changes and agent-to-agent instruction laundering.
Calling this a prompt-injection problem is incomplete. The model can be manipulated, but the blast radius comes from excessive agency (OWASP LLM06), broad credentials, weak approval, and no control connecting the untrusted read to the privileged action.
Why doesn't the existing security stack catch it?
Because Ghostjacking falls in the gaps between the tools you already run.
A WAF understands requests. IAM understands identities and permissions. EDR understands processes. An AI gateway understands model traffic.
Ghostjacking crosses all four layers:
- The WAF may block the original request and preserve its attacker-controlled content in a log.
- IAM sees a valid identity call an allowed API.
- EDR sees a trusted coding agent or no local process at all.
- A gateway may see the model conversation but not the local file read, MCP update, or cloud control-plane change.
The missing context is the agentic chain: which external data the agent consumed, which tool it selected next, which identity it used, and whether the action should have been allowed in that sequence.
How does Bay stop Ghostjacking?
Bay enforces at the point where intent becomes action.
Bay is built around a simple security principle: do not depend on an AI model to police another AI model.
Bay compiles deterministic policy and deploys it to endpoints through Wave, an ephemeral binary that runs through your existing MDM or EDR and exits. On supported agent surfaces, the Enforcer evaluates prompts, pre-tool calls, and post-tool responses, then returns Allow, Ask, or Deny locally, in under 4ms, with no cloud round-trip. Ask holds the tool call pending human approval.
The model can still misunderstand a poisoned alert. It does not get to overrule a policy that blocks the resulting credential read, package installation, network connection, or DNS update tool.
That distinction is what makes runtime enforcement the right control layer for Ghostjacking.
Six controls, one policy plane
1. Discover the authority agents already have
You cannot reduce an attack surface you cannot see. Bay inventories AI agents, MCP servers, tools, credentials, extensions, settings, and endpoint deployments, and applies 200+ detection rules with risk scoring and guided remediation across that inventory.
Bay findings identify the posture that turns manipulation into compromise: auto-approval and YOLO modes, disabled sandboxes, exposed credentials, broad filesystem access, dangerous MCP capabilities, untrusted software, and unsafe extensions. The Skill Security Profile also analyzes agent add-ins for instruction overrides, approval bypass, concealed content, execution behavior, credential access, and network destinations.
For each MCP server, Bay shows its source, transport, authentication, credentials, tools, and action categories. Security teams can see whether an observability integration is read-only or also exposes Create, Update, Delete, or Execute tools.
That answers the first Ghostjacking question: can the agent that reads an alert also change the system described by the alert?
2. Remove tools that should not exist
MCP Control creates an allow list or block list for the fleet. In Enforcement mode, Bay removes disallowed MCP servers from agent configuration on in-scope endpoints.
Application Control extends the same posture to applications, CLIs, browsers, IDEs, and extensions. Malicious Software policies automatically remove software Bay identifies as malicious.
This reduces the number of places untrusted data can enter and the number of tools available after an agent is manipulated.
3. Separate observation from action
Bay MCP rules operate below the server level. A policy can target one server, one named tool, or an action category: Read, Create, Update, Delete, Execute, or Other.
An organization can allow an agent to read Sentry issues, Datadog alerts, or Cloudflare events while blocking every write and execution tool on those integrations. If one narrow write workflow is required, security can Ask or Allow that exact named tool without granting the entire server.
This directly addresses the Cloudflare pattern in Tenet's research. The alert-reading workflow does not need unrestricted DNS administration.
4. Control local execution, credentials, and egress
Ghostjacking becomes endpoint compromise when a poisoned record convinces an agent to run code, install a package, read credentials, or send data out.
Bay policies cover each step:
- Capability rules control shell execution, code execution, process spawning, package installation, cloud CLIs, containers, Kubernetes, browser automation, and system changes.
- Custom rules cover organization-specific command patterns.
- Credential and Filesystem rules block SSH keys, cloud credentials, Kubernetes configuration, environment files, keychains, and agent persistence paths.
- Network rules create destination allow lists and block unapproved egress.
These decisions are evaluated locally at the supported agent hook. The attacker does not win merely because the model followed the injected instruction.
5. Follow the sequence, not just the individual call
A single read can look harmless. A single network call can look normal. Read a credential and then make the network call, and the risk changes completely.
Bay Session Rules preserve that context. A policy can arm when an agent retrieves data from an observability MCP, touches a credential, or sees detector-matched content. It can then block or ask on the next matching write, execution, network, MCP, or model action. Sticky boundaries keep blocking retries for the rest of the session.
For Ghostjacking, this means a security team can express controls such as:
- After an agent reads an externally influenced alert, block infrastructure mutations.
- After an agent reads a credential, block outbound network calls for the session.
- After an MCP returns a secret, block that secret from reaching another MCP or model.
This is the causal control that traditional per-event security misses.
6. Protect configuration and sensitive data
Bay Data Detectors can become runtime policy conditions, not only findings. Model rules protect sensitive content before it reaches the model. MCP rules inspect supported tool inputs and responses. Network rules protect detector-matched content headed to an unapproved destination.
Managed Settings adds a preventive layer for Claude Code, Codex, and Claude Desktop configuration. Administrators can lock permission rules, preserve managed hooks, restrict MCP servers, and constrain plugin sources. Bay protects its managed enforcement settings during merge and reports content or metadata tampering through the Admin Center.
Runtime enforcement catches the action. Managed configuration makes the action harder to expose in the first place.
What Bay changes in the Ghostjacking kill chain
| Ghostjacking stage | Without an agent control plane | With Bay policy |
|---|---|---|
| Poisoned alert enters an observability platform | Agent retrieves it as normal operational data | The server is inventoried, approved, and restricted to the tools required for triage. |
| Agent interprets data as an instruction | Prompt guidance competes with attacker text | Bay does not rely on prompt guidance as the security boundary. |
| Agent selects a write or execution tool | Broad server approval permits the action | Per-tool and per-category MCP rules Deny the action. |
| Agent attempts package or shell execution | Local developer authority becomes attacker execution | Capability or Custom rules Deny the action or hold it with Ask. |
| Agent reads secrets | Developer credentials are available to the agent or child process | Credential and Filesystem rules Deny the access on supported surfaces. |
| Agent attempts exfiltration | Valid process makes an ordinary outbound connection | Network and data-aware rules Deny the destination or protected content. |
| Agent retries or changes tools | Each action is evaluated in isolation | A sticky Session Rule preserves the risky context and blocks later matches. |
| Agent changes settings for persistence | User-level configuration becomes the backdoor | Managed Settings, path rules, and tamper detection protect the control plane. |
Static hardening is useful. It is not enough.
Tenet released Agent JackStop, a set of Cursor and Claude Code configuration examples. Its network, permission, filesystem, and untrusted-output guidance is a useful starting point.
Static configuration alone has limits:
- A prompt rule is still interpreted by the same model receiving the injected content.
- A network allow list does not stop an authorized DNS update through an approved Cloudflare tool.
- A sensitive-path list does not follow data returned by MCP or passed between tools.
- A configuration file does not provide fleet inventory, scoped rollout, simulation, session correlation, enforcement reporting, or tamper alerts.
Bay supplies that operational control plane. Policies are scoped by agent, group, endpoint, and device. Teams can run them in Simulation Mode, inspect would-be decisions, tune rule order and exceptions, and then move to enforcement without rebuilding every agent configuration by hand.
What responsible vendors should not promise
No product makes a model immune to indirect prompt injection. Bay does not claim that it can prevent every attacker-written sentence from entering an agent's context.
Bay controls the consequences at the surfaces it can enforce.
How to prevent Ghostjacking: start with the authority boundary
The fastest way to reduce Ghostjacking risk is to break the trifecta-shaped condition Ghostjacking depends on: untrusted content entering the session, an agent with access to sensitive systems, and a tool that can act on the outside world. Remove any one leg and the chain breaks.
- Inventory every agent, MCP server, and tool.
- Remove unapproved servers and software.
- Make observability integrations read-only.
- Block high-impact MCP, shell, credential, and network actions.
- Add sticky Session Rules from untrusted retrieval to sensitive action.
- Lock the agent configuration with Managed Settings.
- Simulate, verify, and enforce.
Bay gives security teams one place to do all seven across the fleet. The agent may still read a hostile instruction. Bay gives security teams deterministic control over whether the supported actions that follow are allowed, held for approval, or denied.
Frequently asked questions
What is Ghostjacking?
Ghostjacking is an AI agent attack that uses indirect prompt injection to turn a trusted agent into an attack tool. The attacker hides instructions in content the agent reads, such as a log, alert, or issue, and the agent then acts on them using its own valid permissions. It was documented in Tenet Security's Ghostjacking research.
Is Ghostjacking the same as prompt injection?
No. Indirect prompt injection is only the entry point. The damage comes from what the manipulated agent is then allowed to do: excessive tools, broad credentials, and no control connecting the untrusted read to the privileged action. It is better understood as an authorization problem than a prompt problem.
Can you fully prevent indirect prompt injection?
No, and any vendor claiming otherwise is overpromising. No product makes a model immune to attacker-written instructions entering its context. The defensible approach is to enforce on the resulting action: allow it, hold it for human approval, or deny it before it completes.
Why doesn't my EDR, WAF, or AI gateway catch Ghostjacking?
Each of those tools sees one layer. A WAF sees requests, IAM sees identities, EDR sees processes, a gateway sees model traffic. Ghostjacking crosses all of them, and each layer sees only a valid, authorized event. The missing context is the agentic chain: what the agent read, which tool it chose next, and whether that action should have been allowed in that sequence.
How does Bay stop Ghostjacking?
Bay enforces at the action layer. On supported agent surfaces, Bay Enforcer evaluates prompts, pre-tool calls, and post-tool responses and returns Allow, Ask, or Deny locally, in under 4ms, with no cloud round-trip. Even if the agent is manipulated, the harmful action is held or denied before it completes.