Tool Calling and Action Permissions in AI Agents

The Mechanical Loop an Agent Runs When It Calls a Tool

Here is what actually happens when an agent calls a tool. The model perceives a task, selects a tool from the definitions sitting in its context, generates arguments for that call, hands execution off to the runtime, observes the result, and decides whether to keep going or stop. That loop repeats until the task completes or something breaks. It sounds clean. It is not.

Tool definitions enter the model's context as metadata, and the model reasons over them the same way it reasons over anything else: probabilistically. Which means it can pick the wrong tool. It can generate arguments that are malformed or incomplete. It can misread a tool's response, or fail to recover when an API returns something unexpected. Strong general reasoning doesn't inoculate a model against choosing between two semantically similar tools, constructing a precise nested JSON payload, or handling a mid-task failure without losing the thread entirely.

Multi-step tasks make this worse in ways that matter operationally. One bad tool call early in a chain quietly corrupts every subsequent step. No obvious signal. No alert. The error propagates until the final output is wrong, or until something irreversible has already happened.

That fragility is not just a reliability problem. It is a security surface. Every handoff between model and tool is a point where instructions can be injected or arguments manipulated. The same architectural seam that causes reliability failures is the one adversaries exploit. Treating those as separate problems is a mistake. They share the same root.

How MCP Turned Ad-Hoc Tool Wiring into a Standard Interface

Before November 2024, connecting an AI agent to external tools was largely bespoke work. Every team wired their own integrations, defined their own schemas, built their own discovery mechanisms. The result was a fragmented ecosystem where interoperability meant rewriting everything for each new environment.

Anthropic's announcement of the Model Context Protocol changed that by proposing an open standard for how AI assistants connect to data systems and callable functions. MCP introduced four primitives: Tools (callable functions), Resources (data sources), Prompts (reusable templates), and Sampling (model invocation through the server). Communication runs over JSON-RPC. Discovery and invocation are standardized across implementations.

The adoption curve has been steep. Python and TypeScript SDK combined monthly downloads hit 97 million by late 2025. In December of that year, the protocol was donated to the Agentic AI Foundation under Linux Foundation oversight, which is the kind of move that signals a project has stopped being one company's experiment and started being an industry's infrastructure.

A key structural improvement came with the June 2025 spec update, which separated the MCP server from the authorization server. MCP servers now validate tokens issued by external enterprise identity providers rather than managing authentication themselves. The spec also added an explicit requirement for clients to follow least-privilege principles, requesting only the scopes necessary for their intended operations.

Here is the thing to understand about MCP, though. It gave the industry a common language for tool discovery and invocation, and it deferred almost every security guarantee to implementers. The protocol standardizes how tools are described and called, but does not enforce what any given agent is permitted to call or under what conditions. That responsibility sits entirely outside the spec. That gap is not an oversight. It's a design choice with real consequences.

Why Rapid Agent Deployment Is Outrunning the Governance Structures Meant to Control It

The deployment numbers tell an uncomfortable story. Nearly four in five enterprises have adopted AI agents in some form, yet only about one in nine runs them in production, per Gartner data — because organizations can build agents faster than they can govern them. Capability arrived; infrastructure didn't.

The governance deficit shows up clearly in how people actually feel about this. Nearly three quarters of IT application leaders, per Gartner, believe AI agents represent a new attack vector. Only a small fraction of those same leaders strongly agreed they had the right governance structures in place to address that risk. The organizations moving fastest on deployment are frequently the ones moving slowest on the controls that make deployment safe. That inversion is not accidental. It's the predictable result of treating governance as something you layer on afterward.

Non-human identities already outnumber human identities by more than 80 to 1 in enterprise environments, according to the 2025 Identity Threat Landscape Report. Agents are a growing share of that population, and they bring none of the lifecycle anchors that human identity management relies on. No employment record. No access review cycle. No offboarding event. When a project ends or a team restructures, the agent's permissions typically remain exactly where they were. Nobody scheduled the cleanup, because nobody thought of it as something that needed scheduling.

The practical consequence is permission sprawl at scale. An agent provisioned for one workflow accumulates access it no longer needs, or never needed, and that access compounds with every release cycle. And here's the part that should make you uncomfortable: an agent frequently holds greater execution permissions than the human who triggered its workflow. Most people assume that's an edge case. It's the default outcome when deployment outruns governance.

What Tool Poisoning and Prompt Injection Reveal About the Real Attack Surface

OWASP's 2025 generative AI risk list places prompt injection at the top. Tool abuse and privilege escalation appear explicitly in the OWASP AI Agent Security guidance. These are not theoretical concerns, and the incident record makes that clear.

Tool poisoning works like this: malicious instructions embedded in tool metadata hijack the model's decision-making before any user action occurs. The precondition is the absence of validation on tool definitions before those definitions enter the model's context. In April 2025, researchers at Invariant Labs confirmed this in practice. A poisoned math tool silently read SSH keys and exfiltrated them. The model had no way to distinguish a legitimate tool definition from a compromised one, because nothing in the pipeline was checking.

The vulnerability landscape around MCP infrastructure expanded rapidly through early 2026. Security researchers filed over 30 CVEs targeting MCP servers, clients, and infrastructure in just the first two months of that year. CVE-2025-6514 carried a CVSS score of 9.6 and affected a widely used MCP proxy across hundreds of thousands of installed environments.

EchoLeak, documented as CVE-2025-32711, demonstrated how engineered prompts in infected emails could trigger a widely used enterprise AI assistant to exfiltrate sensitive data automatically, without any user interaction at all. A 2025 supply chain breach compromised more than 700 organizations through a hijacked chat agent integration.

The pattern across all of these incidents is consistent: agents operating with permissions broader than any single task required, and no runtime check on whether a given tool call was appropriate for that agent at that moment. The attack surface is not primarily the model. It's the permission structure, or more precisely, the absence of one. The model did exactly what it was allowed to do.

The Three Access Control Models and How They Fit Agents Differently

Role-Based Access Control is where most organizations start, and it's easy to see why. RBAC assigns permissions by predefined role. Familiar to security teams, well-supported by existing tooling, straightforward to implement. The problem is that static roles are a poor fit for agents whose tool requirements shift with task context. An agent executing a reporting workflow needs different access than the same agent executing a data migration. RBAC collapses both into a single role definition and calls it good.

Attribute-Based Access Control evaluates user, resource, environment, and action attributes per request. That per-request evaluation is better suited to dynamic agent behavior, because it can incorporate context at decision time. The question isn't just "what role does this agent have?" but "given this agent's identity, its current task, and the environment, should this action be permitted?"

Policy-Based Access Control, which uses centralized policy engines to evaluate complex rules including real-time risk signals, is the strongest fit for agents operating at scale. PBAC can encode conditional logic rather than just identity. Policies can express things like: this agent may call the payments API only when the transaction amount falls below a defined threshold and the request originates from a verified internal workflow. That level of conditional specificity is impossible in RBAC and cumbersome in ABAC.

The zero trust principle applies directly. AI agents are high-privilege identities requiring continuous verification, not one-time provisioning. Most organizations learn the sequencing empirically: start with RBAC because it's familiar, then discover it cannot express the conditional access patterns agents actually require, then migrate. The migration is harder than getting it right the first time.

What a Working Permission Layer Around Tool Calling Looks Like in Practice

Permission scoping should happen at registration, not at runtime. When a tool or agent skill is published, the definition should explicitly declare which tools it may call, under what conditions, and with what argument constraints. Decisions made ad hoc at runtime, under execution pressure, are decisions made poorly. By then, it's too late to be deliberate.

Inherited permissions are one of the cleanest governance mechanisms available. If an agent can only access data that the triggering user already has access to, the tool call cannot be used to escalate privilege. The access boundary follows the human, not the agent. This single design principle eliminates an entire category of privilege escalation risk without requiring complex runtime policy evaluation. It's not elegant because it's clever; it's elegant because it's simple.

Versioning and audit trails matter more than most teams expect, until they need them. Every change to a tool definition or permission scope should be tracked with the same discipline applied to code. An agent that silently expands its own tool access is, from a behavioral standpoint, indistinguishable from a poisoning attack. The audit record is what makes the difference reconstructable, and it's also what makes post-incident investigation something other than guesswork.

Human-in-the-loop gates should be calibrated to consequence, not frequency. Every tool call does not need an approval step; that would make agents useless. But irreversible or high-privilege actions — writes, sends, deletes, external API calls with financial consequence — warrant a confirmation step before execution. The friction is low. The cost of skipping it on the wrong action is not.

Tool call tracing is the audit record that makes incidents reconstructable and permissions reviewable: what tool was called, with what arguments, by which agent, on whose behalf, at what time. Without this, you cannot investigate incidents, you cannot meaningfully review permissions, and you cannot demonstrate to auditors or stakeholders that your agents behaved as intended. You're just hoping.

When one agent hands off to another in a multi-agent pipeline, the receiving agent should not automatically inherit the caller's full permission set. Privilege should be re-evaluated at each handoff boundary. Automatic inheritance is precisely how permission sprawl propagates through multi-agent architectures, quietly and at scale.

A governed skill registry, where capabilities are published once with declared permissions and reused through that registry rather than rebuilt independently by each team, prevents the drift that comes from multiple teams wiring the same capability with subtly different access scopes. The redundancy isn't just inefficient — it's a governance failure accumulating quietly until it surfaces as an incident.

Why the Permission Layer Is What Determines Whether an Organization Can Actually Trust and Scale Its Agents

Gartner projects that more than 40% of agentic AI projects will be canceled by 2027. IBM's 2025 CEO study found that only about a quarter of AI initiatives delivered expected ROI. The failure mode in those numbers is not capability. The models are capable. The failure mode is trust and control, specifically the inability to deploy agents into consequential workflows with confidence that they will behave within defined boundaries.

An agent that can call any tool with any argument is not more capable in practice. It is less deployable. No organization will grant unrestricted tool access to production systems, financial workflows, or sensitive data environments, and they shouldn't. The permission layer is not a constraint on capability. It is the precondition for deploying capability in contexts where it actually matters.

The scaling argument follows directly. A skill that works in one team's hands can only be safely shared company-wide if its permission boundaries travel with it. Without that, every team that reuses the capability must re-solve the governance problem from scratch, with slightly different decisions each time, producing the fragmented, inconsistent access landscape that makes permission sprawl intractable at scale.

Permission governance is also what makes human oversight substantive rather than nominal. Approvals, audit logs, and scope constraints are not bureaucratic overhead. They are the mechanisms through which a human can understand what an agent did, why it had access to do it, and whether that access was appropriate. Without them, oversight is theater, and everyone in the room knows it.

The organizations closing the gap between broad adoption and actual production deployment share one characteristic: they treat tool permissions as a first-class design decision from the start, not as something to revisit after the capability is already built and deployed. Governance as a precondition rather than a retrofit. The data consistently rewards that sequence. The projects that don't follow it are the ones showing up in Gartner's cancellation projections.