Blog Posts
Read Polygraf AI's plain-English guide to LLM security for enterprise teams to understand why securing an LLM is a must have for any organization who cares about their privacy.
The 4.5x difference in security incident rates between over-privileged and least-privileged AI deployments is the most actionable data point in enterprise AI security. This is a how-to, not principles, not frameworks. Exact controls, exact configuration, exact testing.
The Teleport finding is not a gentle one. Organizations that practice least privilege for AI agents have 4.5x fewer security incidents than those that do not. Access scope – not AI model sophistication, not organizational maturity, not stated confidence – was the strongest predictor of security outcomes. And yet the same report found that 70% of enterprise agents have more access than equivalent human roles in comparable positions.
There is a gap in the implementation because MCP has no built-in least-privilege. The specification does not specify role-based access control. If an agent can connect to an MCP server, it can find every tool that server provides – by design. Clutch Security has shown that in a typical 10K people company, 1.528 people are running an average of 2 MCP servers each and 3.056 total deployments – most provisioned with Personal Access Tokens with too many permissions and never touched.
Least privilege must be implemented outside the protocol, at the gateway layer or it does not exist. This guide shows you exactly how.
The MCP specification was updated in March 2025 with OAuth 2.1 and Streamable HTTP transport and brought important improvements to authentication and transport security. It did not bring native tool-level access control. When an MCP client connects to a server, the server makes all of its tools available to that client. A finance agent can see development tools. A support agent can see database administration endpoints. A summarization agent can see file deletion functions.
This is not a mistake – it is the design principle of MCP to make the agent as powerful as possible. But it leads to a basic security problem: tool discoverability is equal to tool reachability. If an agent can see a tool, it can call it. An agent running under a poisoned instruction (ASI01) or with a compromised credential (ASI03) will call every tool it can discover.
The gateway is the enforcement layer that the MCP does not provide out of the box. It sits between the agent and the MCP server, filtering the tool manifest the agent is receiving, validating the arguments to the tool call against policy, and logging every invocation. Without a gateway, least privilege requires changing every agent, which does not scale and will break every time an agent's task changes. With a gateway, policy is centralized, auditable and enforced on all agents at once.
An MCP gateway is a reverse proxy for agent-tool communication. It proxies the JSON-RPC messages between MCP clients (agents) and MCP servers (tools) and applies policy at each layer of the exchange. Four capabilities characterize a production-quality MCP gateway:
Tool manifest filtering. The gateway intercepts the server's tool manifest when the agent connects and removes any tool the agent is not allowed to use before forwarding it. The agent never sees the full manifest, it only sees the tools declared in its policy. This is the basis of least privilege: if the agent cannot discover a tool, it cannot invoke it, no matter what instructions it is given.
Argument-level validation. In addition to filtering which tools are visible, a gateway validates the arguments of every tool call. A file-read tool that is allowed in the agent's manifest can be restricted to certain directories, a database-query tool can be restricted to certain tables, certain schemas and read-only operations. This bridges the gap between "can this agent use this tool" and "can this agent use this tool to do anything it wants."
Identity authentication and binding. The gateway authenticates the identity of the agent on every connection, checks that it is the policy for that agent and binds the session to the specific permission set of that agent. Each agent's policy is applied in isolation: revoking access from one agent does not propagate to shared service accounts.
Structured audit logging. Log every tool call with agent identity, tool name, full argument set, timestamp and response. This is the forensic layer. Without it, it is impossible to reconstruct what an agent did after an incident as the six month long breach of the OpenAI plugin ecosystem showed.
On April 20, 2026, the Center for Internet Security released the MCP Security Companion Guide, the first formal governance standard for MCP deployments. The recommendations in the guide are directly in line with the gateway-based least privilege architecture described in the guide: tool allowlisting, argument constraints, identity binding, and structured logging are the four CIS controls that it recommends for enterprise MCP deployments.
The following implementation sequence is dependency order: each step enables the next. Organizations that start with monitoring (Step 5) before identity (Step 1) are measuring permissions they do not control.
Clutch Security found that in a 10,000 person company 15.28% of the employees are running on average 2 MCP servers each – 3,056 total deployments. You can't apply least privilege to deployments you don't know about. Before you configure a single gateway policy do a full discovery.
For each agent found, record: what MCP servers it connects to, what credentials it uses, who it belongs to and what task it does. For each MCP server found, record: what tools it exposes, what permissions it has and whether those permissions are shared with other agents
Least privilege without a unique identity is useless. If three agents use the same service account, you cannot apply per-agent policies, you cannot revoke one without affecting the others, and you cannot attribute any tool call to a specific agent in your audit logs. This is the prerequisite that makes all the other steps enforceable.
Every agent should have: a unique credential (dedicated API key or SPIFFE workload certificate), a named owner team and a documented task scope. Use SPIFFE/SPIRE for short-lived certificates where feasible – credentials that expire in hours will remove the multi-month dwell times that characterise the worst MCP breaches.
Write a policy for each agent that clearly states which tools it is allowed to use. Everything that is not on the list is denied by default – the gateway will remove it from the tool manifest before the agent sees it. Start with what the agent actually needs, not what is convenient to grant.
The MCP specification was updated in March 2025 (2025-03-26) with tool annotations: four structured hint fields that describe tool behaviour: readOnlyHint (true = tool only reads data), destructiveHint (true = tool may delete or overwrite), idempotentHint (repeated calls have no additional effect) and openWorldHint (true = tool contacts external services or APIs). Use them in your gateway policy: a summarization agent should deny any tool where readOnlyHint is false or openWorldHint is true, irrespective of the tool name. Note: these are hints from the server – use them as a signal, not a guarantee, and combine them with explicit tool allowlisting.
Tool-level allowlisting prevents an agent from calling unauthorized tools. Argument-level constraints prevent an agent from using authorized tools in unauthorized ways. This is the difference between "can the agent call file_read" and "can the agent call file_read on /etc/passwd."
For each tool in the agent's allowed list, specify the argument constraints the gateway should enforce. File system tools path constraints. Table and schema constraints for database tools. Domain allowlists for email tools. API call rate limits. The CIS MCP Security Companion Guide recommends argument-level validation as a required control for any agent that has access to sensitive data.
Argument-level logging is not the same as application logging. You need to capture not only "agent called file_read" but the whole argument set, the session context, the policy that was evaluated and the response. This is the forensic layer that makes post-incident reconstruction possible.
The gateway should output structured JSON logs for every tool call. Send the logs to your SIEM with agent identity as a first class field. Create baseline behavioral models per agent (expected call frequency, expected access pattern, expected data volume) and alert on deviations. Managed MCP gateway logging latency is usually < 10ms, purpose built < 5ms p99.
Not all tool calls should be pre-approved. For high-risk operations (database writes, file deletes, external API calls, code execution) use just-in-time (JIT) provisioning of access: the agent asks for elevated access for a single operation, a human (or automated approval flow) approves it for a limited time and access is revoked automatically.
This is the agentic counterpart to JIT for access to infrastructure, now available with CyberArk's AI agent identity solution and the Agentic Identity Framework of Teleport. The main architectural requirement is that the gateway has to be able to dynamically grow and shrink an agent's permission set in a session without a session restart.
Policy configuration errors are silent. An agent that silently fails to access a tool it should have access to will find workarounds or produce degraded output – neither of which will trigger an alert. Test every policy against known-good and known-bad scenarios before promoting to production.
The MCP Delegation Gateway (AVCAD) is a research implementation for the MCP and AI Agents Hackathon under the Secure & Govern track, which shows the right testing model: deterministic results from signed delegation proofs (the same permission set always yields the same ALLOW/DENY for the same action). AVCAD is a research project and not a production enterprise gateway, but the testing methodology is the same: cryptographic proof chains make permission results completely predictable and testable before production. Test for: (1) agent can do its declared task, (2) agent cannot do operations outside its declared scope, (3) argument constraints are enforced and (4) kill switch works clean.
"It's not the AI that's unsafe. It's the access we're giving it."
— Ev Kontsevoy, CEO, Teleport · 2026 State of AI in Enterprise Infrastructure Security (February 17, 2026)Three enterprise MCP gateways are production ready as of 2026 and are each tailored for a different deployment context. The Elegant Software Solutions Enterprise MCP Gateway Implementation Guide lists these as the implementations that have been found to have addressed the specific exploit classes that were demonstrated in 2025–2026 security research.
| Gateway | Best For | Tool Allowlisting | Arg Constraints | SPIFFE/JIT | Latency (p99) |
|---|---|---|---|---|---|
| Kong AI MCP Proxy | Orgs bridging MCP to existing HTTP API infrastructure | ✓ | Partial | ✓ | <5ms |
| Azure APIM + Entra ID | Microsoft-heavy enterprises with existing Entra identity | ✓ | Partial | ✓ | <10ms |
| Operant MCP Gateway | Runtime security enforcement — blocks documented exploit classes | ✓ | ✓ | ✓ | <10ms |
| MintMCP | SOC 2 Type II certified — healthcare and financial services | ✓ | ✓ | Partial | <10ms |
| On-Premise Custom Gateway (OPA + Polygraf inspection) |
Air-gapped and classified environments — CMMC, IL4+ | ✓ | ✓ | ✓ | <100ms |
The most common objection to adding a gateway is latency. Production MCP gateways add 5–10ms per tool call for managed platforms and 100–250ms for security-scanning gateways with deep inspection depending on the inspection depth. Note: JSON-RPC batching was introduced in the 2025-03-26 spec revision but removed in 2025-06-18 – the current spec does not support batching. Design your agent workflows to avoid sequential round trips through explicit task scoping and batching.
Run this checklist after the first deployment and after every policy change. A policy that passes all tests in this list has implemented production-grade least privilege.
An MCP gateway decides which tools an agent can call. Polygraf's Behavioral Control Plane provides what a gateway cannot: semantic inspection of tool call inputs and outputs – checking if what is being sent is PII, embedded instructions, policy breaches or sensitive data patterns, at sub-100ms latency, in your security perimeter. For regulated environments where both access control and data inspection are needed, these two layers are not a replacement for each other.
Polygraf's Behavioral Control Plane is designed to work with your MCP gateway and provides semantic inspection of tool call inputs and outputs that your gateway-level access control cannot. Sub 100ms. On-premise. No data leaves your environment.
At Polygraf, we envision a future where AI augments human capabilities without compromising safety, privacy, or ethical standards. Trust in our commitment to building this future with you.
© 2026 Polygraf AI. All rights reserved.
Our Solutions 
Regulations Your download will start now.
Please provide information below and we will send you a link to download the white paper.
Data Privacy 
Data Provenance 
Content Generation