- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2 hours ago - edited 15m ago
Your Agents Trust Every Tool They're Given. Should They?
Introducing Tool-Level Governance & Security Scanning on AI Gateway - Coming soon
The MCP ecosystem is evolving faster than anyone predicted. Servers are shipping with dozens of tools. Agents are being connected to more external systems than ever. And with that growth comes a question enterprise can no longer avoid.
"Can we have more control over the governance of a server? if we trust a server should we trust all the tools within it? What happens if a server quietly adds a malicious tool in its offering?"
The answer, clearly, is no.
We’re introducing two capabilities that move AI Gateway from server-level oversight to fine-grained, tool-aware enforcement: tool-level governance and MCP server security scanning. This post covers the why and the how.
Why Tighter Control Over MCP Transactions Is Needed
AI Gateway today lets AI Stewards approve or reject entire MCP servers, pause them globally or individually, enforce OAuth 2.1 authentication, enable PII filtering, and monitor usage and latency; all from a single control plane in AI Control Tower.
But MCP servers aren’t monoliths. A single server can expose 10, 20, even 50+ tools, each with a different risk profile. Consider a payroll server that exposes both a “view_pay_stub” tool and an “update_direct_deposit” tool. Under server-level governance, approving the server means approving both. There’s no mechanism to say: “Yes to viewing, no to updating.”
That creates real problems:
- Low-risk tools get blocked because a high-risk tool on the same server couldn’t pass review.
- High-risk tools get inadvertently approved because the server as a whole seemed safe. AI Stewards can’t express nuanced policy, it’s blanket approval or blanket rejection.
Enterprises need the ability to approve servers while selectively enabling only the tools they trust.
MCP Servers Expand the Attack Surface
Every MCP server your agents connect to is a potential entry point for adversarial behavior. The MCP protocol relies on tool descriptions & metadata that tells agents what a tool does, what parameters it accepts, and what to expect in return. Those descriptions are consumed by LLMs to decide which tools to call and how. These MCP tool metadat can be compromised to inject malicious context to the Agents, instruct & orchestrate prompt injection attacks and much more.
What happens if that metadata is compromised?
- Prompt injection via tool metadata: A malicious description can instruct an agent to exfiltrate data, override safety controls, or invoke unintended tools.
- Rug-pull attacks: A server ships clean metadata during onboarding, then changes tool descriptions post-approval to embed harmful instructions.
- Tool poisoning: Subtle instructions embedded within otherwise-legitimate descriptions, exploiting the trust agents place in server-provided metadata.
The core issue: MCP servers are not just data endpoints. They’re instruction surfaces. Every tool description is, in effect, a prompt fragment that your agents consume and act on. Without scanning those descriptions for threats, you’re running untrusted prompts inside your enterprise.
MCP Tool Level Governance on AI Gateway
Tool-level governance is coming to AI Gateway with a clear design principle: give AI Stewards granular control without drowning them in complexity.
Tool discovery and registry of tools
Before you can govern tools, you need to know what tools exist. AI Gateway will allow you to fetch a server’s complete list of tools & its metadata (names, description, schema etc.). This creates a persistent, per-server tool registry in AI Gateway which can be refreshed over time (manually & periodically). This will allow stewards to set governance policies on these tools which will govern the transactions and whats allowed to happen with each of these tools.
Selective Approval of MCP Servers at the Tool Level
When an AI Steward reviews an MCP server for approval, they’ll see the full list of tools that server exposes. Instead of a binary approve/reject on the entire server, the Steward can enable specific tools while leaving others disabled, and review tool descriptions and risk signals before making each decision.
At runtime, AI Gateway checks tool state on every call. If an agent attempts to invoke a tool that hasn’t been enabled, the request is blocked with a clear error.
Ongoing Lifecycle Management
MCP servers are dynamic, tools get added, removed, and updated. AI Gateway keeps the tool registry in sync by allowing you to refresh the tool list. AI Stewards control over how changes are handled. New tools can be auto activated or held for review, depending on the organization’s risk posture.
MCP Tool's Security Scanning
We will do a security scan of each MCP Tool & its metadata for providing AI steward with additional understanding of which tools are malicious and which ones are safe to activate.
Design-Time Scanning
When tools are first discovered during intake or refreshed later, we would scan the tools & its metadata to look for any malicious intent such as prompt injection, hidden instructions etc.
Tools flagged as potentially malicious are automatically disabled. AI Stewards see a clear notification during the approval workflow highlighting which tools were flagged and why. The Steward can override if business context warrants it, and that preference is respected in subsequent scans; hence keeping the human in the loop story intact.
Runtime Scanning
Runtime scanning extends AI Gateway’s protection to live MCP transactions, scanning tool call payloads and responses for adversarial content as they flow through the gateway. Even if a server’s behaviour changes post-approval, the gateway catches it. We would block any malicious calls or response based on the configuration set by the AI stewards and hence allowing them the final say in the actions taken.
Why Servicenow is the right place for this?
Step back and consider where enterprise AI is heading. MCP adoption is accelerating. The number of remote MCP servers in public registries has crossed 500 and is growing weekly. Agents are connecting to more systems, across more platforms, with more autonomy. Having more tighter control and systems in place to check for any adversarial attacks in going to be the need of the future to scale Agentic systems. And none of this requires a new governance silo. If you’re already using AI Control Tower, these capabilities surface in the same interface your AI Stewards and compliance teams already use. Same roles, same workflows, same audit trails. Just deeper control via AI gateway.
Curious how tool-level governance would change your current setup? Drop a comment below or sign up for a 30-minute walkthrough with us.
Safe harbor notice for forward-looking statements
This presentation may contain “forward-looking” statements that are based on our beliefs and assumptions and on information currently available to us only as of the date of this presentation. Forward-looking statements involve known and unknown risks, uncertainties, and other factors that may cause actual results to differ materially from those expected or implied by the forward-looking statements. Further information on these and other factors that could cause or contribute to such differences include, but are not limited to, those discussed in the section titled “Risk Factors,” set forth in our most recent Annual Report on Form 10-K and Quarterly Report on Form 10-Q and in our other Securities and Exchange Commission filings. We cannot guarantee that we will achieve the plans, intentions, or expectations disclosed in our forward-looking statements, and you should not place undue reliance on our forward-looking statements. The information on new products, features, or functionality is intended to outline our general product direction and should not be relied upon in making a purchasing decision, is for informational purposes only, and shall not be incorporated into any contract, and is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for our products remains at our sole discretion. We undertake no obligation, and do not intend, to update the forward-looking statements.
