Short answer: control three things separately. Inspect the traffic between your applications and your models, decide which tools an assistant may see and call, and set the permission mode of any agent that runs commands. Safeguard covers all three: the AI Gateway for prompts and responses, per-tenant MCP tool gating, and permission modes in the Safeguard CLI.
Why this is hard
Coding agents read untrusted content, call tools and run commands on developer machines and in CI. A retrieved web page, a pull request description or a tool result can carry instructions the agent follows. One over-broad tool grant is enough for an agent to leak data or change something nobody approved. And in most teams nobody can say which agent holds which access.
You do not fix this with one switch. The risks live in different places, so the controls do too.
The steps
- Take inventory. List the agents, assistants and applications that call a model, and the tools and servers each one can reach. You cannot govern what you have not listed.
- Put a guardrail between the app and the model. An LLM firewall inspects prompts for direct and indirect prompt injection and jailbreak patterns, and inspects responses for personal data leaving. Run it in monitor mode first so you can see what it would have done, then move to enforce.
- Decide what happens when the guardrail fails. A guardrail error should not take your application down. Fail open with an alert is a reasonable default, and fail closed is a choice for the few places that need it.
- Give assistants the smallest tool set that works. Start with read-only tools. Enable more one at a time, and make the tool list the assistant sees match the tool list it may call.
- Prefer a hosted, directory-installed connector over a local bridge. Sign in with OAuth so the assistant acts as you, within your role. Treat any package that claims to be a local bridge for a hosted server as untrusted.
- Pick a permission mode per task. For an agent that runs commands, choose how often it asks. A mode that asks before every change suits an unfamiliar repository. A read-only mode suits exploration. A mode that allows only pre-approved actions and denies the rest suits CI. A mode that never asks belongs only inside a sandbox.
- Record decisions. Keep one event per guardrail decision, with redacted metadata and never the raw prompt text.
- Track agent identity. Know which agent holds which access, at what level, so an audit can tell a person from an agent.
The Safeguard CLI modes
The Safeguard CLI agent has separate permission modes. They are not a ladder, so pick the one that fits the job:
- Supervised is the default. Reads run, and every change and command asks first.
- Edits lets workspace edits and allow-listed commands run, and asks for other commands.
- Plan is read-only. Changes are refused.
- Guarded runs read-only and policy-allowed commands and asks for the rest.
- Strict allows only what is pre-approved and denies everything else, which suits CI.
- Autonomous never asks. It is refused outside a sandbox runner unless you pass an explicit override.
What Safeguard does
The AI Gateway is an LLM firewall with prompt injection, jailbreak and PII egress guardrails. It runs as an inline proxy or a thin SDK shim, in monitor mode by default, with enforce switched on per tenant. Raw prompt and response text is never persisted.
The Safeguard MCP server is hosted at mcp.safeguard.sh and is listed in the Claude connector directory and the official MCP Registry. Administrators govern per tenant which tools are enabled, and a new workspace starts with a small read-only set.
Download
Download the datasheet, US Letter (PDF)
Download the datasheet, A4 (PDF)
