TL;DR: MCP is becoming the default connective layer between AI agents and enterprise systems, but terra argues that the protocol also expands the attack surface through tool poisoning, secret exposure, scope creep, and weak auditability. The governance problem is no longer just model risk; it is whether organisations can continuously validate the tools, permissions, and trust boundaries their agents invoke in production.
Editorial analysis by NHI Mgmt Group, based on content published by terra: “MCP Security Testing: Validating AI's Newest Attack Surface”.
Key questions
Q: What breaks when organizations do not inventory AI agents and MCP connections?
A: Security teams lose the ability to answer what exists, what it can reach, and who owns it.
Q: Why do AI agents and MCP integrations increase IAM risk?
A: AI agents and MCP integrations increase IAM risk because they multiply the number of tool connections, service accounts, and tokens that can carry execution authority.
Q: How do you know if MCP security controls are actually working?
A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows.
Practitioner guidance
- Inventory every MCP server and connector Build a complete catalogue of MCP servers reachable by production agents, including shadow deployments, ownership, and business criticality.
- Validate tool scope before production use Test whether each server enforces least-privilege permissions, parameter constraints, and session binding before an agent can invoke tools.
- Scan for secret exposure paths Check tool descriptions, logs, debug output, and shared context windows for credentials that could be reused beyond the intended session.
Bottom line: MCP turns the agent integration layer into a live governance boundary, which means tool scope, authentication, and auditability now matter as much as model behaviour.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
MCP security testing is now a governance requirement, not a niche red-team exercise. Once MCP becomes the default connective layer for agents, the question is no longer whether the protocol is useful. The question is whether each server, tool definition, and credential path has been validated as part of the identity boundary. That changes MCP from an integration detail into a control point for AI agent governance, and practitioners should treat it that way.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What is the difference between testing the model and testing the MCP server layer?
A: Model testing focuses on prompts, output safety, and reasoning behaviour. MCP server testing focuses on the trust boundary where the agent reaches tools, data, and actions in production. Both matter, but only server-layer testing tells you whether the agent can actually do something unsafe with valid access.
👉 Read our full editorial: MCP security testing is becoming the control point for AI agents