Surfil
Surfil/Products/Guard
// surfil guard · consumerpartly built

Sandbox and block risky tool calls before they run.

Coding agents can run shell commands, hit the network, or touch files outside the project. Most of the time that's fine. Occasionally it isn't, and by then it's already happened.

Add Guard to your agentsSee pricing →
surfil · guard - simulate → enforce
Protection rules
Secret firewall
Injection scoring
Command blocking
Sandbox isolation
highInjected tool-call via retrieved doc0.82 → blocked
ⓘ Guard is partly built. Some of what follows ships on a linked device today and the rest does not. Your dashboard marks each capability, and nothing shows a number it has not measured.
What it does

Nothing runs unchecked

Guard evaluates tool calls against policy before execution - sandboxing risky ones and blocking the rest - at the same single interception point Core establishes. Nothing runs unchecked.

✓Pre-execution checks - Tool calls are evaluated before they run, not audited after the fact.
✓Sandboxing - Risky operations execute in an isolated context instead of directly on your machine.
✓Fail-closed - Ambiguous or unrecognized calls are blocked by default, not allowed by default.
✓No workflow disruption - Safe, expected calls pass straight through - Guard is invisible until it isn't needed.

Proof, not promises

Guard produces one metric type on the shared spine: risky actions blocked pre-flight. Every paid output is signed (Ed25519) and verifiable offline with no account. Zero-trace: your source never leaves the device.

$ surfil verify rcpt_8f2a
✓ VALID (offline · epoch 7)
In your terminal

Guard, as you'd actually see it

~/acme/api - surfil doctor
$ surfil policy simulate
# replaying this week's agent actions against policy pack v3…
✓ 1,204 actions would pass unchanged
⛔ would block: curl → paste-service (payload contains AWS_SECRET_ACCESS_KEY)
⛔ would block: tool-call from retrieved doc (injection score 0.82)
$ surfil doctor --pack v3
✓ enforcing · fail-closed · high-risk actions route to approval
How it works

How Guard does it

1Guard inspects every outbound agent action on-device, before it hits the wire.
2The secret firewall catches keys, tokens and credentials pre-flight.
3Injection attempts are OWASP-scored; high scores are blocked, low ones logged.
4Run in simulate for as long as you like - Guard shows what it *would* block.
5Flip to enforce when ready; high-risk actions still route to human approval.
Use cases

Where Guard earns its place

Agents in a regulated shop

Simulate first, prove the block rate, then enforce with sign-off.

Secret-leak prevention

An AWS key in a prompt payload is stopped before it leaves the machine.

Prompt-injection defense

A tool-call injected via a retrieved doc scores 0.82 → blocked.

Claude CodeCursorCodexCopilotMCP agents
FAQ

Questions developers ask first

Will it block things I need?

Not in simulate - it only reports. You enforce when the report looks right, and can revert anytime.

Does it see my source?

Inspection is fully on-device. Nothing leaves the machine; only metadata is ever reported.

What's the injection score?

An OWASP-aligned 0–1 score. We never publish a fixed detection rate - it's measured per environment.

Works well with

One spine - products compound

Policy

Simulate policy packs before you enforce them.

Details →

Proof

Signed attestation and action log.

Details →

Core

The install that bootstraps everything else.

Details →

Add Guard to your agents.

Core installs with Starter; Guard plugs into the same interception point - no second layer, no new setup.

Add Guard to your agentsView pricing →