People are transferring a lot more autonomy to their AI agents. The paradigm is moving from static information gathering to deeper data lookups and tasks. And to accomplish these actions, agents are being given more and more permissions to sensitive business functions that often exceed what is required for the job at hand.
When agents are given comprehensive and long-lived read and write access to countless production endpoints, dangerous outcomes can occur, including deleted production databases, destructive code commits, and other unexpected actions, which can equate to downtime and a loss of business.
Once your hands are off the keyboard and AI agents can perform real-world tasks and touch sensitive data, the new challenge is to ensure agents don’t have too much access, especially to tool endpoints with potentially destructive actions. In practice, this often boils down to taking a least privilege approach to curate what Model Context Protocol (MCP) servers and tools are exposed to an agent, and authorizing this access on an ongoing basis.
The Challenge: Agentic Permission Sprawl
Agents need a degree of permissions to do their work, but overprivileged agents can expand the threat surface area and pose an unnecessary security risk.
Before AI agents came along, permissions were already overextended in most enterprise environments. A Palo Alto Networks Unit 42 study analyzed more than 680,000 identities across over 200 organizations and found that 99% of cloud users, roles, services, and resources had been granted excessive permissions that went unused. Granting excessive, unused capabilities to any entity expands the potential risk surface, and agents exacerbate this issue.
Nowhere is the issue of overprivileged agents clearer than with MCP adoption. MCP provides agents with impressive capabilities to interact across external tools, systems, APIs, and data. And it’s becoming incredibly easy to configure an AI agent with an MCP server to give it autonomous access to SaaS services, databases, devops tools, and internal systems.
MCP has quickly emerged within enterprise environments. For instance, Snyk’s 2026 State of Agentic AI Adoption found that 46.9% of organizations using AI had adopted agentic architectures involving agents, MCP servers, or both. Now, an agent can sync data with a CRM, initiate a PR to GitHub, deploy a feature, contact customers, and more. Much of this can be powered by MCP servers.
Yet, in the rush to adopt MCP in software engineering, it’s easy for traditional security reviews to fall by the wayside, creating an MCP sprawl problem of shadow servers, blanket agentic access, and privilege drift.
This has created a visibility dilemma. Okta’s Global CISO Insights 2026 found that less than half (47%) of CISOs are confident they can identify all agents in their environments, while only 45% are confident they can authorize individual tool calls using context and intent. In fact, 81% of CISOs said they were concerned about excessive AI access.
Overprivileged Agents: What Can Go Wrong
When AI agents have 100% autonomous control without guardrails or human-in-the-loop checkpoints, they can behave in unexpected ways, in part because the large language models (LLMs) beneath them are nondeterministic. This can cause what some call “intent errors,” a type of agentic misalignment that occurs when an AI seems to misinterpret the prompt and act erratically.
For example, agents don’t always follow security commands when those commands exist only within a prompt. One prime example was when a Replit agent deleted a live production database containing records for thousands of executives and companies. It did this even though the user had communicated an explicit code freeze.
Even OpenAI admits that its coding agents can, at times, take irreversible actions without permission. This has included deleting data from cloud storage, terminating running processes, and restarting GPU clusters. Anthropic refers to the broader phenomenon of agents acting against user intent as “agentic misalignment,” and its research has documented simulated cases in which agents override instructions or take unintended actions.
MCP provides streamlined, discoverable access to tools, data, and APIs. And while it improves and standardizes the ability for LLMs to interact with other systems, this is a double-edged sword for AI environments left ungoverned. The more tools an agent can discover and invoke, the more important it becomes to ensure those tools actually match its intended role. In such a scenario, it’s easy for privileges to drift in multi-agent systems as well, as agents tack on more and more utilities.
Least Privilege for Agentic Tool Calls
Many intent errors and instances of privilege drift can be mitigated by hunkering down access so that the agent never has access in the first place. This boils down to least privilege: the concept that the requesting party only has rights to what it needs, and nothing more. It’s a basic principle of cybersecurity used by authorization systems to enforce the proper permissions.
Ideally, agentic clients should have versions of tools at their disposal that don’t exceed the overriding roles and permissions of the requesting party and are highly scoped for autonomous agents. At a technical level, this means curating MCP tool access.
For instance, some tools might be read-only and fine to expose at length to agents and junior developers. Others might allow write access but still require curation around which tools to expose to more seasoned engineers. You may also want to limit the duration that certain tools are exposed to agents.
More advanced approaches are also progressing within the cybersecurity industry to enable more dynamic flexibility than a simple allow-or-deny decision. For instance, just-in-time access is emerging in cybersecurity circles — the idea of providing temporary access only when it is needed for a particular task. The idea of zero standing privilege is similar, but stricter. When applied to agents, this means not providing them with persistent “standing privileges,” but granting access only when it is required.
Enforcing Least Privilege for MCP at the Gateway
Gateways are already one of the most common ways to host an MCP server, according to Zuplo’s State of MCP report. As such, the gateway is one possible place to configure and enforce a least privilege approach to MCP use by agents.
Using a gateway like Zuplo, you can register all your available MCPs and then spin up a virtualized MCP that only presents the access levels the agents and users using them should have, and nothing more.
This can be done by simply configuring a check mark per tool to include it in the virtual server, and then auto-generating the server to share with internal employees or engineers. It’s a rather simple, intuitive way to create a stopgap between agents and external, potentially harmful endpoints.
Not only can you selectively curate how MCP servers are exposed, but a gateway can act as a unifying layer for disparate authentication standards across MCP servers. It can also generate logs, monitoring, and observability, aiding debugging, compliance, and internal chargeback use cases.
Of course, utilizing a gateway should be seen as an act complementary to preexisting identity systems — this doesn’t replace the need for identity-based protection and identity providers (IdPs), for instance, which establish identity and provide the attributes and claims used to make access decisions. Instead, most MCP and AI gateways are built to work alongside IdPs.
Limiting What Agentic AI Can Touch
Given that 72% of MCP builders expected their MCP usage to increase by the end of 2026, the onus is on security engineers, lead developers, and enterprise architects to ensure their systems are future-proofed — while allowing for innovation with new AI tooling like MCP.
All in all, securing agentic tool calls requires a least privilege mindset. AI agents can act in unpredictable ways, and there are proven cases in which an agent exposed to powerful tools acted against the user’s intended instructions. Simply saying “don’t touch production” is weaker than denying an agent production write access in the first place.
And 58% of MCP builders already wrap existing APIs. This reinforces the idea that MCP in production enterprise environments requires similar forethought around API security — including zero trust, authentication and authorization, and identity-based access.
As we move from static AI to far more actionable agents, the new cybersecurity challenge is to validate intent, and authorize access in an ongoing manner, ensuring agents have the right level of tool access while leaving enterprises in control to innovate safely.
It boils down to what a system can touch. You can’t operate on that which you literally can’t access. Since MCP opens up a world of possibilities for agents, slimming that world down is necessary to safeguard their use in real-world environments.