MCP security testing is becoming the control point for AI agents

At a glance

What this is: This is terra’s analysis of why Model Context Protocol testing is now central to AI agent security, with the key finding that MCP creates a new trust boundary that must be validated continuously.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agent-to-tool access with the same discipline they apply to privileged workloads, not just the model layer.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read terra's analysis of MCP security testing and AI agent attack surface

Context

Model Context Protocol is the connective layer that lets AI agents reach tools, files, databases, and APIs. The security issue is that each connection creates a new trust boundary, and most programmes still treat that boundary as if it were a standard integration rather than an identity-controlled access path.

For identity teams, the problem sits between NHI governance and emerging agentic AI controls. The model may decide which tool to call, but the access it consumes is still enforced through credentials, scopes, logs, and offboarding practices that were never designed for agent-timed execution. See the OWASP NHI Top 10 for the broader control surface this creates.

terra’s framing is typical of what practitioners are now seeing in early agent deployments: the operational pressure to connect first and secure later. That sequence is increasingly mismatched to the risk profile of MCP-connected systems.

Key questions

Q: What breaks when MCP servers are exposed without identity controls?

A: Without identity controls, anyone with a link, key, or copied credential can reach tools and data outside policy. That breaks visibility, weakens compliance evidence, and makes it difficult to separate approved use from shadow AI activity across SaaS and internal systems.

Q: Why do MCP deployments complicate NHI governance?

A: MCP connects agents to tools in a way that can blur the line between a legitimate workload request and an uncontrolled execution path. For NHI governance, that matters because tokens, service accounts, and tool permissions are often managed separately, yet they now combine at runtime. If the request is not bound to identity and context, least privilege is only nominal.

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. If teams cannot reconstruct which server asked for what, or if secrets appear in configuration files, the control set is not operating as intended.

Q: Who is accountable when an AI agent takes action through an MCP server?

A: The accountable party is the human or team that authorised the agent's access, but only if the organisation can prove that chain. Without immutable logs that connect the initiating identity to the tool call and final action, accountability becomes weak, and legal or compliance teams lose the evidence they need.

Technical breakdown

Why MCP creates a new trust boundary for AI agents

MCP standardises how an AI client discovers and invokes external tools, but it does not by itself enforce authentication, sandboxing, or input validation. That means the security property is not in the protocol name. It emerges from how each server binds identity, scopes access, and records actions. Because the model can select tools at runtime based on natural-language reasoning, the access decision is no longer limited to a pre-approved API call path. Each server therefore behaves like a separate privilege boundary that must be tested, not assumed.

Practical implication: inventory every MCP server as a governed identity-integrated access path, not as a simple integration.

How tool poisoning and scope creep appear in MCP environments

Tool poisoning happens when a malicious or compromised tool description, plugin, or retrieved context alters what the model believes it should do. Scope creep appears when permissions expand beyond the original use case and the agent is left with broader capabilities than intended. In MCP, these risks often combine because the server can change tool definitions over time, and the agent may inherit those changes without a fresh governance review. That makes static approval models fragile.

Practical implication: re-validate tool definitions and permission scope whenever an MCP server or connector changes.

Why auditability and credential hygiene determine whether MCP is governable

MCP risk becomes harder to contain when credentials are long-lived, over-privileged, or stored in logs, memory, or configuration files. If the platform cannot show which tool was called, with what context, and under which identity, investigators lose the ability to separate normal agent behaviour from misuse. The governance issue is not only prevention. It is also whether the enterprise can reconstruct agent activity after a suspicious tool call or data request.

Practical implication: require immutable audit trails and short-lived credentials for every agent-to-tool exchange.

Threat narrative

Attacker objective: The attacker wants to convert a trusted AI integration point into a path for credential exposure, unauthorised tool execution, or broader system compromise.

1. Entry begins when an MCP server, tool, or connector is exposed to an AI agent with excessive trust or weak authentication controls.
2. Escalation follows when tool poisoning, scope creep, or secret exposure allows the agent to reach systems or actions beyond the intended boundary.
3. Impact occurs when the agent invokes production tools, reveals credentials, or performs unauthorised actions that affect data integrity, access, or availability.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP has turned AI integration into an identity problem before it is a model problem. The important question is no longer whether an agent can reason through a task. It is whether the enterprise can govern the tool permissions, credentials, and trust boundaries that give that agent reach into production systems. For IAM and NHI teams, the control point has shifted to the protocol layer.

Tool-scoped access is the new minimum viable governance model for agentic systems. The article makes clear that MCP servers can expand capability faster than security teams can review. That means every server needs explicit scoping, review, and revocation logic, because a default-open connector is functionally a standing privilege path. Practitioners should treat tool permissions as lifecycle objects, not one-time setup values.

Shadow MCP creates the same visibility failure we have seen in unmanaged NHIs. If security teams cannot enumerate every server reachable by production agents, they cannot prove what those agents can touch. This is the named concept that matters here: protocol-layer trust drift, where access assumptions silently broaden as connectors, tools, and context change. The implication is that inventory and continuous validation become core controls, not support functions.

Continuous validation is now the only testing model that matches agentic change speed. Point-in-time review assumes the environment is stable long enough to assess it once. MCP environments are not stable, because tools, schemas, and credentials change as teams ship. Governance programmes that still rely on periodic sign-off will miss the very drift that creates the exploit path. Practitioners need to align testing cadence to deployment cadence.

The NIST AI RMF conversation now extends beyond the model to the tool graph. If the inventory stops at the LLM, it excludes the part of the system that actually performs the risky work. That is a governance blind spot, not a technical nuance. Security leaders should expect auditors and regulators to ask how agent access is mapped, scoped, and logged across every connected server.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Our research also shows that only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That is why OWASP Agentic AI Top 10 and the AI agent governance conversation now need to move together, not in sequence.

What this signals

The practical signal for identity teams is that AI integration work is now inseparable from NHI governance. When an agent can discover tools dynamically, the organisation needs inventory, scope control, and revocation discipline across the full connector layer, not just at the model boundary.

Protocol-layer trust drift: once MCP servers start changing faster than approval cycles, the environment stops being governable through periodic review alone. Continuous validation has to become a standing control in the programme, especially where production agents can reach data or payment systems.

With 96% of technology professionals already identifying AI agents as a growing security threat, the pressure on IAM and security operations will be to prove control coverage across every agent-to-tool path, using frameworks such as the NIST AI Risk Management Framework and OWASP Agentic AI Top 10.

For practitioners

• Inventory every MCP server as a governed identity boundary Map each server, tool, and connector to an owning team, access scope, credential type, and revocation path so production agents are never connected to an unowned trust boundary.
• Enforce short-lived, narrowly scoped credentials Replace static tokens and permissive secrets with short-lived credentials that are bound to a specific agent session and tool scope, then rotate or revoke them automatically.
• Re-test tool definitions on every change Treat updated schemas, tool descriptions, or connector changes as security events that trigger retesting for tool poisoning, confused deputy behaviour, and scope expansion.
• Require immutable audit trails for agent activity Log every tool invocation, context change, and identity assertion in a way that supports investigation, compliance review, and forensic reconstruction after suspicious behaviour.
• Run continuous validation instead of point-in-time review Schedule AI penetration testing to match deployment cadence so new servers, new tools, and permission drift are validated before they reach production use.

Key takeaways

• MCP creates a new identity-controlled trust boundary, and that boundary is now part of the AI attack surface.
• Continuous validation matters because tool definitions, credentials, and server permissions can drift faster than periodic review cycles can detect.
• IAM and NHI programmes need inventory, scoping, and auditability across the connector layer if they want to govern AI agents in production.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• Protocol-Layer Trust Drift: The gradual expansion of access assumptions as MCP servers, tools, and credentials change faster than security review cycles can keep up. It is a governance problem because the environment remains functional while the original trust model silently becomes outdated.

What's in the full article

terra's full article covers the operational detail this post intentionally leaves for the source:

• The MCP risk table with specific categories such as token mismanagement, tool poisoning, and context injection.
• terra's testing workflow for enumerating exposed tools, probing parameter schemas, and reproducing exploitable paths.
• The change-triggered testing model that shows how continuous validation fits into an AI application pentesting programme.
• The reporting model that converts an MCP finding into audit-ready evidence for security and compliance teams.

👉 terra's full article covers the MCP risk categories, testing flow, and continuous validation model in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or operational governance, it is worth exploring.