Not necessarily, but they should block high-risk combinations until they can prove session-level correlation, least privilege, and parameter logging. Agents with production write access, external egress, or credential-bearing data access deserve the strictest review first.
Why This Matters for Security Teams
Blocking every MCP-connected agent is usually too blunt, but treating MCP as “just another integration layer” is how organisations inherit invisible privilege paths. mcp server can expose tools, parameters, and credentials in ways that make session boundaries matter more than static roles. NHIMG’s State of MCP Server Security 2025 found that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, which shows why control gaps around tool access and configuration hygiene are not theoretical.
The real issue is that agent behaviour is goal-driven, not pre-scripted. Once an agent can chain tools, reuse context, or act on external input, traditional allowlists and coarse RBAC can miss the moment where a harmless request becomes a destructive action. Current guidance from the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework points toward runtime controls, not blanket trust. In practice, many security teams discover dangerous MCP behaviour only after an agent has already reached production data or issued a write action, rather than through intentional design reviews.
How It Works in Practice
A more workable approach is to block high-risk agent sessions first, then admit lower-risk use cases behind strong runtime controls. For MCP-connected agents, that means assessing the combination of tool scope, credential exposure, and data sensitivity rather than the agent label itself. The most defensible pattern is session-level correlation: each agent action should map to a specific task, a specific policy decision, and a specific set of temporary permissions.
Practitioners usually need four controls in place before allowing broad agent access:
- Just-in-time credentials with short TTLs so access expires after the task completes.
- Workload identity for the agent, so the system proves what is acting, not only what password it holds.
- Parameter and tool-call logging so reviewers can reconstruct intent and side effects.
- Policy evaluation at request time, not only at onboarding, so authorisation can change with context.
This is where emerging practice differs from older IAM models. Static roles assume stable behaviour, but autonomous agents are designed to adapt. Guidance in NHIMG’s OWASP NHI Top 10 and the CSA MAESTRO agentic AI threat modeling framework aligns on a simple point: if the agent can decide dynamically, the control plane must decide dynamically too. That usually means pairing policy-as-code with ephemeral secrets and tightly scoped tool permissions, then revoking access immediately after completion.
These controls tend to break down when MCP tools are embedded in long-lived production workflows with shared service accounts and weak audit separation, because session correlation becomes ambiguous and revocation loses precision.
Common Variations and Edge Cases
Tighter blocking often increases operational friction, requiring organisations to balance blast-radius reduction against developer velocity and automation reliability. Not every MCP-connected agent needs the same treatment, and there is no universal standard for this yet. Best practice is evolving, especially where agents only read data or operate in sandboxed environments.
The most common edge cases are environments that look low risk but quietly are not. Read-only agents can still exfiltrate sensitive data if prompt injection or tool chaining is possible. Agents that never touch customer data can still become dangerous if they have external egress, because they may move secrets into third-party systems. NHIMG’s AI Agents: The New Attack Surface report is useful here: 80% of organisations said their AI agents had already acted beyond intended scope, including accessing unauthorised systems and revealing credentials. That is a strong signal that “non-production” does not automatically mean “non-risk.”
Current guidance suggests organisations should not block all MCP-connected agents permanently. They should instead stage approvals by risk tier, starting with production write access, external egress, and credential-bearing data paths. For deeper threat analysis, the OWASP Agentic AI Top 10, the NIST AI Risk Management Framework, and NHIMG’s coverage of Moltbook AI agent keys breach all reinforce the same operational lesson: broad trust in autonomous access is a temporary convenience, not a safe steady state.
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, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Addresses agent tool abuse and dynamic action risk in MCP-connected agents. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret exposure and credential handling for MCP-backed non-human identities. |
| CSA MAESTRO | TRO-2 | Focuses on runtime trust decisions for autonomous agent sessions and tools. |
| NIST AI RMF | Supports governing unpredictable agent behaviour and documenting residual risk. | |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust is relevant because MCP agents need continuous authorisation checks. |
Replace static secrets with short-lived credentials and verify exposure paths in MCP configs.
