How do security teams decide which agent identity controls belong in orchestration versus infrastructure layers?

Why This Matters for Security Teams

For agentic systems, the core design question is not simply who can log in, but which control plane owns delegation and which layer must enforce containment. Orchestration decides intent, approvals, and task boundaries; infrastructure decides whether the agent can actually reach tools, services, and secrets. When those responsibilities blur, teams either give the harness too much trust or assume the host layer will compensate for weak orchestration. The result is inconsistent audit trails and privilege that is harder to reason about.

This distinction shows up repeatedly in current guidance from the OWASP Agentic AI Top 10 and in NHIMG research on how organisations manage Non-Human Identities. The practical issue is that autonomous agents do not follow stable access patterns. They chain tools, branch on results, and may request additional scope mid-task. That makes static IAM reviews too coarse unless the orchestration layer can express intent and the infrastructure layer can verify runtime identity.

In practice, many security teams encounter overtrust in the orchestration harness only after an agent has already reached a sensitive toolchain or production API.

How It Works in Practice

A useful separation is to treat orchestration as the policy decision plane and infrastructure as the enforcement plane. Orchestration should decide whether an agent may delegate to another agent, whether human approval is required, what task scope is valid, and whether a step-up control is needed. Infrastructure should enforce workload identity, short-lived credentials, network segmentation, and access to secrets or tool endpoints.

That usually means combining policy-as-code with workload identity. A runtime policy engine can evaluate the request context at each step, while the host or platform layer proves what the agent is through cryptographic identity. Standards and implementation guidance increasingly point toward workload identity patterns such as SPIFFE, OIDC, and short-lived tokens rather than long-lived static secrets. For agentic systems, this is especially important because the identity must be tied to the workload instance and the task context, not just to the application name.

Operationally, security teams often map controls like this:

• Orchestration: delegation graph, approval workflow, task scoping, tool selection, and session termination rules.
• Infrastructure: sandboxing, network egress restrictions, token issuance, secret retrieval, and attestation of the running workload.
• Shared: logging, traceability, and policy evaluation at request time, not only at deployment time.

This approach aligns with the CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework, both of which emphasize governance, measurement, and operational controls around AI behaviour. NHIMG’s coverage of agent identity risks also shows why static credential assumptions fail once agents begin acting autonomously across tools and services. These controls tend to break down in multi-tenant orchestration platforms that reuse one trust boundary for many agents because the platform cannot reliably prove which task is invoking which downstream action.

Common Variations and Edge Cases

Tighter separation often improves auditability but increases integration overhead, requiring organisations to balance containment against delivery speed. The hardest cases are systems where the orchestrator and runtime sit in the same product, or where a single agent spans cloud services, local tools, and SaaS APIs. In those environments, it is easy to mistake platform convenience for security isolation.

Best practice is evolving, but current guidance suggests a few consistent patterns. First, delegation decisions belong higher up the stack, where approval logic and task intent can be evaluated. Second, enforcement belongs closest to the workload, where the platform can revoke access, limit egress, and attest runtime state. Third, static credentials should be replaced with short-lived, task-bound secrets whenever possible, because long TTLs make autonomous behaviour harder to contain.

There is also a common edge case around shared infrastructure teams. If platform engineers own the enforcement layer while application teams own orchestration, responsibilities must be explicit or the system becomes ungovernable. NHIMG’s analysis of NHI security confidence and the broader breach analysis both point to the same failure mode: organisations discover privilege drift after an incident, not through a clean design review. In the current state of practice, there is no universal standard for this yet, so teams should document layer ownership, verify runtime identity, and test whether the orchestration plane can fail closed when infrastructure policy rejects an action.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• How should security teams decide whether an AI agent gets human or non-human identity?
• How should security teams govern agent access when identity controls must be API-first?
• How do security teams decide whether an AI agent needs PAM-style controls?