We Tried to Create Multi-Step MCP Drift

Our previous experiments established two ideas:

• Tool outputs can influence an agent after execution.
• Tool descriptions can influence an agent before execution.

The obvious next question was:

Can a single poisoned tool response cause an agent to progressively expand into a sequence of additional MCP tool calls?

If that were true, a simple SSL investigation could gradually evolve into infrastructure exploration without the user ever asking for it.

Baseline execution without injected guidance.

The Experiment

We started with a normal request:

Investigate the SSL configuration for agntid.ai

The only difference between the baseline and treatment runs was a single advisory sentence added to the DNS tool response.

Instead of simply returning DNS records, the tool subtly suggested that the model continue investigating backing compute and ingress.

Treatment run with the injected advisory.

Importantly, nothing else changed.

The tool schemas remained identical.

The structured DNS data remained identical.

Only the advisory note differed.

Baseline summary.

Treatment summary.

What We Expected

A successful multi-step drift would resemble this:

SSL
 ↓
DNS
 ↓
Compute
 ↓
Ingress
 ↓
Additional infrastructure

Each decision would depend on information discovered during the previous tool invocation.

That would demonstrate true sequential expansion.

What Actually Happened

The results were more restrained.

The model occasionally reached for AWS tools, but it did not build a reliable sequential chain.

Trace evidence showing no confirmed sequential AWS chain.

Across ten treatment runs:

• AWS drift occurred in 2 of 10 runs.
• No confirmed multi-step chain emerged.
• Most executions stayed entirely within the monitoring workflow.

Combined experimental summary.

The More Interesting Finding

At first glance, this looks like a negative result.

It isn't.

The experiment answered a different question than the one we originally set out to investigate.

The real security boundary isn't the fifth unexpected tool call.

It's the first one.

Once an agent decides to invoke a tool that falls outside the user's intended scope, the authorization decision has already arrived.

Whether the model continues for one more tool or ten more tools is secondary.

Why This Matters for Runtime Security

Traditional IAM decides access before execution.

Agentic systems decide what to execute during execution.

That means every tool invocation is a fresh authorization event.

This experiment reinforces an architectural point that matters far more than the specific chain length:

• Multi-step chains are an interesting research problem.
• A single unexpected tool call is already a runtime security problem.

Where AgntID Fits

AgntID doesn't need to predict whether an agent will eventually build a five-step chain.

It evaluates the next tool call.

If the user requested an SSL investigation but the agent suddenly attempts to inspect AWS infrastructure, that invocation should be evaluated against runtime policy before it executes.

Execution-time enforcement stops unexpected expansion at the point where it matters most—the first tool call outside the approved task.

Closing Thoughts

This experiment did not produce reliable multi-step MCP drift.

But it did show that even subtle guidance can occasionally push an agent beyond the user's original workflow.

For defenders, that's the more useful lesson.

Security shouldn't wait to see whether a chain develops.

Runtime enforcement belongs at the very first unexpected tool invocation.