Design note

Why we run injection detection locally.

Hosted prompt-injection APIs require inspected text to cross a vendor boundary. Self-hosted and open-source alternatives exist too. Tripwire takes a narrower route: a small deterministic signal layer that runs locally.

It sends scan content nowhere and shows the exact evidence behind each match. That is a deliberate architecture choice, not a claim that local heuristics solve prompt injection.

The cloud firewall dealbreaker.

To detect a prompt-injection attempt, a tool has to read the content. When that tool is a hosted service, the content it reads — the untrusted document, the customer email, the retrieved record, and often the surrounding prompt — leaves your infrastructure and enters a vendor’s.

For teams in health, legal, financial and public-sector work, or any startup with a strict data-handling promise to its own customers, that is not a small integration detail. It is the reason the project stalls in review. You cannot solve a data-exposure risk with a control that itself exposes the data.

What “local” actually means here.

Local is not a marketing adjective on Tripwire; it is the architecture.

On device
The detector is a pure TypeScript engine. The CLI, the Chrome extension and the Guard MCP server all run the same code on your own machine.
No network
Scanning makes no outbound request. There is no API key, no account, no telemetry, and nothing to leak because nothing is sent.
Redaction by default
When a finding is exported, emails, URLs and credential-like strings are redacted, so even the report you choose to share does not carry the sensitive payload.

The practical effect: you can test a signal layer inside an existing data boundary without adding a hosted inspection endpoint.

Explainable evidence beats a mystery score.

Tripwire’s engine is deterministic. The same input produces the same decision, and every finding carries a rule identity, severity, source offset and matched span. You can reproduce a result and inspect the published evaluation, including every documented miss.

That is a deliberate contrast with model-based detectors, whose verdicts are a probability you cannot fully explain. When your own security review asks “why did this pass, and why did that fail,” a deterministic engine can answer. And rather than claim a number in a slide, Tripwire publishes its full 100-case benchmark — 85% accuracy, and every false positive and false negative in the open.

The honest trade-off.

Local and deterministic is not free of cost, and pretending otherwise would undercut the whole point.

What you gain
Data never leaves your machine, results are instant and explainable, and there is no per-call bill or vendor dependency.
What you give up
A heuristic engine will miss novel, contextual, multilingual, visual or heavily obfuscated attacks that a large model might catch. A clean scan means “no known signal matched,” not “safe.”

So Tripwire is deliberately positioned as a fast, private first line of defense and a source of auditable evidence — paired with least-privilege tools, approval gates and sandboxing, not offered as a replacement for them.

Who this is for.

If your prompts can go to a third party and you want broader semantic coverage, a hosted model-based firewall can be a reasonable choice. Mature self-hosted toolkits and enforcement proxies may also fit better when you need a full control plane. Tripwire is for a narrower case: teams that want a fast, explainable first signal across browser, CLI and MCP inputs without a model runtime or hosted scan endpoint.

See it run on your own content. The browser scanner works entirely on-device. New to the topic? Start with the field guide to prompt injection. If you want a hardening assessment of your pipeline, check fit for the fixed-scope review.