Router, Orchestrator, or Prompt Chain? Agentic Patterns Are Security Choices
Back to all posts

Router, Orchestrator, or Prompt Chain? Agentic Patterns Are Security Choices

9 min read
#agentic-ai #ai-security #llm-security

Router, Orchestrator, or Prompt Chain? Agentic Patterns Are Security Choices

As teams adopt agentic AI, the conversation often starts with capability. Which pattern is more flexible? Which one is more autonomous? Which one produces better results?

Those are useful questions, but they are not enough.

An equally important question is this: how does each pattern change the security model of the system?

Router, prompt chain, orchestrator, parallel workers, evaluator loops, and subagents are usually described as architecture patterns. That is true, but they can also be viewed as trust patterns. They influence how context moves, how authority is delegated, how tools are invoked, and how far a bad decision can spread.

That is why agentic design should be examined through the same lens used for any serious security architecture: identity, access control, validation, containment, logging, traceability, and blast radius.

Patterns shape the attack surface

Recent guidance on agentic systems distinguishes between structured workflows and more autonomous agents, and it recommends starting with the simplest pattern that can reliably perform the task. Simpler patterns are often easier to test, easier to observe, and easier to contain.

That matters even more when security enters the picture, which should already be part of design phase.

Every additional layer of routing, delegation, memory, or tool use creates another decision point. Every decision point creates another place where a prompt can be manipulated, a context window can be poisoned, or a privilege boundary can weaken.

It is not enough to ask whether a pattern works. The more important security question is what that pattern allows the system to do when something goes wrong.

Prompt chains often provide clearer control points

Prompt chaining is often a sensible place to begin.

In a prompt chain, the workflow is broken into fixed steps. One prompt extracts, another classifies, another validates, another generates. This is not the most exciting pattern, but it is often easier to reason about than more open-ended agent behavior.

From a security perspective, prompt chains can support clearer control points:

  • Validation between stages.
  • Structured output checks.
  • Narrower tool access.
  • Easier audit trails.
  • Human approval before sensitive actions.

But prompt chains are not automatically safe. They create intermediate outputs, and those outputs can become trusted inputs for later steps. A poisoned extraction, a manipulated summary, or a malicious instruction embedded in retrieved content can still flow through the rest of the chain unless every stage treats prior output as untrusted until validated.

That aligns well with OWASP-style thinking. Inputs, intermediate state, and outputs all need validation. In agentic systems, that validation cannot stop at the first user prompt. It needs to continue through the full run.

Routers should be treated like policy boundaries

A router looks simple. It inspects a request and decides which model, prompt, tool, or specialist path should handle it.

That sounds operational, but it is also a policy decision.

When a router sends a request down the wrong path, the issue is not only answer quality. The request may reach a more privileged tool, a weaker prompt template, a less restricted memory store, or a downstream agent that was never meant to handle that class of task.

This is where agent design begins to overlap directly with security frameworks such as OWASP:

  • Classification decisions affect authorization.
  • Context selection affects data exposure.
  • Tool selection affects privilege use.
  • Fallback logic affects containment.

In that sense, a router does not merely organize work. It should be treated as a trust boundary.

That means router evaluation should include security tests, not just accuracy tests. It should be tested for misrouting, ambiguous prompts, prompt injection attempts, hostile retrieved content, and attempts to steer a request into a more privileged execution path.

Orchestrators can increase blast radius

Orchestrator-worker designs are powerful because they can decompose work dynamically and coordinate multiple specialized agents or tools.

They can also create a larger blast radius if access and delegation are not tightly controlled.

Once an orchestrator can plan, delegate, call tools, read memory, and re-route work, it begins to resemble a distributed control plane. If its reasoning is influenced by poisoned context or its permissions are too broad, a single bad decision can propagate across several workers, APIs, or systems.

This is where agentic security starts to resemble cloud security and identity architecture:

  • Delegation should be explicit.
  • Worker permissions should be scoped.
  • Tool access should be minimized.
  • State changes should be logged.
  • High-risk actions should require secondary approval.

An orchestrator with weak access boundaries may become a privilege multiplier.

Prompt injection has greater operational impact during runs

Prompt injection is already one of the best-known risks in LLM security, but it can become more dangerous in agentic systems because the model is not just answering questions. It may be deciding, routing, retrieving, writing, calling tools, or taking action.

OWASP’s prompt injection guidance is especially relevant here because it emphasizes two points that matter for agentic runs:

  • Both direct and indirect prompt injections can alter model behavior.
  • RAG, fine-tuning, and similar enhancements do not eliminate the risk.

That means the danger is not limited to a malicious user typing “ignore previous instructions.” It also includes hidden instructions inside webpages, tickets, documents, emails, logs, knowledge base entries, or images that an agent processes as part of its task.

In a standard chatbot, this may produce a bad answer.

In an agentic system, it can do much more:

  • Route a task to the wrong agent.
  • Trigger an unauthorized tool call.
  • Exfiltrate sensitive context.
  • Modify downstream decisions.
  • Influence memory for future runs.
  • Cause the system to act with the wrong objective.

The key shift is that prompt injection in agentic AI is not only a content problem. It is also a workflow problem.

Non-human identities are a critical control area

One of the most important and often under-emphasized issues in agentic AI is the rise of non-human identities.

Agents do not operate by magic. They use API keys, OAuth tokens, service accounts, certificates, session tokens, and machine credentials to access systems and perform work. As organizations add more agents, they also add more non-human identities, often with broad, persistent access.

That creates a serious security concern.

If an agent can route requests, retrieve private data, update records, call SaaS APIs, or trigger infrastructure changes, then its identity is just as important as its prompt. In many cases, it may be even more important.

This is where many agentic designs become fragile:

  • Shared credentials across agents.
  • Long-lived secrets.
  • Over-privileged service accounts.
  • Weak separation between read and write actions.
  • No clear mapping between an agent’s purpose and its permissions.

A stronger security design treats agents and tool pathways as distinct access subjects wherever practical. Access should be scoped to the minimum necessary permissions, validated continuously, logged clearly, and rotated automatically wherever possible.

In practice, that means applying zero-trust thinking to agentic systems:

  • No agent should inherit blanket access.
  • No tool call should be trusted without context and policy checks.
  • No credential should be treated as permanent.
  • No action should happen without clear attribution.

The phrase “non-human identity” may sound abstract, but in agentic systems it becomes operational very quickly. It can be the difference between a contained assistant and an unmonitored machine actor with production access.

OWASP is a useful framework

OWASP is becoming a useful language for thinking about these systems because it pushes security teams to move beyond generic AI safety concerns and focus on concrete failure modes.

For agentic systems, that means asking questions such as:

  • Can this agent be manipulated by direct or indirect prompt injection?
  • Can memory or retrieved context be poisoned?
  • Can the router send a request into a privileged path?
  • Are tool calls validated before execution?
  • Does each agent have its own scoped non-human identity where appropriate?
  • Are permissions aligned to task, or simply inherited for convenience?
  • Is there approval for high-risk actions?
  • Can the full run be reconstructed from logs?

That is where architecture becomes security.

The right pattern is not the one that appears most autonomous. It is the one that provides enough capability without giving away unnecessary trust.

Security-first pattern selection

A practical way to think about pattern choice is this:

  • Use prompt chains when control and verification matter most.
  • Use routers only when classification is strong enough to be trusted as a policy decision point.
  • Use orchestrators only when the value of dynamic delegation is worth the identity, access, and observability overhead.
  • Treat memory, retrieval, and external content as untrusted during every run.
  • Assign distinct non-human identities to agents and tool paths whenever possible.
  • Validate access continuously, not just at deployment time.
  • Assume prompt injection will be attempted and design so that it cannot easily turn into action.

Agentic systems do not fail only because the model says the wrong thing.

They also fail when the architecture allows the wrong thing to happen.

I’ve created an experimental Agentic Patterns Visualizer. Explore different patterns and security controls.

References and further reading