What should teams do when an MCP tool starts behaving outside its baseline?

Why This Matters for Security Teams

When an MCP tool starts deviating from its expected baseline, the issue is rarely just “odd output.” It can indicate prompt injection, tool abuse, unauthorized data access, or a broken trust boundary between the model, the tool, and the connected systems. For teams running autonomous or semi-autonomous workflows, the risk is that a single abnormal tool call can become a chained action with real-world impact. The OWASP Top 10 for Agentic Applications 2026 is useful here because it frames agent behavior as a security surface, not just an application feature.

Security teams often miss the moment of compromise because they monitor prompts, tickets, or API requests, but not the execution path inside the session. That gap matters for MCP because the tool may have already read files, queried systems, or triggered downstream actions before anyone notices the baseline shift. In practice, many security teams encounter the real problem only after data exposure or unauthorized action has already occurred, rather than through intentional behavioural monitoring.

How It Works in Practice

The right response is to treat abnormal tool behaviour as an incident signal and move from observation to containment. Start by pausing the tool process or revoking the tool session, then preserve the relevant execution context: last prompts, tool invocations, protocol messages, outputs, and any correlated identity or privilege events. That evidence helps distinguish a model-level anomaly from a compromised connector, poisoned context, or malicious instruction injected through upstream content.

Baseline comparison should focus on sequence and intent, not just content. A tool may ask for the same endpoint but in a different order, at a different frequency, or with a broader scope than normal. That is often more important than a single suspicious string. Teams should compare:

• tool-call order and repetition patterns
• destination systems, scopes, and data classes accessed
• changes in approval prompts, retries, or fallback behaviour
• new privilege use, token reuse, or unusual session duration

From a control standpoint, this maps well to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where organisations need logging, monitoring, access enforcement, and incident response discipline around AI-enabled workflows. Current guidance suggests logging alone is not enough; you need correlation across runtime events, identity context, and tool permissions. Where possible, preserve artefacts for later review and only restore access after the root cause is understood and the baseline has been recalibrated.

These controls tend to break down when MCP tools are distributed across multiple services with inconsistent logging, because the execution path becomes fragmented and the abnormal action cannot be reconstructed reliably.

Common Variations and Edge Cases

Tighter tool isolation often increases operational overhead, requiring organisations to balance fast recovery against the risk of restoring a compromised workflow too early. That tradeoff is most visible in production agents that support customer operations, software deployment, or data retrieval, where a hard stop can disrupt business but a soft response can leave the compromise active.

Best practice is evolving for shared agent environments, so there is no universal standard for this yet. Some teams use severity tiers: low-risk drift may trigger review and throttling, while high-risk drift triggers immediate containment, credential rotation, and human re-approval. That approach works best when the baseline is stable and the tool’s allowed actions are narrow.

Edge cases include legitimate model adaptation, seasonal workload changes, and workflow changes after product releases. These can look suspicious if the baseline is stale. The practical test is whether the new behaviour is explainable, authorised, and bounded by policy. If an MCP tool starts calling a broader set of tools, requesting higher-scope data, or bypassing expected approvals, treat that as a security event until proven otherwise. The OWASP Agentic AI Top 10 reinforces the need to govern agent actions, not just model text, because the control failure often lives in the action layer.

Related resources from NHI Mgmt Group

• How should organisations respond when an authenticated identity starts behaving outside its baseline?
• How should security teams handle tool discovery for AI agents in MCP environments?
• How should security teams govern MCP tool access in enterprise environments?
• What should teams do when shadow AI starts using credentials outside normal control paths?