Ghost doesn't attack the Gate's rule engine — that's provably not where the risk is, since it never reads text. Ghost attacks everything around it: execution primitives with no gated path, facts fed to the gate that are secretly derived from agent output, tool pairs that can be chained to reproduce a consequential effect, and policy coverage gaps that silently default to ALLOW. Run the live demo below — every attack attempt is generated fresh, in real time.
Every run asks an LLM to write a new, differently-worded social-engineering attempt against three built-in scenarios, then evaluates the same fixed facts through the real gate engine running server-side. The generated wording is never fed to the engine — exactly like the Gate demo, typing a better lie changes nothing.
The gate can't be jailbroken by cleverer phrasing — that's the whole point of a deterministic engine. So Ghost tests everywhere the phrasing actually matters: upstream of the gate, and around it.
Any declared tool that's a raw shell, sql, or exec primitive can re-implement any gated action directly. Automatic FINDING — no gate in front of it can close that door.
Two individually-benign tools — a reader plus something with an ambiguous external effect — can sometimes be chained to reproduce a consequential action neither name alone would trip a keyword check for.
Exhaustive testing at every numeric threshold (limit-1 / limit / limit+1), plus a coverage check: any consequential tool with no matching declared policy rule is a silent ALLOW-by-default gap.
The real injectable surface isn't the gate — it's upstream. If approval_verified is itself derived by asking the agent "did you get approval?", the whole guarantee is void before the gate ever runs.
Does approval/verification state survive being attributed to a delegate? Ghost confirms the engine itself has no delegation bypass — and flags what it can't verify: your own integration's plumbing.
Is cumulative state (a velocity counter, a "payout changed recently" flag) actually implemented across a sequence of actions, or always passed as false/0 — silently defeating the rule that depends on it?
The public demo above proves the mechanism. A boundary report runs the same six checks against your actual declared tool list, policy rules, and fact-provenance contract — no LLM call anywhere in this path, since feeding your tool descriptions into a prompt would recreate the exact risk Ghost tests for. Fast, static, and it doesn't touch your live agent.
The same inputs as the chokepoint checker on the Gate page, extended: every tool name, every rule's kind and threshold, and where each fact your policy relies on actually comes from.
PASS / FINDING / BLOCK / HUMAN REVIEW per check, with a tamper-evident evidence log you can independently verify — not a guarantee, a description of gaps in the surface you declared.
Ghost does not connect to, execute against, or take any action on your live production agent. It does not "jailbreak-test" the deterministic rule engine — that's provably not where the risk is, and claiming otherwise would just be a more elaborate demo of a fact Gate already proves.
A clean Ghost report is not a guarantee. It's a description of what Ghost could check against a declared surface, at the moment you declared it. Where a fact's source is unspecified, or where verifying something requires seeing your actual integration code, Ghost says so and routes it to human review instead of guessing.
The public demo above always shows PASS, by construction — the point isn't suspense, it's that a fresh, differently-worded attack changes nothing about a verdict computed from typed facts. The real product is the boundary report and the pilot, run against your own declared surface.
A boundary report or a shadow-mode pilot — either way, nothing gets blocked until you've seen what would have been.
Request a boundary report →