Why an Orchestrator, When You Already Have MCP
A common misread of the modern agent stack is that MCP is the agent. It is not. MCP is a way to expose tools; it says nothing about when to call one, in what order, what to do with the result, or when to stop. That judgement lives in the orchestrator — the control loop that turns a language model and a bag of tools into something that can actually get a multi-step job done. Once you see the orchestrator as the loop, you see exactly where the security-relevant decisions are made.
What MCP deliberately does not do
MCP is a protocol for advertising and invoking tools. Handed a request, it can execute "read this file" or "send this email." What it cannot do is decide that the task requires reading three files, summarising them, then drafting one email — and adapting when step two returns something unexpected. That sequencing, retrying, and state-keeping is not the model's job either; a model only emits text. Something has to run the model, read its proposed action, execute it, feed the result back, and loop. That something is the orchestrator.
So the division of labour is clean: the model proposes, MCP executes, and the orchestrator decides — it owns the loop, the memory, and the credentials the tools run under. It is the difference between a hand and the intent to reach.
Why the orchestrator is the security centre of gravity
Three properties of the loop make the orchestrator the thing an attacker actually wants:
- It closes the feedback loop. Tool results are appended to the context and shape the next decision. A poisoned observation — a web page, a file, an API response carrying hidden instructions — is now steering every subsequent step. This is indirect prompt injection with a persistence mechanism.
- It holds standing authority. The credentials the tools run under usually live with the orchestrator, not the user. Misdirect the loop and you are spending the orchestrator's privileges, not your own.
- It often has no ceiling. Without a bound on iterations, cost, or irreversible actions, a loop that goes wrong does not fail safely — it keeps calling tools until something external stops it.
There is a second, quieter reason the orchestrator matters: it is where memory lives. Many frameworks let the loop carry state between runs — scratchpads, summaries, a vector store of past interactions. That persistence is genuinely useful, and it also means a successful injection need not be a one-shot event. An instruction written into the agent's memory on Monday can resurface to steer a plan on Thursday, long after the poisoned content is gone. Persistent state turns a transient prompt-injection into something closer to a stored implant, and it is the orchestrator, not MCP, that decides whether such memory exists and how far it is trusted.
None of this is a reason to avoid orchestration; you cannot build a useful agent without it. It is a reason to treat the loop as privileged code. The single most effective control is an action ceiling: cap iterations, require human confirmation before irreversible or external actions, and never let a tool result silently re-enter as trusted instruction.
- Trace one real task and confirm whether tool outputs are fed back into the model verbatim. If a returned document can contain text the model then acts on, your observe step is an injection entry point.
- Ask what stops a loop that misbehaves: is there a cap on iterations or spend, and does any irreversible or external action require a human to approve it? If the honest answer is "nothing," that is the finding.
A quick trace tells you the shape of the risk. Mapping the true blast radius of the loop and driving injection through every observation path is a controlled engagement — the full, adversarial version — driven across every server, tool and content path — is what a Shadow AI Discovery assessment runs for you.
The orchestrator is where autonomy actually lives, which makes it where accountability has to live too. You can harden every tool and still be owned through the loop that calls them. Start by inventorying every orchestrated agent you run and, for each, the credentials its loop is holding — you cannot bound a blast radius you have never measured.