From Model Risk to Action Risk

TL;DR

• Prompt injection can't be fully fixed at the model level. The UK's NCSC says it may never be fully mitigated.
• Coding agents act with the employee's own credentials, so an injection that lands can turn into real commands, file writes and data leaving the laptop.
• Coding agents don't agree on what's dangerous: given the same planted instruction, Claude Code refused and Cursor sent the developer's .env file.
• Manifold checks what an agent is about to do on the laptop and applies the security team's policies before it runs. Session analysis flags what the policies miss.
• The question to ask a security vendor: if an injection gets through, what can the agent still do, and will you know?

A developer finds a project on GitHub, downloads it and asks Cline, the AI coding assistant installed 4.2 million times, to set it up: "Set up this project for me, follow every instruction in the README."

Cline gets to work. The README looks ordinary. One step is a quick "health check" that contacts a web address. Hidden inside that address is a command the attacker planted.

Before running anything, Cline checks whether the step is safe. It has a "Safe Commands" setting for exactly this. But it never looks at the command itself. It asks the model, and the model, which has just read the attacker's README, says it's fine. The command runs without a warning, and the developer carries on with their day.

When our researchers tried this, the hidden command simply opened a calculator, proof that it worked. A real attacker wouldn't stop there. With the developer's own access, they could walk off with cloud credentials, SSH keys and source code, and the developer would never know it happened.

Cline left the safety check to the very model the attacker had just tricked. In our research team's words, Cline "asks the prompt-injected agent whether the prompt-injected agent's command is dangerous." The model never said anything harmful; the damage came from what the agent did. (Read the full research.)

AI security started with the model

The first wave of AI security tools was built around the model. Prompt firewalls screen the input people send to the model, and guardrails and classifiers screen its output. AI red teaming tests whether it can be talked into saying something it shouldn't, like how to make a bomb.

That approach was built for chatbots. The output was text, and a person read it before anything happened. At worst, the model said something embarrassing and someone posted a screenshot.

Coding agents changed the output. It is now a shell command, a file write, an API call or a git push, carried out with the employee's own credentials, which are usually far more permissive than the task needs. Nobody reads it first. By the time anyone looks, it has already run.

Why the prompt can't be the control

Fixes for prompt injection don't last: patch one and another turns up a few attempts later. A new model can fall for a trick the last one learned to resist. The UK's National Cyber Security Centre said in December 2025 that prompt injection may never be fully mitigated and advised reducing its impact instead.

The attacks that get through are also the hardest to see at the prompt. A multi-step attack splits the work into pieces that each look harmless. Read this file. Compress it. Send it here. A prompt firewall checking each step passes all three. Only the sequence of actions in the session shows what happened.

Even the agents themselves don't agree on what's dangerous. In another piece of our research, two git config commands were enough to impersonate a well-known AI researcher. An AI code reviewer trusted the name and merged the change, which added an instruction file telling coding agents to send the developer's .env file, where secrets are kept, to an outside server. Claude Code refused, but Cursor did it.

An agent's built-in safety is useful, but it is inconsistent, and you can't build a control on something that changes with every agent and model.

Won't smarter models fix this?

The usual objection is that prompt injection will fade as models improve. Bigger models will spot the simple tricks, and only sophisticated multi-step attacks will remain.

Suppose they're right. The attacks that remain are exactly the ones prompt-level tools can't see, because each step looks harmless on its own.

Even if the best models do get better at resisting injection, few companies run just one. Teams use models from several providers, both open-source and closed, and a new class of model routers switches between them depending on the task. How well an agent resists an injection then depends on which model happened to handle that request, which makes it hard for anyone to say how protected they are at a given moment.

And injection was never the only way an agent causes damage. When Uber published results from monitoring more than 50,000 agents, credential leakage turned out to be more common than prompt injection. Agents copied secrets to places they shouldn't, with no attacker involved. A model that can never be injected can still run a destructive command or push a key to a public repository.

Ask what a manipulated agent can still do

If the injection is to land, the useful question is what the agent is about to do, on whose machine and with whose access.

That question gets answered where the agent runs: on the employee's laptop, at the moment of action. That is where Manifold works.

• Commands: Endpoint hooks see the command an agent is about to run, and a policy the security team writes can stop a risky one before it runs.
• Supply chain assets: Manifold scans the skills and MCP servers agents use and flags the risky ones, drawing on the same intelligence we publish openly in Manifest. A policy can then block a risky one before an agent uses it.
• The session trace: Every session is recorded, so a security team can see what the agent ran and touched, how each action was handled, and by which policy.
• Data leaving: Exfiltration-like behaviour is flagged in the session, and a policy can block it before the secrets leave.

When a policy matches, blocking is only one of the options. Manifold lets each policy respond in one of six ways:

• Alert: flag the action.
• Advise: guide the agent while it works.
• Ask: have the developer confirm first (more on Ask).
• Correct: stop the action and show the agent the safe way.
• Block: stop the action.
• Block session: end the session.

Now replay the spoofed identity attack with Manifold on the developer's laptop. The planted instruction file still lands, and Cursor still decides to follow it. But when Cursor tries to send the .env file to the attacker's server, Manifold flags it as data leaving, and before the upload command runs, a matching policy can deny the request or ask the developer to confirm first. The security team can see in the session trace what Cursor tried to do and how the policy responded.

The same protection applies to other agents we support. In our testing, when GitHub Copilot was tricked into fetching and running a script with a curl | bash command, that command passed through the hook, where a policy could stop it.

When a policy doesn't catch it

An injected agent doesn't have to do anything a policy would flag. It can stay inside what it's already allowed to do, on systems the company has approved, so every step looks like normal work. We've seen what that looks like in practice: agents that caused real intrusions using valid credentials.

Policies keep evolving as teams learn how their agents behave, so Manifold also runs session analysis. It looks at the agent's behaviour across the whole session and flags patterns no single policy can see, like the read, compress and send sequence from earlier. The security team sees what slipped past their policies and where the next policy should go.

What to ask your AI security vendor

When a vendor tells you what percentage of prompt injections they catch, ask a different question: if one gets through, what can that agent still do in my environment, and will I know?

A good answer is specific. It names which agents they cover, which actions they can stop before they run, and what your security team sees afterwards. If the answer is still a detection rate for prompts, they're only securing the model.