SecOps / Security for AI
MCP and tool security: control what agents can call
Every tool an agent can call is an attack surface and a privilege. Treat the tool layer like production infrastructure, because it is.
The Model Context Protocol made it easy to give an agent hands. That is also the risk: a connected server can read data, change systems and, through its tool descriptions, speak directly into the model's context. Tool security is where the agent's authority becomes real.
The problem: tools multiply faster than anyone reviews them
Teams add MCP servers the way they once added browser extensions: one at a time, each with a good reason, none with a review. A server may come from a public catalogue, a vendor or a colleague's repository. It runs with whatever credential it was handed, and its descriptions, schemas and outputs are read by the model as if they were trustworthy.
Four failure modes recur. Tool poisoning hides instructions in a tool's description or output so the agent behaves differently than the user expects. Excess privilege gives a server a broad token because a narrow one was harder to set up. Confused deputy problems arise when a server forwards a user's token to a downstream API that never intended to trust it. And a changed server, silently updated after approval, becomes a supply-chain compromise inside the agent's trusted perimeter.
The MCP authorization specification addresses the first half of this. It builds on OAuth 2.1, requires resource indicators so a token is bound to a specific server, requires servers to validate that a token was issued for them, and forbids token passthrough, where a server accepts a token meant for something else and passes it on. Those are protocol-level requirements. Whether your deployment follows them, and what happens at the tool boundary regardless, is an operational question.
How the tool layer is designed to be governed
The design is a control plane in front of the tools, so policy applies to every agent without rewriting each one. Today Swfte's MCP gateway checks a per-server API key scope and logs each call (method, status and latency). The items below that go further, such as per-tool policy, version pinning and caller-level audit with SIEM export, are designed for and not shipped. The MCP gateway page states what is built.
An approved registry
Designed for: agents connect only to servers in a managed catalogue, and a new server enters through review of who owns it, what it can reach, which tools it exposes and at what version. Today you deploy MCP servers into a workspace; a review workflow is not built.
Scoped, audience-bound credentials
Today the gateway requires an API key scoped to the MCP server. The design goes further: each tool call carries a credential scoped to that tool and that caller, so that a token issued for one server is not accepted by another, and that a caller's token is never passed through to a downstream service.
Per-tool, per-principal policy
Designed for, not shipped: allow and deny rules by agent and by tool, for example that only a Finance agent may call the payments tool, with read and write tools separated and approval on write tools. Today access is decided per MCP server by API-key scope.
Description and version pinning
Tool definitions are pinned to the reviewed version. A change to a description or schema is treated as a change to the tool and goes back through review, which closes the quiet-update route.
Output handling
Tool output is untrusted input to the model. It is screened and passed as data, and size and format limits apply, which reduces the room for injection through results.
Full call audit
Designed for: every call logged with caller identity, tool, arguments, result summary, latency and policy decision, searchable and exportable to your SIEM. Built today: each gateway call is logged with the workspace, the MCP server, the method, the status and the latency. Caller identity, arguments and SIEM export are not built.
Where it sits on the platform
One platform with several entry points. Each product below plays a defined part in this capability.
| Platform entry point | Role in this capability |
|---|---|
| Connect | Governed access to external systems and tools, with scoped credentials in place of keys held by agents. |
| Nexus | In-flight policy at the tool call, supply-chain events for agent-initiated installs, and inventory of unknown non-human identities. |
| Studio | Declare which tools each agent may use, and gate write actions with approvals. |
| Trust Fabric | Access, policy, supply-chain and audit facets applied to the tool layer. |
What a tool-using agent can and cannot do
A Trust Profile for a support agent that calls MCP tools against a CRM and a ticketing system.
Support Agent 031
Answers customer queries by calling CRM and ticketing tools.
| Can | Cannot | Requires approval | Records |
|---|---|---|---|
|
|
|
|
Controlled autonomy for tool calls
Reads and writes are different risks. Autonomy can differ per tool, not just per agent.
- L1 Assist
Agent reads through approved tools and recommends. No write tools attached.
- L2 Approve
Write tools are attached; each call is approved by a person before it runs.
- L3 Supervise
Low-risk, reversible writes run within limits; thresholds and exceptions escalate.
- L4 Autonomous
Well-understood tools with hard bounds, rate limits and rollback, under sampled review.
- L5 Adaptive
Changes to tool access are proposed, tested and gated; the agent cannot grant itself tools.
The five-level model is described in full on the controlled autonomy page.
Frameworks the design is mapped to
Mappings of intent between controls and published risk lists. Not an assessment result.
| Framework | Entry | How the design addresses it |
|---|---|---|
| OWASP Top 10 for Agentic Applications (2026) | ASI02 Tool Misuse and Exploitation | Per-tool policy, argument validation and approval on write actions. |
| OWASP Top 10 for Agentic Applications (2026) | ASI04 Agentic Supply Chain Vulnerabilities | Approved registry, version pinning and review of changed tool definitions. |
| OWASP Top 10 for LLM Applications (2025) | LLM03 Supply Chain; LLM06 Excessive Agency | Provenance for tools and models, and minimised privileges for each. |
| MITRE ATLAS | AML.T0010 AI Supply Chain Compromise | Inventory and change control on the components an agent depends on. Confirm current technique IDs at atlas.mitre.org. |
EU angle: supply chain and third-party risk
Tool servers are third parties. These instruments treat third-party and supply-chain risk as a security duty.
| Instrument | Reference | Supports evidence for |
|---|---|---|
| NIS2 | Art. 21 risk-management measures, including supply-chain security | Supports evidence of how third-party tools and servers are reviewed, scoped and monitored. |
| DORA | ICT third-party risk management | Supports a register of AI tool dependencies and a record of their use, for financial entities in scope. |
| EU AI Act | Art. 15 cybersecurity | Supports evidence of controls against tampering with an AI system's components, including pre-trained components and tools. |
| GDPR | Art. 32 security of processing | Supports evidence of limits on which tools can reach personal data. |
Swfte is built compliance-by-design. It provides the technical controls, governance mechanisms and evidence required to deploy AI within an organisation's applicable regulatory, security and policy requirements. The exact posture depends on the customer's use case, jurisdiction, deployment and configuration. Nothing on this page is legal advice. Swfte's own security attestations are listed on the trust page.
What this page does not claim
- Protocol requirements describe what MCP specifies, not what every server in the wild implements. Review remains necessary.
- Pinning and review reduce supply-chain risk; they do not remove it.
- The gateway governs tool calls it carries. Direct connections made around it are outside its view, which is why inventory and egress control sit alongside it.
- Nothing here claims that your use of the platform is compliant with any regulation. Swfte's own security attestations are listed on the trust page.
Frequently asked questions
What is MCP tool poisoning?
It is hiding instructions in a tool's description, schema or output so the model treats them as commands. The user sees a normal-looking tool; the agent receives different instructions. Defenses are reviewing and pinning tool definitions, treating tool output as untrusted data and limiting what the agent can do if it is fooled.
Why is token passthrough forbidden?
If an MCP server accepts a token that was not issued for it and forwards it to a downstream API, the downstream service may trust the token wrongly, and its own rate limits, scope checks and logging are bypassed. The MCP specification requires servers to validate audience and obtain separate tokens for upstream calls.
Do we need a gateway if our servers follow the spec?
A gateway gives one registry, one policy and one audit trail across the fleet, and it covers servers that do not implement the specification well. Following the spec is necessary but does not give you fleet-wide visibility.
How do we handle servers we do not control?
Treat them as third parties: review before admitting, pin the version, scope the credential to the narrowest permission, route calls through the gateway and re-review on any change.
Where is the gateway covered in detail?
The MCP gateway page describes the primitives: registry, secrets, permission policy, audit, rate limits and observability. This page explains why each matters for security.
The rest of SecOps
Nine pages cover both halves. Each has a different job.
AI for security operations
Frameworks and evidence
Back to the SecOps hub.
Build MCP and tool security with Swfte
Start with one agent and one policy, or talk to the team about your environment, your data and your regulators.