Governance and Safety for Claude Skills and MCP Servers

The moment you give an agent tools, you have given it the ability to act in the real world — to read data, write records, send messages, move money. That is exactly what makes Claude with Skills and MCP servers useful, and exactly what makes it a governance problem. A chatbot that gives a wrong answer wastes a minute. An agent with a misconfigured MCP server that gives a wrong answer can delete a record, email a customer, or touch production. Before you scale, leadership needs guardrails that make the powerful version safe — not by slowing everyone down, but by making the dangerous things hard and the safe things easy.

The new attack surface

Connecting Claude to your systems via MCP creates a surface that didn't exist before, and it has three distinct edges. The first is over-broad tool access: an MCP server that exposes a whole database when the task needed one table, or write access where read would have done. Every capability you grant is a capability that can be misused — by a confused model, a bad prompt, or an attacker who finds a way to influence the input.

The second edge is prompt injection through tool results. When an agent reads data from an external source — a web page, a support ticket, a document — that data can contain instructions aimed at the model. If your agent will dutifully follow text it just fetched, an attacker who controls any input the agent reads can try to redirect it. This is the single most underappreciated risk in tool-using agents, and it gets worse as you connect more sources.

The third edge is the confused-deputy problem: the agent has more authority than the person asking it to act, so a user can get the agent to do things they couldn't do themselves. If your MCP server runs with admin credentials and any employee can prompt it, you've effectively given everyone admin through a side door.

The guardrails that matter

Good governance for agentic systems is a defense-in-depth stack, not a single gate. The cheapest and most effective layer is least privilege: every MCP server gets the narrowest scope that does the job, read-only wherever possible, and destructive actions gated behind explicit confirmation. The second layer is human-in-the-loop on consequential actions — the agent proposes, a person approves, for anything that touches money, customers, or production. The third is audit logging of every tool call, so that when something goes wrong you can reconstruct exactly what the agent did and why.

flowchart TD
  A["Agent wants to call a tool"] --> B{"Within granted scope?"}
  B -->|No| C["Deny & log"]
  B -->|Yes| D{"Destructive or high-value?"}
  D -->|No| E["Execute, log result"]
  D -->|Yes| F["Pause for human approval"]
  F -->|Approved| E
  F -->|Rejected| C
  E --> G["Audit trail + monitoring"]

Notice what this flow does and doesn't do. It doesn't try to make the model perfectly safe — that's not achievable. Instead it puts deterministic checks around an inherently probabilistic actor. The scope check is enforced by the server, not trusted to the model. The approval gate is a human decision, not a prompt. The audit trail is written regardless of what the model intended. Governance works by not relying on the agent to police itself.

A definition worth pinning down

Agentic governance is the set of technical and organizational controls that bound what an AI agent is permitted to do, ensure consequential actions are authorized, and create an auditable record of every action it takes. The emphasis on technical matters: a policy document that says "the agent shouldn't delete production data" is worth nothing if the MCP server has delete permissions. Real governance is enforced in the credentials and the code paths, with policy as the explanation, not the mechanism.

Containing prompt injection

Because tool results can carry hostile instructions, you need specific defenses, not general caution. The strongest is the same least-privilege principle: if the agent reading untrusted web content has no ability to send email or touch your database, the worst an injected instruction can do is make the agent say something silly. Separating the agent that handles untrusted input from the agent that holds powerful credentials — so the powerful one never reads raw external text — is one of the most effective architectural defenses available.

Beyond isolation, treat all tool-returned content as data, not commands. Instruct the agent explicitly that text fetched from external sources is information to reason about, never instructions to follow. Keep a human in the loop for any high-consequence action that follows the reading of untrusted content. None of these is bulletproof alone; together they shrink the blast radius dramatically.

What leadership actually has to decide

Most of governance is not technical — it's a set of decisions only leadership can make, and making them explicitly is what prevents chaos later. Which categories of action can an agent take autonomously, and which always require a human? What data is an agent never allowed to touch? Who is accountable when an agent does something wrong — the person who ran it, the person who built the Skill, or the platform team? Who can publish a new MCP server to the shared environment, and what review does it pass first?

Teams that answer these before scaling move fast safely, because everyone knows the boundaries. Teams that skip them either move recklessly until an incident forces the conversation, or freeze entirely out of fear. The goal of governance is not to say no; it's to make yes safe, by pre-deciding where the lines are so that day-to-day work doesn't require a risk debate every time.

Frequently asked questions

What's the single most important guardrail?

Least privilege on MCP servers. If every server has the narrowest possible scope and destructive actions are gated, most of the catastrophic failure modes simply can't happen, regardless of what the model does. It's the highest-leverage control because it's enforced by credentials, not by trusting the agent's judgment.

How do we defend against prompt injection?

Architecturally, not just behaviorally. Keep the agent that reads untrusted external content separate from the one holding powerful credentials, treat all tool-returned text as data rather than commands, and require human approval for consequential actions taken after reading external sources. Defense in depth shrinks the blast radius.

Do we need a full audit log from day one?

Yes. Logging every tool call is cheap to add early and nearly impossible to reconstruct after an incident. The first time something goes wrong, the audit trail is the difference between a five-minute diagnosis and a week of guesswork — build it before you need it.

Should we let any engineer publish MCP servers?

Not to shared production environments. A light review — checking scope, credentials, and error handling — before a server joins the shared catalog prevents the most common mistakes. Personal experimentation should be free; anything others will depend on should pass a gate.

Bringing agentic AI to your phone lines

Governed autonomy matters even more when the agent talks to customers directly. CallSphere applies these guardrails to voice and chat — assistants that answer every call, use tools mid-conversation, and act only within bounded, auditable scopes. See it live at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.