AI agent orchestration without hardcoded workflows raises new NHI risk

At a glance

What this is: GitGuardian’s demo of Google ADK and A2A shows runtime agent discovery and LLM-directed routing, with the key risk being that security checks can become optional if they sit inside the model’s decision loop.

Why it matters: IAM and NHI teams should treat agent discovery, routing, and completion as governance decisions, because once an LLM chooses the execution path, conventional workflow assumptions no longer guarantee that security controls will run.

👉 Read GitGuardian’s analysis of AI agent orchestration without hardcoded workflows

Context

AI agent orchestration is the control plane that decides which agents run, in what order, and when a task ends. In this demo, that orchestration is not hardcoded, so the model becomes part of the governance path rather than just the reasoning engine.

That creates an identity problem as much as an automation problem. When agent discovery happens at runtime and security scanning is optional to the model, the programme is no longer governing a fixed workflow. It is governing an execution path that can change with context, which is exactly where NHI guard rails become harder to guarantee.

Key questions

Q: What breaks when secret scanning is optional inside AI agent orchestration?

A: If a security control only runs when the model chooses it, the control is no longer mandatory and cannot be relied on to protect generated output. In practice, that creates an enforcement gap where unsafe content or secrets can move through the workflow whenever the model routes around the check. Mandatory controls must execute outside the model’s decision loop.

Q: Why does runtime agent discovery increase governance risk for NHI teams?

A: Runtime discovery expands the set of non-human identities that can be invoked without prewired orchestration, so the control problem shifts from static workflow design to access exposure. The more agents the orchestrator can surface, the harder it becomes to prove which identities were available, which were used, and whether that exposure matched policy.

Q: How should security teams govern LLM routing in production?

A: Treat routing as a policy-controlled layer. Define which models and providers can serve which request types, log every route decision, and attach ownership to the credentials used by the gateway. If routing changes affect data handling, approval should include security, privacy, and AI governance review before production rollout.

Q: How should security teams govern AI agent orchestration across multiple systems?

A: Security teams should govern AI agent orchestration by mapping every agent, connector, and handoff to a clear owner, entitlement scope, and approval boundary. The key is to manage delegated action paths, not just sign-in events. That means tying observability, access reviews, and lifecycle controls to the full workflow, including APIs, memory, and downstream tool use.

Technical breakdown

Runtime agent discovery turns orchestration into an identity control point

The demo uses an agent registry and AgentCard discovery so the host can find sub-agents without prior wiring. That means the orchestrator does not just call known endpoints. It enumerates available non-human identities at runtime, converts them into callable tools, and lets the LLM choose from that set. In identity terms, discovery becomes part of authorisation: the model can only route to what is surfaced, but it still decides which actor is invoked and when the sequence stops.

Practical implication: Treat runtime discovery as an identity boundary and govern which agents are exposed to the orchestrator.

LLM-driven routing changes the trust model for non-human identities

Hardcoded workflows preserve predictable control flow because each step is pre-authored. LLM-driven routing replaces that with policy-by-instruction, where the model decides the next agent and the completion point inside the same session. That does not make the system autonomous in the strict sense unless the three autonomy conditions are present, but it does move the operational trust decision into runtime orchestration. The result is a looser, less auditable path between task intent and agent invocation.

Practical implication: Separate routing logic from safety logic so task selection cannot disable mandatory checks.

Guard rails must sit outside the model’s decision loop

GitGuardian’s own pattern is the critical one: secret scanning should run every time, regardless of whether the LLM chooses it. When a security control is optional to the model, it ceases to be a control and becomes a suggestion. This is the core governance lesson for NHI programmes, because secret detection, content inspection, and policy enforcement must not depend on the same runtime that is trying to optimise the task outcome. Otherwise the control and the thing being controlled share a failure domain.

Practical implication: Place mandatory inspection and policy enforcement in the execution path, not in model instructions.

NHI Mgmt Group analysis

Runtime agent discovery creates an identity blast radius problem. Once agents are discovered at execution time, the control issue is no longer just which tool the LLM chooses. It is which identities are made available to a runtime decision-maker, and how quickly that set can expand or change. That makes inventory and policy around exposed agents a first-class governance concern for NHI programmes, not an implementation detail.

Hardcoded orchestration and LLM-directed orchestration fail in different ways. Static workflows are brittle but reviewable. Runtime routing is flexible, but it pushes execution decisions into the model’s decision loop, where traditional approvals and step-by-step controls lose visibility. The practical implication is that teams must distinguish workflow flexibility from governance flexibility, because one does not guarantee the other.

Security scanning becomes unenforceable when the model can skip it. The article’s central governance gap is not agent collaboration itself but optional security controls inside the orchestration path. That is a named NHI risk pattern: control optionality inside runtime orchestration. If a control can be omitted by the model, it is not a control boundary. Practitioners need to treat that as a design failure, not a tuning issue.

A2A broadens interoperability, but interoperability does not equal trust. A standard for agent-to-agent communication helps systems connect across frameworks and vendors, yet it also widens the number of identities that can be discovered, invoked, and combined at runtime. For NHI governance, that means the burden shifts from integration feasibility to authorisation discipline and lifecycle visibility. The field should expect more agent sprawl unless runtime exposure is tightly governed.

Agentic orchestration will force NHI teams to move from workflow review to policy review. The important question is no longer whether the workflow is elegant. It is whether the orchestration layer preserves mandatory controls even when the model changes the path. That changes how NHI programmes think about approval, escalation, and inspection, because the real control point is now the set of actions the model is allowed to trigger.

From our research library:

• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
• Read next: AI Agent Authorisation Guide

What this signals

Control optionality inside orchestration is the real NHI failure mode. When a model can decide whether a control runs, the control has already moved outside governance. For identity teams, the issue is not whether agents can collaborate, but whether collaboration can ever override mandatory enforcement. That is why runtime orchestration needs policy boundaries, not just better prompts.

AI agent discovery should be treated like an access review problem. If the orchestrator can enumerate agents dynamically, then every discovered agent is an exposure decision. The governance programme needs a way to answer which agents were visible at runtime, which identities they represented, and whether those exposures were expected for the task.

Least-privileged AI access materially changes incident likelihood. Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey. That gap is large enough to make privilege scope, not model capability, the decisive control variable in agentic programmes.

For practitioners

• Define mandatory controls outside model discretion Run secret scanning, policy checks, and blocking rules in the execution layer so the LLM cannot suppress them by choosing a different path.
• Restrict which agents are discoverable at runtime Limit registry exposure to approved agents only, and treat agent discovery as an access-control decision rather than a convenience feature.
• Separate orchestration logic from safety logic Keep routing, completion, and task decomposition separate from controls that detect secrets, unsafe content, or policy violations.
• Set hard stop conditions for agent loops Use maximum-turn and termination rules that prevent runaway orchestration while preserving an audit trail of which agents ran.
• Inventory agent-facing identities and permissions Map every agent, registry entry, and downstream credential path so you can see which non-human identities the orchestrator can invoke.

Key takeaways

• Runtime agent orchestration creates an NHI governance problem because the model can influence which non-human identities are invoked and whether controls run.
• The central risk is optional enforcement, not agent collaboration itself, because any security check that the model can skip is not a dependable control boundary.
• Practitioners should move mandatory inspection, exposure limits, and loop termination outside the model’s decision loop to keep orchestration auditable and enforceable.

Key terms

• Runtime Agent Discovery: Runtime agent discovery is the process of finding callable agents during execution rather than from a fixed build-time list. In NHI governance, it expands the exposure surface because the orchestrator can surface new non-human identities dynamically and decide whether they are eligible to run.
• Agent Card: An Agent Card is a machine-readable description of an agent’s capabilities, endpoint, and invocation details. In A2A-style systems it helps other agents discover and call the agent at runtime, which makes the card a governance object as much as a technical descriptor.
• Orchestration Guard Rail: An orchestration guard rail is a control that must run regardless of what the model decides during task execution. For agentic systems, it is the difference between optional guidance and enforced policy, and it should sit outside the LLM’s decision loop.
• Control Optionality: Control optionality occurs when a security check is treated as one possible step rather than a mandatory one. In AI agent systems, it is a governance failure because the model can route around the check, leaving the control dependent on the very system it is supposed to constrain.

What's in the full article

GitGuardian's full blog post covers the operational detail this post intentionally leaves for the source:

• The agent discovery and registration pattern used by the orchestration demo
• The A2A and ADK implementation details for wiring host and sub-agents together
• The security-agent scan flow that flags exposed secrets in generated content
• The max-turn guard rail used to prevent runaway orchestration

👉 GitGuardian’s full post shows the runtime discovery flow, the guard rail pattern, and the secret-scanning demo details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.