How do teams decide whether to use filtering, access control, or both for MCP?

Use both. Access control prevents unauthorised connections and tool use, while filtering governs the data flowing through approved sessions. If either control is missing, enterprise MCP security remains incomplete because identity approval and content governance solve different problems.

Why This Matters for Security Teams

For MCP, filtering and access control solve different parts of the problem. Access control decides whether an identity can connect to a server or invoke a tool at all. Filtering decides what data can move once a session is already approved. Treating them as substitutes leaves a gap where a legitimate session can still exfiltrate sensitive data or execute unsafe actions.

That gap is especially dangerous in agentic environments because agents do not behave like stable human users. Their requests vary by prompt, tool chain, and runtime context, which means static assumptions break quickly. Current guidance from the OWASP Agentic AI Top 10 and NHIMG research on AI Agents: The New Attack Surface report points to the same operational reality: approved systems still need content-level governance.

NHIMG’s research also shows how quickly this becomes material in production. SailPoint reports that 80% of organisations say their AI agents have already performed actions beyond intended scope. In practice, many security teams discover the need for both controls only after an agent has already been allowed into a trusted workflow.

How It Works in Practice

The cleanest way to decide is to ask two separate questions: who may use MCP, and what may pass through it. Access control answers the first. It should validate the calling workload, bind the session to a verified identity, and scope which servers or tools are reachable. Filtering answers the second. It inspects prompts, outputs, retrieved context, and payloads for policy violations, sensitive data, and unsafe tool parameters.

In practical deployments, teams often use both layers together:

• Access control for authentication, session approval, and tool-level entitlements.
• Filtering for DLP, prompt inspection, secret detection, command allowlists, and output redaction.
• Policy decisions evaluated at request time rather than relying only on pre-approved static roles.
• Short-lived credentials so approved sessions expire quickly if an agent changes behaviour.

This aligns with the control intent described in the OWASP Non-Human Identity Top 10 and with the governance direction in NHIMG’s Ultimate Guide to NHIs, which emphasizes that identity approval alone does not govern data movement. A strong MCP design also benefits from workload identity, so the platform can cryptographically verify the agent or service before it reaches the tool layer.

In mature environments, filtering is often placed closest to the data plane, while access control sits at the control plane. That separation makes it easier to log, revoke, and audit each decision independently. It also helps security teams distinguish an authentication failure from a policy violation when reviewing incidents. These controls tend to break down when MCP is embedded in legacy app proxies that cannot inspect tool calls or when multiple agents share the same upstream credential.

Common Variations and Edge Cases

Tighter filtering often increases operational overhead, requiring organisations to balance stronger data governance against latency, false positives, and policy maintenance. That tradeoff is real, especially where agents need broad context to complete legitimate tasks. Current guidance suggests starting with the highest-risk data classes first, rather than trying to inspect every token equally.

Some environments need access control first, then filtering second. That is common when external MCP servers expose high-value tools and the main risk is unauthorised use of the tool itself. Other environments need the opposite emphasis because the server is already trusted, but the agent may still pull or emit regulated data. The right answer is usually both, but the control emphasis should reflect the dominant failure mode.

There is no universal standard for this yet, so teams should document their decision criteria and tune by use case. For example, code assistants, support copilots, and data analysis agents may each require different redaction rules and different permission scopes. NHIMG’s reporting on 52 NHI Breaches Analysis shows that incident patterns often emerge at the seam between identity approval and downstream data handling. The practical rule is simple: if the session can be approved, it still needs content governance; if the content can be filtered, it still needs identity-based access control.

Related resources from NHI Mgmt Group

• How can teams decide whether to use context-based access control for GenAI?
• How do security teams decide whether to use OIDC federation or service-account keys for MCP access?
• How should teams govern AI agents that use MCP?
• How should security teams govern AI agents that use OAuth access?