It should focus on both, but orchestration design comes first because it defines who may act, what they can see, and how action is confirmed. Once a software entity can issue or receive directives, it effectively becomes an identity-bearing actor that needs bounded authority and traceable handoffs. Governance fails when those controls are separated.
Why orchestration comes before identity in agent governance
Agent governance starts with orchestration design because orchestration defines the decision boundary: who can issue work, which tools or data the agent may touch, which steps require confirmation, and what evidence exists after execution. Identity matters inside that design, but identity alone does not tell you how the agent is allowed to act, sequence actions, or hand off authority safely.
That is why treating identity as the first and only control is usually the wrong abstraction. A well-named agent with weak orchestration can still overreach, chain actions unsafely, or blur approval points. By contrast, a bounded orchestration model can constrain authority even when the underlying identity is valid and authenticated.
The practical test is simple: if you cannot describe the agent’s allowed actions, escalation points, and confirmation rules, you do not yet have governance, only authentication. Orchestration is the layer that turns a software entity from a connected component into a controlled actor.
What identity contributes once orchestration is defined
Identity becomes material after the orchestration model exists because it provides attribution, delegation boundaries, and lifecycle control. Once an agent can receive directives or issue them on behalf of another principal, it needs a durable identity state that can be registered, scoped, reviewed, and retired. That is the difference between “a process that ran” and “an accountable actor that was authorised to run.”
In practice, identity supports the governance questions that orchestration cannot answer on its own. It lets teams distinguish one agent from another, verify which human or system delegated authority, and decide whether the agent’s access should be time-bound, environment-bound, or task-bound. Without that identity layer, approvals and logs often collapse into generic system activity.
This is also where lifecycle discipline matters. An agent identity that is easy to create but hard to decommission becomes a standing risk, especially when orchestration paths, connectors, or tokens remain active after the original use case is gone.
How to balance both without creating a governance gap
The right balance is not “identity versus orchestration”, it is sequencing them correctly. First define orchestration rules for action boundaries, then bind those rules to a specific agent identity, then verify that the agent can only exercise the authority the orchestration layer intended. That order keeps policy from being separated from execution.
- Start with the actions the agent may take, not with the label on the agent.
- Bind each sensitive action to an explicit authorisation path or confirmation step.
- Use identity to record ownership, delegation, and retirement for the actor that executes the workflow.
- Review the agent when its toolset, data access, or delegation chain changes.
When those pieces stay coupled, governance can answer three questions consistently: what the agent may do, who approved that authority, and how the action was traced. When they drift apart, teams often discover too late that the orchestration allows more than the identity review ever intended.
Risk and Threat Considerations
Agent governance breaks down when orchestration and identity are managed as separate problems. The common failure mode is over-trust: a validly authenticated agent inherits broad tool access, and the system then treats its outputs as if they were already approved. That creates privilege creep, weak traceability, and a larger blast radius when the agent is misused or compromised.
Failure mechanism: Orchestration decisions are left implicit, so the agent can chain actions, call tools, or forward directives without a clear boundary between intent, approval, and execution. Identity may still be correct, but it no longer constrains behaviour tightly enough.
Impact: The organisation loses reliable attribution and control over agent actions, which can lead to unsafe automation, hidden escalation, and difficult-to-contain downstream effects across systems the agent can reach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack surface, NIST AI RMF sets the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent governance here centers on bounded authority and traceable action. |
| ASI02 — Tool Misuse | Orchestration must constrain which tools an agent may invoke and when. | |
| Recommendation — Restrict agent privileges and require explicit authorization boundaries for sensitive actions. Limit tool access to approved workflows and validate each tool call against policy. | ||
| CSA MAESTRO | Multi-Agent Environment, Security, Threat, Risk and Outcome | The question concerns orchestration, autonomy, and governance of agent behaviour. |
| Recommendation — Apply MAESTRO to model agent coordination, authority boundaries, and control points. | ||
| NIST AI RMF | AI Risk Management Framework | Agent governance needs structured risk, accountability, and oversight for AI systems. |
| Recommendation — Use the AI RMF to define govern, map, measure, and manage controls for agent behaviour. | ||
| ISO/IEC 42001:2023 | AI Management System | The question is about organisational governance of agentic systems and accountability. |
| Recommendation — Establish AI management responsibilities, approvals, and oversight for agent deployments. | ||
Practitioner Guidance
What to prioritise: Define the orchestration policy first, then assign identity to the actor that will execute it. If the agent can affect production data, external systems, or other agents, require an explicit control point before the action completes.
What to verify: Confirm that the agent’s logged identity maps to a specific owner, scope, and retirement path, and that the orchestration layer records the decision that authorised each sensitive step. If you cannot show both, the control is too weak to trust.
Common mistake: Treating authentication or registration as a substitute for governance. A well-managed identity with poor orchestration still allows unsafe delegation; a strong orchestration model with no accountable identity leaves you unable to review or revoke authority cleanly.
Practitioner takeaway: The safest pattern is to govern agent behaviour as an orchestrated actor with an identity, not as an identity that happens to run workflows.