Improving enterprise security with zero-trust authorization for AI tools
Zero-Trust Authorization and Discovery for Enterprise MCP
Cryptography and SecurityArtificial Intelligence
Summary
Modern AI agents sometimes get tricked into making unauthorized actions because current security methods don’t fully protect them. The authors looked closely at several popular software tools for managing AI permissions and found they can’t properly separate human users from automated programs. They built improvements to fix these problems so companies can better control which AI tools are visible and usable based on strict permissions. Tests showed these changes stopped unauthorized access that other methods missed, making security safer without changing the core AI protocols.
What this means in practice
- •For enterprise security teams: Securely control AI tool access by enforcing strict per-tool permissions and supporting both human and service account authentications.
- •For cloud platform engineers: Enable seamless deployment of AI systems with dual-persona authorization handling and credential normalization across different identity providers.
Authors
Huan Li, Yuwei Wang, Srinivasan Manoharan
Abstract
LLM agents translate natural-language context, which may include attacker-controlled text, into privileged tool calls, so authorization must remain effective even when an agent is prompt-injected or adversarially steered. The Model Context Protocol (MCP) has become a widely adopted interface for this boundary, yet its official SDKs' authentication and authorization primitives fall short of enterprise zero-trust requirements, most acutely a dual-persona model in which one server must serve human users (corporate SSO) and automated agents (service-account credentials on a different header). We conduct a systematic gap analysis of six surveyed MCP SDKs (Python, TypeScript, Go, Rust, C#, Swift) and identify three structural shortcomings: credential extraction bound to a single Authorization header, complicating dual-persona deployment without custom middleware; the absence of pre-authentication tool discovery; and the lack of fine-grained per-tool authorization in the base SDKs. We close these gaps with composable extensions to FastMCP: cross-header credential normalization for enterprise deployments serving both human and service-account callers, cached token verification across heterogeneous IdPs, an unauthenticated metadata endpoint for credential-free registry discovery, and permission-filtered tool visibility kept consistent with per-tool invocation enforcement by a single declarative annotation, all without modifying the protocol or SDK internals. Across four frontier LLMs over 2160 attempts, an in-body-check-only server still exposes forbidden tools (152/720, 21.1%), whereas permission-aware visibility drives the rate to 0/720; visibility-only filtering remained bypassable by scripted clients, while models referenced the hidden tool by name in up to 94% of settings when inferable from the prompt, confirming that discovery controls cannot replace invocation-time enforcement.