How should security teams decide between network, MCP, data and identity controls for agents?

Use the control layer that matches the decision you need to make. Network controls govern connectivity, MCP controls govern tool invocation, data controls govern exposure, and identity controls govern who may do what inside the target system.

How to choose the right control layer for agents

Choose the layer that answers the question you are actually trying to govern. Network controls are about whether the agent can reach a destination, MCP controls are about whether it can invoke a tool, data controls are about what content it can see or move, and identity controls are about who or what is authorised to act inside the target environment.

The practical test is scope: if the concern is transport or egress, start at network; if the concern is tool selection or protocol mediation, start at MCP; if the concern is exposure of records, prompts, or outputs, start at data; and if the concern is delegated authority, privilege, or session trust, start at identity. This avoids using a stronger control layer than the decision requires.

That separation matters because agents often cross all four layers in one workflow. A single action can be reachable on the network, permitted by MCP, constrained by data policy, and still fail at identity because the agent lacks the right token, role, or delegation path. For a layered view of agent risk, see Agentic AI Security Guide and OWASP Agentic AI Top 10.

What each control layer actually changes

Network controls reduce where an agent can connect, which is useful for segmentation, internet exposure, and blast-radius reduction, but they do not tell you whether the agent should use a permitted tool or read a permitted record. MCP controls sit one layer higher and govern how the agent reaches tools and resources, including authorization boundaries, token handling, and tool invocation paths. For the protocol layer itself, MCP Security Guide and the Model Context Protocol authorization specification are the most direct references.

Data controls answer a different question: what information the agent can access, transform, export, or retain. They are the right lever for sensitive content, minimisation, masking, and policy enforcement around prompts, documents, and outputs. Identity controls, by contrast, govern the authority behind the action. They matter when the same request is acceptable in principle, but only for a specific agent, tenant, workflow, or delegated role. In practice, teams should avoid treating one of these layers as a substitute for the others. For identity-led deployment patterns, AI Agent Identity Security: The 2026 Deployment Guide and Agentic AI Identity Guide provide the clearest implementation framing.

A useful operating rule is to put the narrowest control where the decision is smallest, then compose outward. That often means MCP for tool mediation, identity for delegation and privilege, data controls for content exposure, and network controls for coarse containment. If the target system already has strong identity and privilege enforcement, duplicating that decision in the network layer usually adds friction more than assurance.

When teams should combine layers instead of choosing one

Many agent use cases need more than one control layer because the failure modes differ. Network controls can stop obvious reachability, MCP can stop unauthorised tool use, data controls can limit leakage, and identity controls can limit abuse of delegated authority. Combining them is most useful when the agent is allowed to act, but only within a tightly bounded task, environment, and data set.

A common pattern is to pair identity with MCP when an agent is allowed to call tools but only under a specific delegation model. Another is to pair data controls with identity when the same record class is available to multiple agents, but the business decision is who may process it and under what conditions. For broader governance and lifecycle treatment of agent identities, Identity Security Programme Guide and AI Agent Identity Security Buyer’s Guide help teams separate architecture choice from procurement choice.

The best multi-layer design is the one that keeps each control close to the decision it is meant to enforce. If the same policy must be re-expressed in multiple layers, that is usually a sign the team has not separated reachability, tool use, data exposure, and delegated authority cleanly enough.

Risk and Threat Considerations

The main risk is control confusion, where a team enforces the wrong layer and assumes the problem is closed. That can leave an agent reachable, tool-capable, or data-exposed even though the intended decision was about privilege or delegation.

Failure mechanism: Attackers or misconfigurations exploit the gap between layers, for example by using a permitted network path to reach an overbroad tool, or by using valid identity in a system that lacks content or action scoping. Once one layer is overloaded with responsibilities, blast radius increases and review becomes harder.

Impact: The result can be unauthorised tool invocation, sensitive data exposure, lateral movement inside the target environment, or agent actions that are valid at transport level but excessive at the authority level. In agentic systems, that often shows up as accidental overreach before it looks like an obvious compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI03 — Identity & Privilege Abuse	Agents are governed by delegated authority and privilege boundaries.
	ASI02 — Tool Misuse	MCP decisions center on whether an agent may invoke a tool.
	ASI04 — Agentic Supply Chain Vulnerabilities	MCP and agent integrations depend on third-party components and protocols.
Recommendation — Constrain agent authority to the minimum required for each task. Restrict tool invocation paths and validate each tool call. Review agent dependencies and trust boundaries before deployment.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Identity controls for agents are fundamentally about limiting authority.
	IA-9 — Identification and Authentication (Non-Organizational Users)	Agents and other non-human actors require strong authentication boundaries.
	SC-7 — Boundary Protection	Network controls govern reachability and segmentation for agent traffic.
Recommendation — Apply least privilege to every agent credential and delegated role. Authenticate each agent with a distinct, verifiable identity. Segment agent traffic and restrict unnecessary network reachability.
OWASP ASVS	V8 — Authorization	The page distinguishes tool, data, and identity authorization decisions.
Recommendation — Verify authorization at the point where the decision is enforced.

Practitioner Guidance

Decision rule: If the control question is “can it get there?”, start with network; if it is “can it call this tool?”, start with MCP; if it is “can it see or move this data?”, start with data; if it is “can this agent act with this authority?”, start with identity.

What to verify: Teams should be able to show that each layer is enforcing a different decision, not the same one in four places. If a control cannot be expressed as a clear deny, allow, or scope boundary for that layer, it is probably being applied too broadly or too late.

Practitioner takeaway: The right control is the one that changes the decision with the least collateral restriction, and mature agent security usually comes from composing the four layers rather than trying to force one of them to do all the work.