Agent orchestration depends on expression, runtime and observability

At a glance

What this is: Agent orchestration is best understood as expression, runtime, and observability, and the article argues that most confusion comes from treating those layers as one problem.

Why it matters: IAM, PAM, and NHI teams need to treat agent control flow, durable execution, and traceability as separate governance concerns because each layer creates different identity and audit risks.

Context

Agent orchestration is the coordination of AI agent behaviour across control flow, execution durability, and visibility. The governance gap is that teams often discuss multi-agent design as if framework choice alone determines security, when runtime persistence and trace-level evidence are what make an agent governable in production.

For identity and access teams, the important question is not whether an agent uses tools, but how its permissions, state, and action history are preserved across long-running execution. Once orchestration becomes operational, identity controls need to follow the agent across the full lifecycle, not just at initial authentication.

Key questions

Q: How should teams govern agent workflows that mix parallel and sequential steps?

A: Separate the workflow design question from the security question. Use parallel expression only where tasks are loosely coupled, and keep sequential work tightly stateful when later steps depend on earlier ones. Governance should focus on where context is shared, where decisions branch, and where tool access is inherited across the flow.

Q: Why do agent runtimes change the security model for AI systems?

A: Agent runtimes change the security model because they control persistence, approval, sandboxing, and observability. That moves the trust boundary from the model response to the execution loop, where policy can be enforced consistently and where misuse can be detected and reconstructed.

Q: What are the signs that data observability is failing in a production environment?

A: Common signs include recurring data quality issues, slow root cause analysis, inability to trace a defect back to a specific pipeline change, and delays in identifying whether the source is the pipeline or an upstream system. When teams can see an issue only after consumers report it, observability is not providing enough proactive insight to prevent data downtime.

Q: When should organisations treat an AI agent as a high-risk identity?

A: Treat an AI agent as high-risk when it can move data, trigger production actions, or access multiple systems without direct human oversight. The more environments it spans, the more likely a single misconfiguration can create broad blast radius. In those cases, continuous review is safer than static approval.

Technical breakdown

Expression layer: control flow determines how agent decisions are structured

Expression is the layer where an agent’s workflow is written as a graph, loop, state machine, or handoff pattern. The architectural question is not whether the agent is intelligent, but how decisions are sequenced and shared across sub-tasks. Multi-agent fan-out can work when tasks are parallel and loosely coupled. A single-threaded pattern is better when each decision depends on the previous one. Security relevance appears when each step carries tool access or context that can diverge between branches. That is where orchestration becomes a governance problem, because design choices shape which actions can happen, in what order, and with what shared state.

Practical implication: Treat control-flow design as part of authorisation design, not just application logic.

Runtime layer: durable execution changes how agent state survives failure

Runtime is the layer that persists progress, replays events, and resumes work after interruptions. In durable execution systems, the agent is not a volatile chat loop in memory. Its actions are journaled to storage so that a worker crash, deploy, or disconnect does not destroy the task. That matters because long-running agents create a new governance requirement: state continuity becomes part of the security boundary. If state, permissions, or tool context are reconstructed incorrectly after recovery, the agent can continue operating with stale assumptions. For identity teams, the parallel is clear. Lifecycle control must extend through recovery, not stop at login or initial task start.

Practical implication: Verify that recovery preserves the correct permission state and does not resurrect stale access.

Observability layer: traces and replays are the evidence of agent behaviour

Observability is the layer that records traces, evaluations, replays, and failure signals so teams can explain what an agent actually did. Without it, production debugging becomes guesswork, especially when failures are subtle and intermittent. In agentic systems, the important artefact is not just the prompt or the final answer, but the full execution path, tool calls, and decision points. That creates a direct governance intersection with IAM and NHI oversight, because auditability now depends on preserving the identity context of each tool action. If an agent can act, retry, or hand off work without a clear trace, accountability breaks down even when the model output looks correct.

Practical implication: Require trace-level logging that ties each tool action to the agent identity, state, and execution step.

Threat narrative

Attacker objective: Exploit orchestration gaps to let an agent act with ungoverned state, opaque recovery, and insufficient auditability.

1. Entry begins when an agent is given framework-driven control flow and tool access for a business task, creating the first governance surface.
2. Credential and state misuse can follow if recovery logic, shared context, or tool permissions are reconstructed incorrectly after a failure or handoff.
3. Impact appears when the organisation cannot explain, replay, or audit what the agent actually did across a long-running execution.
4. The attacker objective in this pattern is not necessarily takeover of the model itself, but uncontrolled or unaccountable action through the agent’s runtime and tool permissions.

Breaches seen in the wild

• Twitter source code leak 2023: Twitter source code and internal tools were posted to GitHub by "FreeSpeechEnthusiast" and stayed public for months before a 2023 takedown.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent orchestration is becoming an identity control problem as much as an AI design problem. Once agents can hold context, call tools, and resume work across failures, the security question shifts from model quality to governed action. IAM and PAM teams need to think about who or what is authorised to continue acting after a pause, restart, or handoff. The practitioner conclusion is that orchestration policy and identity policy now need to be designed together.

Runtime durability creates a new form of standing privilege unless the recovery path is controlled. A durable agent can survive the failure that would normally end a session, which means stale permissions, stale context, or stale assumptions can also survive. That is a governance gap, not just an engineering convenience. The practitioner conclusion is that recovery must revalidate execution state before work continues.

Trace-level observability is the difference between agent governance and agent guesswork. If organisations cannot reconstruct which identity, tool, and step produced an action, then audit and incident review are already compromised. This is especially relevant for NHI and agentic AI programmes, where the actor can be software but the control obligation is still human-owned. The practitioner conclusion is that every meaningful agent action needs a durable evidence trail.

Context engineering is now a governance discipline, not just a prompt-engineering technique. The article’s central insight is that failures often come from structure, not intelligence, which means the organisation has to control what information is shared, when it is shared, and how it is preserved. That is especially relevant when agents operate as non-human identities with delegated tool access. The practitioner conclusion is to treat shared context as governed access, not informal memory.

What this signals

Context persistence is the new governance boundary for AI agents. Once an agent can resume after interruption, the security model has to protect not only authentication, but also the preserved task state that determines what the agent is still allowed to do. That creates a direct intersection with NHI governance, because software actors can outlive the human session that originally approved them.

Durable execution without traceable identity is operationally efficient but not governable. The practical risk is that recovery systems can keep work moving while silently weakening accountability. For security and IAM teams, the design question is whether every resumed action can still be tied to a known agent identity and a valid permission scope.

Agent orchestration should now be reviewed as part of access architecture, not only AI architecture. The teams that will manage this well are the ones that put identity, lifecycle, and audit requirements into the orchestration layer before production scale makes the gaps expensive. The immediate watchpoint is whether shared context is being treated as controlled access or informal convenience.

For practitioners

• Define orchestration boundaries by task topology Map which workloads need parallel expression and which require single-threaded context so you do not give every agent the same control pattern.
• Bind recovery to permission revalidation Require a fresh check of tool scope, context validity, and task ownership whenever a durable agent resumes after interruption or worker failover.
• Log every tool action at trace level Capture the agent identity, step number, tool invoked, and recovery event so investigators can replay the full execution path.
• Separate shared context from implicit memory Store the context an agent needs for continuation in governed state, and do not rely on hidden conversational history to carry control decisions.

Key takeaways

• Agent orchestration is a three-layer problem, and security failures appear when teams confuse control flow with runtime durability and traceability.
• Durable execution changes the governance model because an agent can resume work with preserved state unless that recovery path is explicitly revalidated.
• Observability is the practical control that makes agent behaviour auditable, which is why trace-level evidence matters as much as model output.

Key terms

• Agent Orchestration: Agent orchestration is the coordination of multiple AI agents or workflows to complete a task set with limited human intervention. In identity terms, it creates delegated execution paths that need ownership, scope limits, and auditability because work is no longer performed only by a person in one session.
• Durable Execution: Durable execution is a workflow design pattern that preserves state so a process can resume after failure without redoing completed work. In AI agent systems, it turns a fragile run into a recoverable sequence with replay, history, and auditability.
• Trace Observability: Trace observability is the ability to inspect a workflow step by step, including inputs, decisions, retries, and outputs. For AI agents, traces show where a loop is wasting tokens, hitting permission barriers, or failing to converge. That visibility supports debugging, cost control, and post-run review.
• Context Engineering: The practice of selecting, curating, and delivering the information an AI system uses at runtime. In agentic environments, context engineering is a security function because the quality, provenance, and trust level of the inputs directly shape the system’s actions and outputs.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for teams that need to govern software actors, delegated access, and identity risk in production systems.