Book a walkthrough
ColossalX
Sign inBook a walkthrough

ControlColossalX MCP Firewallx, held

MCP security: decide which tools each agent may call.

The ColossalX MCP Firewall sits on the tool-call path: it denies by default, checks arguments and catches poisoned tool descriptions before agents act.

How it works

Specs

ColossalX MCP Firewall, in detail

Delivery and data

Delivery
SaaS, from one login.
Isolation
Each customer runs in an isolated workspace with its own database.
Certifications
None held. Frameworks are mapped to and assessed against.

Frameworks

OWASP MCP Top 10
Covered in probes and scans: MCP risks in probes and scans.
OWASP Top 10 for Agentic Applications
Assessed per agent against: Tool misuse (ASI02), assessed per agent.
See the frameworks

Last reviewed 6 Oct 2026

Tool calls · through the gatewayIllustrative

Tool calls · through the gateway: support-bot to ColossalX (tool call); repo-agent to ColossalX; ColossalX to files-mcp (allow); ColossalX refused before tickets-mcp (poisoned); ColossalX to crm (monitor).

In shortMCP securityMCP security protects the tools AI agents reach through the Model Context Protocol: which MCP servers an agent may talk to, which tools it may call, with which arguments, and whether a tool description can be trusted. It matters because an agent acts on what a tool tells it, often without a person reading along. In the glossary

The ColossalX MCP Firewall is MCP security at the AI gateway. It learns the MCP servers your agents reach from real requests, refuses any tool call no rule allows, inspects arguments with built-in checks, scans tool descriptions for poisoning and pins tool definitions. A named person decides each server, and the reason stays on record.

A poisoned tool description tells an agent to read secrets and send them out.

ColossalX refuses tool calls no rule allows, flags the poisoned description, and a person decides each server.

How it works

From a tool call to a decision, before it runs.

A tool whose description tells the agent to read secrets: scanned, refused and decided by a named person, before the call ever reaches the server.

Workflow · a poisoned tool, refusedIllustrative

01 Tool offered

An MCP server offers a tool whose description instructs the agent.

02 Description scanned

The scanner reads the description first and names the technique.

03 Call refused

No rule allows the tool, so the call is refused.

04 Server decided

A named person blocks the server; the reason stays on record.

What you see

MCP servers, learned from real requests.

Each server your agents reached, the tools it offered, the agent that first brought it and the decision a person made on it.

  1. Learn the serversServers are learned from real requests, not added by hand.
  2. Deny by defaultRules allow, monitor or block a tool; no rule means refused.
  3. Check the callBuilt-in checks inspect arguments; descriptions are scanned for poisoning.
  4. Decide and recordA person approves or blocks each server, with the reason kept.
Read the detail, step by step4
  1. Learn the servers. ColossalX records which MCP servers your agents reach, which agent first brought each one, which tools it offered and who reached it.
  2. Deny by default. Tool rules map a name or a pattern to allow, monitor or block, for one agent or for all agents. Each change to a rule keeps a reason.
  3. Check the call. The tool description scanner looks for hidden instructions, data exfiltration and privilege escalation, and names the technique it found. A rule tester shows the decision before anything goes live.
  4. Decide and record. Access an agent needs for a while is granted just in time: one agent, one tool, until a date, approved by someone other than the requester.
The MCP Servers view in a demo workspace: servers learned from real agent requests, how many are approved, awaiting a decision or blocked, the tools each one offered and the agent that first brought it.
From a demo workspace
3notes
  1. Servers awaiting a decision
  2. Default for undecided servers
  3. Agent that brought it

How it connectsx, held

Where a refused tool call goes next.

A refusal is a record, not a dead end.

  1. The agent's page

    Refused tools show on the agent's page, with a way to ask for time-boxed access.

  2. Just-in-time access

    One agent, one tool, until a date, approved by someone other than the requester.

  3. Alerts

    An unapproved MCP server raises an alert in the inbox, by email, webhook or SIEM.

  4. Measured in testing

    Authorised attacks run through the gateway, so whether the firewall held is measured.

Honest by design

What it does, and what it does not.

Rule tester · before it goes liveIllustrative

Rule tester · before it goes live: support-bot to crm · lookup_customer, "lookup_customer(customer_id: "C-1042")". Checks: Tool rule passed, Built-in argument checks passed, Description scanner waiting. Verdict: held, Unanswered, not allowed.

What it does not do

x, not measured

Only namespaced tool names, such as server__tool, can be attributed to a server: a floor, not a census.

All 4 limits
  • Argument checks are the gateway's built-in checks; rules written on screen do not yet add their own.
  • If the rule store cannot be read, tool calls are allowed and recorded. It does not fail closed.
  • Description scanning names the techniques it finds; it cannot prove a description is safe.

How we know

  • The MCP server inventory is learned from real requests. Nothing is added by hand.
  • The rule tester reports an unanswered check as unanswered, never as allowed.
  • Red-team runs attack agents through the gateway, so the firewall's result is measured.

Questions

Questions buyers ask

What is MCP security?

MCP security is the protection of the tools AI agents reach through the Model Context Protocol: which MCP servers an agent may talk to, which tools it may call, with which arguments, and whether a tool's description can be trusted. It matters because an agent acts on what a tool tells it.

What is MCP tool poisoning?

MCP tool poisoning is an attack in which a tool's name or description carries instructions meant for the agent, such as reading secrets or calling another tool. The agent may follow them because it treats the description as trusted. ColossalX scans tool descriptions for this before an agent acts on them.

What does an MCP gateway do?

An MCP gateway sits between agents and the MCP servers they call, so tool calls can be seen, checked and decided in one place. In ColossalX that place is the AI gateway: tool calls are checked against firewall rules, and the servers agents reach are learned from real requests.

How does ColossalX decide which MCP tools an agent may call?

Tool rules match a tool name or pattern to allow, monitor or block, for one agent or for all. With no matching rule the call is refused. Built-in checks inspect arguments, and a just-in-time grant can open one tool for one agent until a date, approved by a second person.

How does ColossalX cover the OWASP MCP Top 10?

OWASP MCP Top 10 risks are covered in ColossalX probes and scans, alongside the OWASP LLM Top 10 (2025), and repository scans check MCP client configuration. This is coverage in testing and scanning, not a certification of your MCP servers.

Related

Where to look next.

Next step

Know your x.

See the ColossalX MCP Firewall on your own agents: the servers they reach and the tools refused.

Book a walkthrough Email us instead
  1. 01Tell us what you run
  2. 02See the four verbs on it
  3. 03Decide where to start