Securing MCP servers when every team connects agents to internal tools

When teams start connecting AI agents to internal tools through MCP servers, the platform owner's job is to know which servers and agents exist, decide which tool calls each agent may make, and keep a record of every decision. Do it before the connections outgrow the review process: register every server, give each agent a narrow set of tools, put a policy point in front of the calls, and log every allow, deny and monitor outcome so an auditor can follow it later.

This post walks that job end to end for an AI platform owner at a large enterprise. The first two thirds work with whatever tools you already have. Safeguard enters at "How Safeguard does this", and the matching use-case page is MCP Server Security.

Key takeaways

• The Model Context Protocol (MCP) gives an agent a menu of tools. Every tool on that menu is a permission, and most rollouts hand out permissions faster than anyone reviews them.
• The MCP specification already sets the floor: OAuth 2.1 for protected remote servers, resource indicators so a token is bound to one server, no token passthrough, and a human who can deny a tool call. The platform owner's work is making that floor real across many teams.
• A workable control set has four parts: an inventory of servers and agents, per-agent tool scope, a policy point that sees each call, and an audit trail of every decision.
• Safeguard capabilities covered here, all GA: AI agent discovery (GA), AI-BOM discovery (GA), MCP Guardrail (GA, documented as Guard), agent identity (GA), the Safeguard MCP server with per-tenant tool gating (GA), search Connectors with per-tool permissions (GA), the AI Gateway (GA), and policies and gates (GA).
• Guard policies decide each MCP tool call with allow, deny or monitor. CI gates use Block, Warn and Notify, with approvals handled through exceptions. They are separate mechanisms and most enterprises need both.
• Some things stay your job: choosing which servers are acceptable, designing OAuth in servers you own, approving sensitive actions, and acting when an alert fires.

The situation

You own the AI platform. The title might be Director of AI Platform, Head of ML Infrastructure or Principal Engineer for Developer Productivity. The company approved a couple of assistants and stood up a model gateway. Then the requests started.

Support engineering wants its agent to read tickets and post replies. Finance operations wants an agent that can pull invoices. Developers have already wired their coding agents to the issue tracker, the wiki, a database read replica and a cloud console, mostly by pasting a server URL and a token into a config file. A product team has built an MCP server in front of the order system and wants it listed for everyone. Each request is reasonable. Together they mean agents now hold standing access to internal systems, and nobody can produce one list of which agent can call which tool with whose credentials.

The trigger is usually one of three moments: an architect asks in a review "which agents can write to production today?"; an internal audit or customer questionnaire asks how AI tool use is governed and logged; or a small incident, such as an agent posting in the wrong customer channel or a token found in a shared config file.

A bad week: a team asks you to approve a third-party MCP server, and you find other teams already use it. Someone asks whether its token can reach the HR system, and the answer sits in config files on laptops you cannot see. You are asked for 30 days of agent activity, and the only logs are whatever each client kept. Then someone says "just block it", and blocking it breaks a workflow a VP depends on.

What you want is one process instead of four: a default path safe enough that teams take it, and a record good enough to answer the architect and the auditor from one place.

The rules and standards behind it

No single regulation says "govern MCP servers". There is a clear set of primary sources that define good practice, and they are what an auditor or architect will reach for. This section summarises them; it is not legal, regulatory or audit advice, so confirm how they apply to you with your own counsel and auditors.

The MCP specification

The MCP specification (version 2025-11-25) is the first source, because it is what your servers and clients claim to implement.

• Authorization. Authorization is optional for MCP implementations, but when a remote server supports it the rules are firm. A protected MCP server acts as an OAuth 2.1 resource server and must publish OAuth 2.0 Protected Resource Metadata (RFC 9728). Clients must implement Resource Indicators for OAuth 2.0 (RFC 8707) and send the canonical URI of the MCP server, so the token is bound to the server it was issued for. Implementations using the STDIO transport should not follow this part and take credentials from the environment instead, which is why local servers so often carry long-lived tokens in config files.
• Security best practices. The companion page names the attacks that matter: the confused deputy problem, token passthrough, server-side request forgery, session hijacking, local MCP server compromise and poor scope design. It says token passthrough is "explicitly forbidden" by the authorization specification, because the server cannot tell clients apart, downstream logs show the wrong identity, and audience-based controls are bypassed. On scopes it recommends a minimal initial set with incremental elevation when a privileged operation is first attempted.
• Tools. The tools section says that for trust and safety "there SHOULD always be a human in the loop with the ability to deny tool invocations." Servers must validate tool inputs, implement access controls, rate limit invocations and sanitise outputs. Clients should confirm sensitive operations with the user, show tool inputs before calling, validate results before passing them to the model, set timeouts and log tool usage for audit. Clients must treat tool annotations as untrusted unless they come from trusted servers.

Every client-side "should" here is something your organisation inherits the moment an assistant connects to an internal server. Enforce it centrally or rely on each team.

OAuth security practice

RFC 9700, the Best Current Practice for OAuth 2.0 Security (January 2025), section 2.3, says access token privileges should be restricted to the minimum required and tokens should be audience restricted to the resource they are meant for. RFC 8707 (February 2020) defines the resource parameter that makes that possible. Together they turn "one token per server, narrow scopes" from a preference into documented practice.

Zero trust

NIST SP 800-207, Zero Trust Architecture (August 2020), sets the principle you apply to agents: no implicit trust from network location or ownership, with authentication and authorisation performed before a session to a resource is established. An agent inside the corporate network is not trusted because of where it sits. Each tool call is a request to a resource and is decided on its own.

AI risk frameworks

The NIST AI Risk Management Framework (AI RMF 1.0, released 26 January 2023) organises AI risk work into Govern, Map, Measure and Manage, and NIST AI 600-1, the Generative AI Profile (26 July 2024), is its companion for generative systems. Both expect you to know which AI systems you run, who is accountable and how you monitor them; an inventory of agents and their tools is the most direct evidence. CISA, the NSA, the FBI and partners published "AI Data Security" best practices on 22 May 2025, which cover data used to operate AI systems.

OWASP guidance

The OWASP Top 10 for LLM Applications 2025 has two entries that read like an MCP risk register. LLM01 Prompt Injection covers indirect injection, where content from external sources such as websites or files changes the model's behaviour; a tool result is such a source. LLM06 Excessive Agency names three root causes, excessive functionality, excessive permissions and excessive autonomy, and its mitigations include minimising extensions and their permissions, avoiding open-ended extensions, executing in the user's context, requiring user approval and complete mediation. OWASP's Top 10 for Agentic Applications for 2026 is a useful second checklist when you review an agent design.

How teams do it today and where it breaks

Most enterprises go through three phases. Knowing which one you are in tells you what to fix first.

Phase one: every team for itself. Teams connect assistants to whatever they need. Local STDIO servers run on laptops with personal tokens in environment variables. Remote servers are added by URL. Nobody keeps a list. It breaks the moment anyone asks which agents can write to production, because tokens are broad and shared, logs live in each client, and revoking access means finding every place a token was pasted.

Phase two: an allowlist and a review form. The platform team publishes approved servers and a request form, and security reviews each server once. It breaks because servers change after review: a server that exposed read tools at intake adds a write tool later, and the list still says "approved". The list also says nothing about which agent may use which tool, and it produces no log of calls.

Phase three: a policy point in the path. The platform team puts a proxy between agents and servers, registers each server and agent, and writes rules per tool. Every call is decided and logged. It still breaks if rules start broad and are never tightened, if unmatched traffic is silently allowed, if laptops stay invisible, or if nobody reads the logs.

Step by step, with or without Safeguard

These steps work with any tooling, ordered so each makes the next easier.

1. Build the inventory before you write a rule

You cannot scope what you have not listed. Keep two inventories.

MCP servers: name, owner team, where it runs (local STDIO, internal remote, vendor-hosted remote), transport, the systems it reaches, how it authenticates upstream, and the tools it exposes today. For remote servers, call tools/list and store the result with a date, because it will change.

Agents: name, owner, the assistant or framework it runs on, whether it acts for a person or as a service, the environments it touches and the servers it connects to.

Two sources will surprise you: laptops, where coding agents carry their own MCP server configs, and repositories that import AI SDKs or ship MCP server configuration. A minimal intake record you can paste into a ticket today:

2. Classify tools, not servers

A server is not safe or unsafe; its tools are. Sort every tool into a tier and set the default handling per tier.

This table is the most useful artifact you will produce. It turns "is this server approved?" into "which agents get which tiers?", a question you can answer the same way every time.

3. Fix authentication at the server

For remote servers you own, implement the MCP authorization flow: OAuth 2.1 resource server, Protected Resource Metadata, and validation that each token was issued for this server. Never pass a client's token through to a downstream API; give the server its own credential per downstream system, scoped to what its tools need. For third-party servers, ask the vendor whether the server validates token audience, whether it passes client tokens downstream, and what scopes it requests. For local STDIO servers, narrow what the environment holds: one token per server, short lifetimes where possible, never a personal admin token.

4. Put a policy point in front of the calls

There are three places to decide a call. Inside the client: the Claude MCP connector in the Messages API, for example, can enable all tools, allowlist some or denylist others, but each team configures its own. Inside the server: fine for servers you own. In the path: a proxy sees every call regardless of client or server author, so it is the one place to apply a single policy to servers you do not control, and to log it.

5. Write rules in the order they are evaluated

Write rules as data. Each says what it matches (method, tool name pattern, agent), what it does (allow, deny or monitor) and what it filters (input checks, output masking, row and rate limits). Start each new server in monitor, watch a week of traffic, then promote rules. Make sure unmatched traffic is flagged, not silently allowed. A starter order:

1. Deny admin and credential tools for every agent.
2. Deny hard-to-reverse write tools except for named agents, and require client confirmation by a person.
3. Allow sensitive read tools with PII masking, a row limit and a rate limit.
4. Allow low-sensitivity read tools for approved agents.
5. Monitor everything else.

6. Give each agent its own identity

Shared bot accounts make every log entry useless. Each agent should present its own identity, so rules can target it, activity accumulates against its own record, and you can stop one agent without stopping the rest. Where an agent acts for a person, record which person.

7. Log every decision and read the logs

Each call should produce a record of agent, server, tool, decision, matching rule and any masking applied, kept for a defined period. Alert on the signals that mean trouble: a rise in denies for one agent, a spike in prompt-injection scores, or an agent calling a tool for the first time.

8. Gate the code that becomes an MCP server

An internal MCP server is software with dependencies and licences, and it usually holds production credentials. Put the same SCA, SBOM and CI gates on MCP server repositories that you put on any such service.

Questions platform owners ask

Should we allow local STDIO servers at all?

Usually yes for developer tools, with limits: an approved list per agent, narrow tokens in the environment, and an inventory taken from the devices. The MCP authorization flow does not apply to STDIO, so your controls are the token you issue and your visibility on the laptop.

Who approves a new MCP server?

The owning team proposes it with the intake record. The platform team classifies its tools. Security reviews the two write tiers and above. Nobody approves a server as a whole; they approve tool tiers for named agents.

What should a human approve in the moment?

Anything in the hard-to-reverse tier. The MCP tools section expects a human who can deny a call, and client confirmation prompts are where that happens. A policy point can deny or monitor; it does not replace the person who says yes to a refund.

How do we keep prompt injection from turning into tool calls?

You cannot stop the model reading hostile text, because tool results are text. You can limit what a hijacked agent can do: narrow tool scope, deny hard-to-reverse tools by default, check inputs for known injection phrasing, mask sensitive output and rate limit. Read OWASP LLM01 and LLM06 together: reduce the chance of injection and its blast radius.

Illustrative scenario: a composite insurer rolls out agents to five teams

This is a composite example built for this post, not a customer. The company, its teams and its details are invented, and any number below is an example input, not a result.

The company. "Larkspur Mutual" is a fictional US insurer. Its AI platform team runs the approved assistants and a model gateway. Five teams want agents connected to internal tools: claims operations, customer support, finance operations, developer productivity and data engineering.

What the first inventory finds. A laptop sweep shows coding agents connected to local servers for the issue tracker, the wiki and a database client. A code search finds two internal MCP servers, one in front of the claims system and one in front of the policy document store. Support has connected a vendor-hosted server for its ticketing tool. None of these is on an approved list.

How the team classifies tools. The claims server exposes read a claim, search claims, add a claim note and approve a payment. Reads go in the sensitive read tier, the note in reversible write, and payment approval in the hard-to-reverse tier. The policy document server is low-sensitivity read. The ticketing server has reads, a reply tool and an assignment tool.

What the rules look like. Admin and credential tools are denied for every agent. Payment approval is denied for all agents, to be revisited after a quarter of monitored use of the other tools. Claims and support agents get claims reads with PII masking and a row limit. Only the claims agent gets "add a claim note", rate limited. The support agent gets ticket read and reply, with reply monitored for the first month. Unmatched traffic is monitored.

What changes for teams. Developers keep local servers, with narrow per-server tokens instead of personal admin tokens. Teams on remote servers point agents at a proxy URL instead of the server URL.

What the platform team reviews weekly. Denies by agent and rule, monitored calls on write tools, new tools on registered servers, and agents calling a tool for the first time. Each finding becomes a rule change, a tier change or a conversation with the owner.

What the auditor gets. The inventory, the tool tier table, the current rules and a query of the decision log for the audit period.

How Safeguard does this

Safeguard covers the inventory, the policy point, agent records, the decision log and the CI gate for MCP server code. Each step links its docs page. Commands and requests appear as the docs show them; we did not run them for this post.

A naming note first. The offering calls the MCP control layer MCP Guardrail (GA). The docs describe it as Guard, with pages for servers and agents, policies, the proxy, the audit trail and webhooks. This walkthrough uses both names for the same thing.

1. See what agents and MCP servers are already on laptops

AI agent discovery (GA) runs inside the Safeguard CLI and the Safeguard Desktop app. It detects the supported AI coding agents on a computer and reports, per device and person, what each agent may do, the MCP servers it is connected to (with transport and tools seen in use), the skills and plugins installed into it, the models it uses, the credentials it refers to by name only, and its activity from the agent's own session files. Results appear under Assets › Inventory › Asset discovery, with tabs for agents, models, skills and plugins, MCP servers and devices.

The privacy defaults matter for an enterprise rollout. Environment and header values are never read, only their names. Credential values are never read or sent. Prompts, responses and full tool inputs are not collected unless Safeguard enables prompt capture for the organisation, the administrator turns it on and the person separately agrees. An administrator turns the feature on and sets the collection policy, and each person allows it on their own computer. The docs show these CLI commands:

safeguard aidr collect status # your organisation's setting, your choice, the last delivery
safeguard aidr collect on # read the notice and allow it
safeguard aidr collect show # print exactly what the next run would send (nothing is sent)

Docs: AI agent discovery.

2. Find MCP servers and AI assets in code and cloud

AI-BOM discovery (GA) inventories AI assets across code, cloud and connected SaaS. In code that includes AI SDK imports, prompt templates, notebooks and MCP server configuration, assembled per product into an AI-BOM, a tenant-scoped snapshot of your AI footprint. This is how the two internal servers in the scenario would surface from repositories rather than from memory.

Docs: AI-BOM Discovery.

3. Register each remote MCP server and each agent

MCP Guardrail keeps MCP servers and agents as first-class records, so policy can target them, agents can be blocked or quarantined, and audit events reference them by name and ID. Servers are registered explicitly with a name, upstream URL, transport (sse or http) and how Guard authenticates upstream (none, bearer, basic or api_key). The docs show registration through the Guard management API:

curl -X POST https://<your-guard-host>/api/v1/servers \
  -H "Authorization: Bearer <your-jwt>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "billing-mcp",
    "description": "Internal billing tools server",
    "upstream_url": "https://internal-mcp.example.com",
    "transport": "http",
    "auth_type": "bearer",
    "auth_config": { "token": "upstream-service-token" }
  }'

Once a server is registered and active, Guard sends it a JSON-RPC tools/list request on a schedule (every five minutes by default, per the docs) and stores the tools against that server. That is the mechanism behind "review on change": a new tool on a registered server appears without anyone filing a ticket.

Agents are registered the same way, with a name, description and metadata such as team and environment. Each agent record carries a status (active, blocked or quarantined), a running risk score, an anomaly score, request counts and a last-seen time. This is agent identity (GA) in practice: which agent holds what access, on one durable record.

Docs: Servers & Agents.

4. Put the proxy in the path

The Guard proxy is a self-hosted reverse-proxy gateway between agents and MCP servers that applies your Safeguard policy to every JSON-RPC call without changing the server's code. That makes it the route for vendor-hosted servers and servers you did not write.

A registered server is reached through a proxy URL record that binds a slug to one server and can optionally bind one agent (so calls are attributed to it for policy, risk scoring and audit) and one specific policy (overriding the organisation default for that slug). One server can sit behind several proxy URLs, for example a lenient policy for a trusted internal agent and a stricter one for everything else. Revoking a proxy URL stops new requests through it without touching the server or agent records.

Agents send JSON-RPC to the proxy path with a bearer API key scoped to the organisation. The docs show:

curl -X POST https://<your-guard-host>/p/billing-mcp/message \
  -H "Authorization: Bearer sg_live_..." \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"..."}}'

Refused calls come back as JSON-RPC errors with distinct codes for a policy deny, a blocked agent, a prompt-injection threshold hit, a rate limit and an upstream failure, so an agent framework can handle each one.

Docs: Guard Proxy Deployment.

5. Write the policy as ordered rules: allow, deny or monitor

A Guard policy is an ordered list of rules evaluated against every MCP request through the proxy. You author it in your Safeguard workspace; there is no policy file to check in. One policy per organisation is the default that Guard loads, and a proxy URL can pin a different one. Each rule matches on any combination of method (for example tools/call), tool name with glob wildcards such as support_*, and agent ID, and resolves to one action:

Rules are evaluated highest priority first and the first match wins. If no rule matches, or the organisation has no default policy yet, Guard flags the request for monitoring rather than silently allowing or blocking it: the "default to monitor" posture, built in.

Rules can carry input filters that run before the tool executes (block a parameter pattern, cap input length, reject invalid encoding, check for known prompt-injection phrasing) and output filters on the response (mask common PII patterns, redact named columns, cap rows, mask a regular expression), plus a rate limit and jailbreak and anomaly thresholds. Here is one rule from the docs' example policy, exactly as shown:

{
  "id": "block-jailbreak-support-tools",
  "name": "Block jailbreak attempts against support tools",
  "description": "Deny anything that looks like a prompt-injection attempt on customer-support tool calls",
  "action": "deny",
  "deny_reason": "Request blocked: matched jailbreak/prompt-injection pattern",
  "match_methods": [ "tools/call" ],
  "match_tools": [ "support_*" ],
  "input_filters": [
    { "type": "jailbreak_check" },
    { "type": "max_length", "max_length": 8000 }
  ],
  "jailbreak_threshold": 0.75,
  "priority": 100
}

Edits propagate without a deploy, because the proxy pulls the live policy in the background. If an instance cannot reach Safeguard, it keeps enforcing the last policy it fetched rather than failing open or closed. Two details from the docs belong on a sticky note: rules with equal priority have no guaranteed order, and unrecognised fields are ignored rather than rejected, so a typo such as match_tool silently does nothing.

Docs: Guard Policies.

6. Block or quarantine one agent

Guard has block, unblock and quarantine actions on the agent record, so stopping one agent needs no policy rewrite. Use them for an immediate response and policy for standing rules.

7. Read the decision log and alert on what matters

Every request Guard evaluates, allowed, denied or monitored, goes to an append-only audit trail: agent, server and proxy URL, method and tool, decision, the matching rule and deny reason, risk, jailbreak and anomaly scores, PII types detected, fields redacted and timing. Retention is 90 days by default and configurable per deployment. You can query by action, method and date range, which is exactly what an auditor asks for: every deny in the period, with the rule behind it. Alert rules on signals such as a rising jailbreak score, anomaly score or blocked-request ratio can be delivered to your endpoint as signed webhooks.

Docs: Audit Trail & Alerts and Guard Webhooks.

8. Apply the same discipline to Safeguard's own MCP server

If teams connect assistants to Safeguard itself, the Safeguard MCP server (GA) follows the same least-privilege pattern. Tools are gated per tenant with a feature flag per tool. A new workspace starts with a small default set of read-only tools, and every other tool, including ones that start a scan or add an integration, stays off until an administrator enables it under Feature Flags. Discovery and execution resolve from the same source, so an assistant cannot see a tool it cannot call or call one it cannot see, and if resolution fails the server falls back to the small default set.

Authentication is OAuth 2.0 where the client supports it, or an MCP key from Settings → Developer for clients that can only send a fixed header. The assistant acts as the person who connected it, within that person's role. The docs say a revoked MCP key stops working within a minute.

Docs: MCP Integrations and Tool availability and gating.

9. Set per-tool permissions when Griffin calls external MCP servers

Search Connectors (GA) let Griffin call tools on external MCP servers during a search conversation. A connected connector's tools are grouped into interactive, read-only and write or delete categories, and each tool or category is set to Always allow, Needs approval (the default) or Deny. Tokens and authorisation headers are encrypted at rest and not displayed back. It is the tool tier table, applied to Safeguard's own agent.

Docs: Search Connectors.

10. Check prompts and responses with the AI Gateway

The AI Gateway (GA) checks prompts for direct injection, indirect injection in retrieved or tool-supplied content and jailbreak patterns, and checks responses for sensitive data leaving in the output and for schema violations. Monitor mode is the default; enforce mode is a per-tenant opt-in. Guard decides tool calls; the gateway looks at what goes to and comes back from the model.

Docs: AI Gateway (LLM Firewall).

11. Gate the MCP server code in CI

Treat MCP server repositories like any service: SCA and SBOM generation (GA) on every build, and policies and gates (GA) that decide whether it passes. A failed policy does one of three things to the gate:

Exceptions are requested against the policy and finding with a justification and an expiry date, and an approver decides. In CI, the docs show safeguard ci scan --wait --fail-on-gate <gate> failing a job when the gate fails.

Docs: Policies & Gates.

Requirement, what Safeguard does, what you still own

What to measure

Measures to track, not outcomes we are claiming. Pick the ones you can collect and review them on a fixed cadence.

• Share of MCP servers in use that are registered, compared with what the laptop and code inventories find.
• Share of agents with their own identity rather than shared accounts or personal tokens.
• Share of tools classified into a tier.
• Hard-to-reverse write tools any agent can call without a human approval step.
• Share of traffic decided by an explicit rule rather than the monitor fallback.
• Denies per week by agent and rule, and how many led to a rule change.
• Time from a new tool appearing on a registered server to that tool being classified.
• Time from "stop this agent" to the agent being blocked.
• MCP server repositories with SCA and a CI gate, and open exceptions past their expiry.

What Safeguard does not do

• Guard does not find MCP servers on your network by itself. The docs say server and agent records are created explicitly; what Guard automates is tool discovery once a server is registered. AI agent discovery and AI-BOM discovery surface candidates on devices and in code, and someone still registers them.
• Guard does not check tool names and descriptions for hidden instructions. The docs state that tool-poisoning detection on a tool's own name and description is not available yet. Review descriptions at intake and whenever the tool list changes.
• The proxy's SSE stream does not run the full request pipeline. Output filtering applies to server-sent events, but deny rules, rate limits and injection checks run on JSON-RPC calls posted to the message path.
• There is no Guard SDK package to install today. The MCP docs say none is on public registries, so this walkthrough uses the proxy. Do not install any public package that claims to be it.
• It does not fix authentication in servers you own. Implementing OAuth 2.1, Protected Resource Metadata and audience validation in your own servers is your engineering work.
• It does not decide what is acceptable. Safeguard records and enforces your rules. Which tools are acceptable, which agents get which tiers and who approves a payment are your decisions.
• Tool gating on Safeguard's own MCP server is per tenant, not per user. Per-agent control is a Guard feature for your own servers.
• AI agent discovery covers its supported agents only, and only on devices where the person has allowed it.

Common mistakes

• Approving servers instead of tools. An approved server with one dangerous tool is a dangerous approval.
• Leaving unmatched traffic allowed. Default to monitor while tuning, and track how much traffic still falls through.
• One shared identity for every agent. It makes the log useless and "stop this agent" impossible without stopping all of them.
• Passing user tokens through to downstream APIs. The MCP specification forbids it.
• Reviewing once at intake. Tool lists change; re-review on change.
• Ignoring laptops. Local STDIO servers are where the broadest tokens live.
• Equal rule priorities and typo'd fields. Neither raises an error. Test each new rule in monitor before relying on it.
• Treating a deny rule as the human in the loop. A rule stops a call; it does not approve one.

FAQ

What is MCP server security?

The controls that decide which AI agents can connect to which MCP servers, which tools they can call, with what credentials, and how each call is recorded: an inventory, per-agent tool scope, a policy point in the call path and an audit trail.

Does the MCP specification require OAuth?

Authorization is optional, but when a remote server supports it the server acts as an OAuth 2.1 resource server and must publish Protected Resource Metadata, and clients must use resource indicators so tokens are bound to that server. STDIO servers take credentials from the environment.

What is token passthrough and why is it forbidden?

It is when an MCP server forwards a client's token to a downstream API without checking it was issued for the server. The MCP security guidance forbids it because it bypasses audience-based controls and breaks the audit trail.

Should agents have their own identities?

Yes. A distinct identity lets rules target the agent, lets activity accumulate against one record, and lets you block one agent without affecting the rest.

Is a client-side tool allowlist enough?

It helps, but it is configured per client and per team. A proxy in the call path applies one organisation policy to every client and server, including servers you did not write, and logs each decision centrally.

How does Safeguard's MCP Guardrail decide a tool call?

It evaluates the call against the organisation's default policy, or a policy pinned to the proxy URL, highest priority rule first. The first matching rule applies allow, deny or monitor; if nothing matches, the call is flagged for monitoring.

Can Safeguard find MCP servers on laptops?

AI agent discovery in the Safeguard CLI and Desktop app reports the MCP servers each supported coding agent is connected to, once the organisation turns it on and the person allows it. Guard itself does not create server records automatically.

How is a Guard policy different from a CI gate?

Guard policies decide live MCP tool calls with allow, deny or monitor. CI gates decide whether a build passes with Block, Warn or Notify, and approvals run through exceptions.

Related reading

• Building an inventory of MCP servers for an enterprise program
• Scoped credentials per MCP server
• An enterprise MCP registry onboarding process
• MCP server permissions: a practical checklist for reducing blast radius
• MCP tool poisoning attacks

The MCP servers your teams build are services with open source dependencies like any other, so their exposure depends on how fast fixes reach production. The block below explains how Safeguard closes that gap for the components inside those servers.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo connects Claude to the Safeguard MCP server with OAuth and shows choosing which tools Claude can use. It is the tool tier idea in practice: an assistant gets the tools you decide, not everything the server offers.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repo. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. That is what a human in the loop looks like for an agent that can change code.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. It shows an approval step for a sensitive action reaching the responsible person wherever they are.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• MCP specification 2025-11-25: Security Best Practices
• MCP specification 2025-11-25: Authorization
• MCP specification 2025-11-25: Tools
• RFC 9700: Best Current Practice for OAuth 2.0 Security
• RFC 8707: Resource Indicators for OAuth 2.0
• NIST SP 800-207: Zero Trust Architecture
• NIST AI Risk Management Framework
• NIST AI 600-1: Generative AI Profile
• CISA: AI Data Security best practices (22 May 2025)
• OWASP LLM01:2025 Prompt Injection
• OWASP LLM06:2025 Excessive Agency
• OWASP Top 10 for Agentic Applications for 2026
• Anthropic: MCP connector (Claude API docs)
• Safeguard docs: AI agent discovery
• Safeguard docs: AI-BOM Discovery
• Safeguard docs: Guard Servers & Agents
• Safeguard docs: Guard Policies
• Safeguard docs: Guard Proxy Deployment
• Safeguard docs: Guard SDK
• Safeguard docs: Audit Trail & Alerts
• Safeguard docs: Guard Webhooks
• Safeguard docs: MCP Integrations
• Safeguard docs: Tool availability and gating
• Safeguard docs: Search Connectors
• Safeguard docs: AI Gateway (LLM Firewall)
• Safeguard docs: Policies & Gates
• Safeguard: MCP Server Security use case

To try it, download Safeguard or start with the documentation.

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.