Ghost doesn't attack the gate's rule engine. The engine never reads text, so there is nothing to attack there. Ghost goes after everything around it: execution tools with no gated path, facts fed to the gate that actually come from the agent's own output, tool pairs that can be chained into an action neither one allows alone, and policy gaps that quietly default to allow. Every attack attempt in the demo below is generated fresh.
Each run asks a language model to write a new social-engineering attempt for three built-in scenarios, then runs the same fixed facts through the gate engine on our server. The generated wording never reaches the engine. As on the Gate page, a better lie changes nothing.
Cleverer phrasing can't get past the gate; that's what a rule engine is for. So Ghost tests the places where phrasing does matter: before the gate, and around it.
Any declared tool that's a raw shell, sql, or exec primitive can rebuild any gated action directly. That is always a finding. No gate in front of it can close that door.
Two tools that look harmless on their own, a reader plus something with an unclear external effect, can sometimes be chained into an action that a keyword check on either name would miss.
Tests at every numeric threshold (limit-1 / limit / limit+1), plus a coverage check: a consequential tool with no matching policy rule is allowed by default, and nobody notices.
The place where injection works is before the gate. If approval_verified is set by asking the agent "did you get approval?", the guarantee is gone before the gate ever runs.
Does approval state survive being handed to a sub-agent? Ghost confirms the engine itself has no delegation bypass and flags what it can't check from outside: the plumbing of your own integration.
Is cumulative state (a velocity counter, a "payout changed recently" flag) really tracked across a sequence of actions, or always passed as false/0, which quietly disables the rule that depends on it?
The demo above shows the mechanism. A boundary report runs the same six checks against your own tool list, policy rules and the sources of your facts. No language model is involved in that path: feeding your tool descriptions into a prompt would create the very risk Ghost is testing for. It is a static check and doesn't touch your live agent.
The same inputs as the checker on the Gate page, plus a bit more: every tool name, every rule with its threshold, and where each fact your policy relies on comes from.
PASS, FINDING, BLOCK or HUMAN REVIEW for each check, with a hash-chained log you can verify yourself. It is not a guarantee; it describes the gaps in the tool list you gave us.
Ghost does not connect to, run against or act on your live agent. It also doesn't try to jailbreak the rule engine. The engine never reads text, so that test would only repeat what the Gate demo already shows.
A clean Ghost report is not a guarantee. It describes what Ghost could check against the tool list you declared, at the time you declared it. Where a fact's source isn't specified, or where checking something would need a look at your integration code, Ghost says so and marks it for human review instead of guessing.
The public demo above always ends in PASS. That's by design: the point is that a freshly worded attack changes nothing about a verdict computed from facts. The real work is the boundary report and the pilot, run against your own tool list.
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 →