Prompt injection can hijack an agent's judgment.
It can't hijack its permissions.

Prompt injection is the number-one risk on the OWASP Top 10 for LLM applications, and it has a property that makes security teams deeply uncomfortable: nobody has solved it, and nobody credibly claims they will. An LLM agent works by reading text and acting on it. Any text it reads — a web page, an email, a document, a ticket, another agent's output — can carry instructions. The UK's National Cyber Security Centre warned about exactly this when it urged caution in building on LLMs: the model cannot reliably tell the difference between the data it was given to work on and the commands hidden inside that data.

The industry's main responses — better system prompts, injection classifiers, output filters — all share the same weakness: they fight language with language, and they fight probability with probability. A filter that catches 99% of injections is a filter that an attacker gets to probe, for free, until they find the 1%. When the agent holds real credentials and touches real systems, "99% of the time it refuses" is not a security boundary. It's a dice roll with your infrastructure on the table.

CipherGov's position: stop defending the prompt. Defuse the consequence.

CipherGov doesn't try to prevent prompt injection — we assume it will succeed. The whole platform is built on a harsher, more honest premise: the agent's judgment is compromisable, so the agent's judgment must never be the thing standing between an instruction and its execution.

That's what it means to put enforcement below the model. Whatever an agent decides to do, the decision isn't what executes — every action is independently checked against the agent's cryptographically signed birth certificate before it can touch anything. The check is deterministic, not probabilistic, and there is no ML in the enforcement path — which means there is nothing in the enforcement path that reads attacker-controlled text. You cannot prompt-inject a signature verification.

An injected instruction can change what the agent wants to do. It cannot change what the agent is signed to do.

What that looks like in practice

Our demo platform has a button we're fond of: "Inject rogue instruction." It feeds a live, LLM-driven agent a hostile instruction mid-task — the classic indirect injection scenario. What the audience watches happen, every time:

1. The injection lands. The model reads it, reasons about it, and — because models are suggestible — often decides to act on it. We don't pretend otherwise.
2. The action dies before it reaches anything. The hijacked attempt is refused in under a millisecond; no target system ever sees it.
3. The attempt becomes evidence. The refusal lands in tamper-evident, signed audit records — what was attempted, by which agent, when. The injection is now an audit artifact instead of an incident.
4. The agent loses its license. A compromised agent can be revoked outright — in under 60 seconds, even air-gapped — after which nothing it signs is accepted anywhere. The attacker didn't gain access; they disclosed themselves and got their agent terminated.

The four guarantees, read as an anti-injection architecture

• Control — the blast radius of a successful injection is capped at the agent's signed scope, enforced below the model. Not "the agent was told not to." The agent can't.
• Attestation — injected text can't steal an identity. An attacker who fully puppets the model still can't sign as anyone else, replay an old credential, or mint a new one.
• Revocability — a compromised agent isn't a crisis, it's a revocation. The kill switch needs no network, so it works in exactly the disconnected environments where physical AI runs.
• Observability — every injection attempt that reaches for the wrong capability self-documents in signed, chained evidence. Your auditors and your incident reviews get proof, not the agent's self-report.

The honest fine print

Cryptographic enforcement caps the blast radius; it doesn't make the model wise. If an agent is signed to send email, an injection can still talk it into sending a bad email — within scope, within policy. That residual risk is real, and it's why scopes should be minimal, why risky capabilities deserve tighter policies, and why model-level defenses still matter as a layer. Governance doesn't replace them. It guarantees that when they fail — and at scale, they will — the failure is bounded, revocable, and provable.

That's the trade we think every team deploying agents should understand: you cannot make a language model un-suggestible. You can make its suggestibility powerless outside a signed, revocable, auditable scope. Prompt injection keeps its voice. It loses its hands.

See the "Inject rogue instruction" scenario live — book a 30-minute demo, or start with the 2-minute recording.