The pain: the more your agent can do, the more it can do wrong
The instinct when connecting an AI assistant to your platform is to give it everything — every query, every action, every admin operation. Then you picture that same agent, on a bad prompt or a confused reasoning step, cancelling a subscription, revoking a teammate's access, or deleting a record, and the enthusiasm curdles into anxiety. A large tool surface is exactly what makes an agent useful and exactly what makes it dangerous. Most teams resolve that tension by shipping a tiny, timid integration and leaving the real capability on the shelf.
The problem: "all or nothing" is the wrong axis
The usual choices are both bad. Expose everything and you've handed an autonomous system your admin console. Expose almost nothing and the agent can't do the work you connected it for. Worse, the decision usually gets made once, globally, by whoever built the integration — not per customer, not per risk appetite, and never revisited. There's no dial, only a switch, and the switch is in the wrong place.
The solution: register everything, enable deliberately
Safeguard's MCP server registers 900+ tools — the full platform surface, from vulnerability triage to procurement to admin operations — but availability is governed per tenant by a per-tool feature flag (mcp:tool:<name>). Two properties make this safe:
- A tiny default. A fresh workspace gets exactly 10 core tools — connect a repo, scan it, browse results, orient the session. Everything else ships off.
- Deliberate, admin-controlled widening. An administrator turns on precisely the tools their team should have, per tenant, from the feature-flags console — and can turn any default off just as easily. A workspace can let agents browse pricing but never initiate checkout; enable findings triage but not member management. The dial exists, and it's in the customer's hands.
Discovery and execution resolve from the same flag set, so an agent can never see a tool it can't call or call one it can't see. And it fails safe: if flag resolution can't complete, the server falls back to the small default rather than exposing anything wider. An outage can never broaden what an agent can do.
The ease of use: start narrow, grow with trust
The experience for an admin is a searchable list of every capability with a clear "default" marker and a per-tenant toggle. You start with the safe core, watch how the agent behaves, and switch on more as you build confidence — the same way you'd grant a new hire access. No redeploy, no code change, no all-or-nothing leap of faith.
That's the shape governance has to take as tool counts climb into the hundreds and thousands: not a smaller product, but a smaller default, with every additional capability a conscious, reversible decision owned by the person accountable for the risk. Least privilege isn't a constraint you bolt on afterward — it's the thing that lets you ship the whole platform to an agent at all.
What teams are searching for
Teams hit this problem long before they know what to call it. If any of these queries brought you here, you are in the right place:
- "MCP tool governance"
- "limit what an AI agent can do"
- "per-tenant feature flags MCP"
- "least privilege for AI agents"
- "control MCP tool access"
- "disable MCP tools per customer"
Safeguard is built for exactly this.
How Safeguard helps
Safeguard is the software supply chain security platform built for the age of AI agents — 900+ governed MCP tools, agent-native onboarding and procurement, and reachability-aware scanning across SAST, DAST, SCA, secrets, containers, and IaC.
- Get started free: create your Safeguard account and connect a repository in minutes.
- Read the docs: the Agents & LLMs guide and the full documentation walk through every capability, step by step.
Not sure where to start? Point your AI assistant at our MCP server and just ask it to onboard you.