Building New Security Perimeters: How Agent Tool Access Changes Your Risk Model

Part of the Beyond Copilot, Claude and ChatGPT: actually embedding AI into your company series.

What this article covers

When an agent gains the ability to call tools directly, your organisation’s risk model changes in a specific and concrete way. The network perimeter you built to protect internal systems assumes that access requests carry credentials, traverse known paths, and originate from known identities. An agent operating through the Model Context Protocol can call 183 macOS applications, edit a host file, or analyse a codebase without an API key, a VPN session, or a service account entry in your identity provider.

This article maps what changes in your threat model when agents get tool access, what new attack surfaces appear at the MCP layer, and how to build governance that keeps up with the pace of deployment. If your organisation is still in the earlier phase of putting AI into existing tools, the embedding AI into your company pillar covers that foundation. This article picks up where that work ends, at the point where agents stop being features inside your tools and start acting as infrastructure components themselves.

The governance gap is already measurable. As of April 2026, 82% of enterprises have deployed AI agents but only 44% have security policies covering them, a 38-percentage-point gap between deployment and governance. That gap exists partly because the tools moved faster than the frameworks, and partly because the security assumptions carried over from previous integration patterns do not hold at the tool-access layer.

How MCP changes what an agent can touch

The Model Context Protocol connects an agent to a server that exposes a set of tools. Those tools can be filesystem operations, native application actions, database queries, or code execution. The agent calls a tool by name, passes parameters, and receives a result. From the agent’s perspective, calling a tool is identical whether that tool wraps a read-only API or overwrites a production config file.

The MCP architecture introduces three properties that distinguish it from traditional API integration.

No credential per tool. In a standard API integration, each system issues its own key, scoped to permitted operations. With MCP, a single server process can expose many tools under one runtime context. If that process runs with broad OS permissions, every tool it exposes inherits those permissions.

Tool discovery is dynamic. A client can query an MCP server for its current tool list at runtime. This means the set of things an agent can do may change between deployments without a code change or a review cycle.

Local execution crosses the network boundary. Local MCP implementations run on the user’s machine and can reach native applications, local files, and system settings. Traffic never leaves the host, so network-layer monitoring does not see it.

flowchart TD
    A[Agent receives task] --> B[Queries MCP server for tools]
    B --> C{Tool available?}
    C -- Yes --> D[Agent selects tool]
    C -- No --> E[Task fails or escalates]
    D --> F{Policy check exists?}
    F -- Yes --> G[Check passes or blocks]
    F -- No --> H[Tool executes directly]
    G --> I[Action logged]
    H --> J[Action taken, no log]
    I --> K[Outcome returned to agent]
    J --> K

The absence of a policy check in that path is not a failure of MCP as a protocol. It is a gap in how most organisations have deployed it so far.

The attack surfaces that emerge

Prompt injection at the tool boundary

Prompt injection in a chat interface changes what the model says. Prompt injection in an agent with tool access changes what the agent does. A malicious instruction embedded in a document the agent reads, a calendar event it processes, or a code comment it analyses can cause the agent to call a tool it was never intended to call. The instruction is indistinguishable from legitimate context at the model layer.

The practical risk is that an agent with access to both a file-reading tool and a network-posting tool can be instructed, via injected content in the first tool’s output, to exfiltrate data through the second. This is not a theoretical edge case. It is the category of incident that 88% of enterprises reported experiencing in the twelve months to April 2026, and only 21% of those organisations had runtime monitoring of agent actions in place.

Understanding this attack surface is a prerequisite for building an effective AI security framework.

Scope creep at the tool level

When a developer adds a new tool to an MCP server to solve an immediate problem, they are also expanding every agent that connects to that server. There is no natural review gate between “this tool now exists” and “this agent now has access to it.” Across a fleet of agents, tool scope grows in the same way that IAM permissions grow in a cloud environment: incrementally, by request, with no periodic recertification.

JPMorgan Chase runs more than 450 active AI agent use cases in production, spanning investment banking, fraud detection, trade settlement, and document review. At that scale, tracking which agents can call which tools requires the same rigour applied to service-to-service permissions in a microservices architecture. Most organisations are not starting from that baseline.

Trust assumptions in multi-agent systems

When one agent calls another, the called agent inherits a trust context it cannot independently verify. If your orchestrator agent can call a sub-agent that has file-write permissions, then any compromise or misdirection of the orchestrator propagates to the sub-agent’s capabilities. Multi-agent systems introduce this transitivity problem, and it scales with the depth of the agent graph.

flowchart TD
    O[Orchestrator agent] --> A1[Research agent - read only]
    O --> A2[Drafting agent - file write]
    O --> A3[Comms agent - email send]
    A1 --> T1[Web search tool]
    A1 --> T2[Document read tool]
    A2 --> T3[File write tool]
    A3 --> T4[Email API tool]
    X[Injected instruction in doc] --> A1
    A1 -- passes instruction up --> O
    O -- re-routes to --> A3
    A3 -- sends exfiltration email --> T4

The research agent in this diagram has only read permissions. The vulnerability is the trust path from it to the orchestrator and then to the comms agent.

What traditional perimeter controls miss

Firewall rules and network segmentation assume that sensitive actions require network traversal. A local MCP server running on a developer’s laptop with access to their filesystem, browser, and calendar does not traverse a network segment you control. Even for server-side MCP deployments, the relevant boundary is now the tool list exposed by the server, not the IP range from which requests arrive.

Identity-based controls help more than network controls at this layer, but they have their own gap. Most identity providers track human users and service accounts. They do not natively model “agent instance X is permitted to call tool Y on behalf of human Z, but only during business hours and only for files in project directory W.” That level of specificity requires a policy layer purpose-built for agent governance.

EY deployed its EYQ agentic platform to 300,000 professionals across tax, assurance, and consulting by March 2026. At that scale, the governance model cannot rely on human review of individual agent actions. It requires policy enforcement at the tool call level, with logging sufficient to reconstruct what happened after the fact.

Designing governance for tool-connected agents

Treat the tool list as a permission surface

Every tool exposed by an MCP server is a permission. Manage it the same way you manage IAM policies: with a defined owner, a documented justification, a minimum-scope principle, and a periodic review cadence. If you would not give a service account write access to a production database without a ticket and a review, the same standard applies to an MCP tool that writes to that database.

The RBAC versus ABAC comparison for agents covers the tradeoffs in access control models at this layer. For most organisations, attribute-based control (which can encode context like task type, data classification, and time window) gives finer resolution than role-based control alone.

Require confirmation for irreversible actions

An agent that reads and summarises data is recoverable if it makes a mistake. An agent that deletes records, sends emails, or modifies infrastructure configuration is not. Insert a human confirmation step, or at minimum a structured logging and hold step, before any tool call that is irreversible or that touches data outside the agent’s primary scope.

Morgan Stanley’s DevGen.AI reviewed 9 million lines of legacy code and saved 280,000 developer hours without granting the agent write access to production systems. The agent translated code into specifications; humans decided what to do with those specifications. That boundary is a design choice, not an accident, and it is the kind of choice that belongs in a governance policy, not left to individual deployment decisions.

Log at the tool call level, not the conversation level

Conversation-level logging tells you what the agent said. Tool-call-level logging tells you what it did. The two are not equivalent. A logging pipeline that captures every tool call with its parameters, the identity context under which it ran, and the result gives you the data you need for both incident response and compliance attestation.

Agent observability is the operational discipline for maintaining that pipeline. Category tooling, including Prefactor, provides structured logging at the tool call level so that audit trails capture the action, not just the conversation. Choose the approach that integrates with your existing SIEM and preserves enough fidelity to reconstruct a full action sequence.

Apply least privilege at the agent level, not just the server level

A single MCP server can serve multiple agents. If all agents connecting to that server inherit the full tool list, a narrow-purpose agent (one that only needs to read calendar data) also has access to tools it never needs. Scope each agent’s permitted tool list explicitly, even if that requires running separate server instances or implementing a proxy that filters the tool list per caller identity.

The runtime governance versus pre-deployment review comparison outlines where each control type is most effective. Pre-deployment review catches misconfigurations before they reach production. Runtime governance catches behaviour that deviates from the expected pattern after deployment. Both are necessary, because tool lists change and agent behaviour in production differs from agent behaviour in staging.

Scaling governance as your fleet grows

AI agent fleets are growing fast. The mean organisation had roughly 37 agents deployed in December 2025. By April 2026, 38% of organisations reported more than 100 agents deployed. At 100 agents, manual tool-list review becomes a bottleneck. At 200, it becomes impossible without automation.

The governance practices that work at 10 agents, an inventory spreadsheet, a weekly review meeting, and a shared Slack channel for incident escalation, do not scale to 100. The organisations that avoid the governance gap are the ones that treat agent tool access as an infrastructure problem from the start, with the same tooling, automation, and policy-as-code approaches applied to cloud IAM, container permissions, and network ACLs.

For security and infrastructure teams building this foundation, the enterprise AI security guide and the AI governance framework overview provide the policy structure to build on. The CISO role guide covers how to position this work within a broader security programme.

The 28% of Fortune 500 companies that have deployed MCP in under 18 months are not slowing down. The question is not whether your agents will have tool access. It is whether your governance will keep up with what they can do with it.

Where to start

Map every MCP server in your environment, list the tools each one exposes, and record which agents connect to each server. That inventory is the prerequisite for every other control described in this article. Once you have it, use Take the agent readiness assessment to identify the specific governance gaps between your current state and a production-grade security posture.