Write guardrails that keep secrets and personal data out of prompts

This guide adds two or three guardrails to a SpanDock server, enforces them on every computer, and checks that they work. Guardrails are rules you set once on the server, such as "no card numbers in tool calls" or "confirm before sending a customer ID", and SpanDock enforces them on each person's computer. The matching runs on the computer itself, so prompt text never leaves it to be checked.

Prerequisites

• A SpanDock server on the Enterprise plan, or in the 30-day trial. Guardrails on computers aren't on other plans; redaction of prompts and tool contents at the source is in every plan.
• Paired computers running Claude Code, Codex or Gemini CLI. See Pairing clients.
• Administrator access to the server's dashboard.

What a guardrail looks for

Each guardrail uses one detector:

Detector	Finds
Secrets	API keys, tokens, private keys, credentials in URLs and passwords
Email addresses	Email addresses
Phone numbers	Phone numbers
Card numbers	Card numbers, checked with the Luhn algorithm so order numbers aren't taken for cards
IBANs	Bank account numbers in IBAN form, with their check digits verified
National IDs	US Social Security numbers and UK National Insurance numbers
Words	A list of words, such as project code names
Your own pattern	A regular expression, such as your customer ID format

Each guardrail also says where to look (what the person typed, the arguments of tool calls, or tool results) and who it applies to (user types, groups or people; everyone if you name none).

What a guardrail does

• Block: the prompt or tool call is refused, with your message.
• Warn: it goes through, with a note to the person and to the model, and it is flagged.
• Confirm: the person confirms first, and it is flagged for review.
• Redact: the matching text is removed where it can be; otherwise the call is refused.

You also choose what happens when SpanDock can't check, for example if it isn't running: let it through (the default) or block.

Where it is enforced, and where it isn't

• Claude Code, Codex and Gemini CLI: SpanDock installs a hook in each, which checks the prompt and every tool call before it runs.
• MCP tool calls through the MCP gateway: arguments and results, for every AI tool that uses the gateway, including chat apps such as Claude Desktop.

What can't be checked: messages typed into chat apps such as Claude Desktop or ChatGPT, which go straight to their provider, and the prompts of tools without hooks, such as Cursor or Windsurf. Their MCP calls through the gateway are covered. Plan your rules knowing where these gaps are.

If a person removes the hook from their own settings, SpanDock puts it back within a minute, and the server shows it meanwhile. Computers keep enforcing their guardrails while the server is unreachable.

Step 1: choose your first guardrails

Start with a small set that catches real problems without getting in people's way. For example:

1. Secrets, in prompts and tool call arguments, for everyone: block. A key pasted into a prompt is almost never intended.
2. Card numbers, in tool call arguments and results, for everyone: redact. Card data shouldn't reach a model or leave through a tool.
3. Your own pattern for customer IDs, in prompts, for contractors: confirm. The person can continue, and the event is flagged for review.

Step 2: add them on the server

1. On the server's dashboard, open Safety & compliance → Guardrails → Rules.
2. Add a guardrail: choose the detector, where to look, who it applies to, and the action. For a block, write the message people will see.
3. Repeat for each guardrail.

Rules suggested from your company policies, under the MCP gateway's Suggest rules, can become guardrails too.

Step 3: enforce them on computers

1. Open Guardrails → On computers and turn on Enforce on every computer. To start with a few machines instead, turn it on for single computers on the Computers page.
2. A guardrail reaches every computer within a minute. On computers shows each computer's state and which tools have the hook.
3. Ask people to start a new session in Claude Code, Codex or Gemini CLI. These tools load hooks when a session starts.

While guardrails are on, each computer's SpanDock shows a notice saying what is checked.

Verify it works

1. On a computer with enforcement on, start a new session in Claude Code.
2. Type a prompt containing a test value your rule should catch, such as a made-up string in your customer ID format. Never use a real secret to test.
3. Check the outcome: blocked with your message, a warning, a confirmation, or redacted.
4. On the server, open the Events tab. Filter by guardrail, action, outcome, computer and tool.

Every match is recorded as an event: the guardrail, the action and the outcome, the detector, the tool and the computer. Never the prompt, the arguments or the result. If you turn on Event samples, an event also keeps a masked sample, such as j***@e***.org.

Troubleshooting

• Nothing happens in an existing session. Hooks load when a session starts. Start a new one.
• A tool shows no hook on On computers. Only Claude Code, Codex and Gemini CLI get hooks. Other tools are covered only for MCP calls through the gateway.
• A rule fires too often. Narrow where it looks or who it applies to, or change block to warn while you tune it.

Next steps

• If the license lapses, guardrails keep working; the license is needed only to add or change them. See Guardrails on computers for the full reference.
• Govern MCP connectors with permissions and approvals: MCP gateway.
• Read what is recorded and what stays private.