AI agent orchestration without hardcoded workflows raises new NHI risk

At a glance

What this is: This demo shows runtime-discovered AI agents coordinated through A2A, with secret scanning added as one agent in the workflow.

Why it matters: For IAM and NHI teams, it highlights how agent discovery and model-driven routing create new control points that cannot depend on the LLM’s judgment alone.

👉 Read GitGuardian's analysis of A2A agent orchestration and secret scanning

Context

AI agent orchestration is becoming more dynamic, which means identity and access controls now have to govern systems that choose their own execution path. In this demo, the security problem is not just whether agents can communicate, but whether discovery, delegation, and completion logic remain bounded when the model is deciding what happens next. That is an NHI governance problem because each agent operates with execution authority and can expand the blast radius if controls are optional.

The article frames a real tension for practitioners. Runtime discovery reduces hardcoded workflow sprawl, but it also makes agent membership, sequencing, and termination dependent on a model and a registry. That is typical of early agentic AI implementations, where flexibility is prioritized before durable governance patterns are in place. For IAM leads, the key question is whether agent identity, tool access, and security checks are enforced independently of orchestration logic.

Key questions

Q: How should security teams govern AI agents that can discover other agents at runtime?

A: Security teams should treat runtime discovery as an authorization event, not a convenience feature. Every discoverable agent needs a clear identity, a bounded capability description, and policy enforcement that decides whether invocation is allowed. Discovery should expand visibility, not permissions. If an agent can be found at runtime, it should still be subject to least privilege, logging, and approval rules.

Q: When should secret scanning happen in an AI agent workflow?

A: Secret scanning should happen every time the workflow runs, before content can be used downstream or persisted. If the scan only occurs when an LLM chooses to call a security agent, the control is optional and can be skipped. Deterministic scanning outside the model loop is the safer pattern because it does not depend on the model’s judgment or task completion decisions.

Q: What is the difference between agent orchestration and agent authorization?

A: Orchestration decides the order in which agents work and how tasks move between them. Authorization decides whether an agent is allowed to do a specific action at all. In mature NHI governance, orchestration can be dynamic, but authorization must remain fixed by policy. That separation prevents a model from turning routing flexibility into unrestricted access.

Q: Should organisations let an LLM decide when an agent workflow is complete?

A: Organisations can let an LLM suggest completion, but they should not rely on it as the only stop condition. A hard turn limit and explicit termination rules are necessary because the model can fail to stop, stop too early, or optimize for output instead of safety. Completion should be bounded by workflow policy, not just model output.

Technical breakdown

How A2A agent discovery changes the trust model

A2A, or Agent-to-Agent protocol, gives agents a standard way to expose capabilities through an AgentCard and be discovered at runtime. That replaces hardcoded service-to-service wiring with dynamic registration and lookup. The trust model changes because the orchestrator no longer needs prior knowledge of each agent, but it must trust the registry, the capability description, and the policy that decides which agent can be invoked. In NHI terms, this is closer to dynamic workload identity than static application integration, and it increases the importance of authorization at invocation time.

Practical implication: Treat agent discovery as an authorization problem, not just an integration convenience.

Why LLM-driven orchestration creates privilege ambiguity

When the LLM decides which agent to call and when to stop, the model becomes part of the control plane. That introduces privilege ambiguity because the same runtime that generates output is also making delegation decisions. If the host agent can choose any registered capability, then least privilege depends on the quality of the instruction set, the registry scope, and any policy boundaries around tool use. This is especially sensitive for NHI because agents can act autonomously, but autonomy should not imply unrestricted choice.

Practical implication: Separate the model’s routing freedom from the permissions it can actually exercise.

Why guard rails should sit outside the model loop

Security scanning is a good example of a control that should not be optional. If secret detection only happens when the model chooses to call a security agent, then the security layer is probabilistic, not enforced. In production, secret scanning, policy checks, and high-risk approvals should execute as deterministic controls around the workflow, not as agent suggestions inside it. That distinction matters because the model can fail, stop early, or optimize for task completion instead of risk reduction.

Practical implication: Make secret scanning and policy enforcement unconditional control points.

Threat narrative

Attacker objective: The attacker objective is to move secrets or sensitive content through a dynamic agent workflow and reach systems the workflow can access.

1. Entry occurs when a registry exposes agent capabilities at runtime and the orchestrator accepts newly discovered agents without hardcoded allowlists.
2. Escalation follows when the LLM is allowed to select tools and delegate work, creating a route for broad agent privilege use if policies are weak.
3. Impact occurs when a malicious or careless agent processes content containing exposed credentials or secrets that should have been blocked before execution.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Dynamic agent discovery creates an identity blast radius, not just an automation advantage. When agents can appear at runtime, the security boundary shifts from static code paths to registry trust, capability descriptions, and invocation policy. That means the governance problem is no longer only who can log in, but which autonomous components can be discovered and delegated to at all. Practitioners should treat discovery as part of the access model.

LLM-driven orchestration is a control-plane decision, so it must be constrained like one. Letting the model choose the next agent may be acceptable in a demo, but it is too loose for production workflows that touch secrets, credentials, or regulated data. The decisive question is whether the model can only route within pre-approved boundaries. Teams should separate orchestration flexibility from authorization authority.

Runtime guard rails are the difference between agentic convenience and NHI governance. Secret scanning, policy checks, and termination conditions should execute deterministically, even when the model misroutes or stops early. If the security step depends on model choice, the control is advisory rather than enforced. Practitioners should design these checks as non-bypassable workflow controls.

Model-agnostic agent stacks will pressure enterprises to standardize NHI policy faster. The more easily agents can move across models, clouds, and frameworks, the less value there is in treating identity controls as platform-specific. That will push teams toward reusable policy, central discovery governance, and consistent audit logging. Practitioners should plan for identity control portability now, not later.

Named concept: runtime orchestration trust debt. The more decisions a model makes about agent selection, completion, and sequencing, the more security debt accumulates in runtime trust assumptions. That debt is manageable only if teams enforce policy outside the model and reduce what the model is allowed to decide. Practitioners should measure and shrink that trust debt before agent sprawl turns it into a systemic control gap.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and they are 13% more likely to be categorised as critical than code-based leaks.
• For deeper context on runtime exposure paths, see Guide to the Secret Sprawl Challenge for how sprawl turns discovery into a continuous governance problem.

What this signals

Runtime orchestration trust debt: as agent discovery becomes more dynamic, the control problem shifts from static permissions to the trust assumptions embedded in orchestration itself. NHI programmes should prepare for agent cards, registries, and routing logic to become part of audit scope, especially when workflows touch credentials or regulated content.

With AI-related credential leaks surging 81.5% year over year in 2025, according to The State of Secrets Sprawl 2026, agentic workflows should be treated as potential amplifiers of existing secret exposure paths. That means security teams need revocation, scanning, and logging controls that remain effective even when orchestration changes at runtime.

For practitioners

• Separate orchestration from enforcement Keep secret scanning, approval gates, and policy checks outside the LLM decision loop so they run on every execution, not only when the model asks for them.
• Inventory every discoverable agent Track which agents register with your discovery layer, what capabilities they advertise, and which workflows can invoke them. This creates a usable control inventory for reviews and incident response.
• Limit the model’s routing authority Allow the host agent to choose among pre-approved actions, but do not let it expand its own toolset or bypass high-risk steps such as scanning sensitive content.
• Bind agent identity to runtime policy Tie agent cards, registry entries, and execution permissions together so that discovery does not become a shadow access path. Review those bindings whenever a new agent is added.

Key takeaways

• Dynamic agent discovery changes NHI governance by making registry trust and capability exposure part of the access model.
• If secret scanning only happens when the model chooses it, the control is advisory, not enforced.
• Enterprises should separate routing flexibility from authorization authority before agent sprawl turns into unmanaged access.

Key terms

• 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.
• Runtime Orchestration: Runtime orchestration is the process of deciding which agent runs next, what it should do, and when the workflow stops. In agentic systems, this can be handled by an LLM, but that makes the orchestration layer part of the security boundary and not just application logic.
• Guard Rail: A guard rail is a control that must run regardless of model choice or task flow. For NHI and agentic AI, examples include secret scanning, policy enforcement, approval checks, and turn limits that prevent the model from bypassing security requirements.

What's in the full article

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

• The full A2A demo code path for discovery, registry registration, and host-agent routing.
• The GitGuardian scan flow, including the request structure used to check generated content for exposed secrets.
• The max-turn guard rail and how the orchestration loop avoids runaway execution.
• The practical integration pattern for using a security agent as a deterministic control instead of an optional model choice.

👉 GitGuardian's full post covers the discovery flow, LLM routing loop, and secret-scanning guard rail pattern.

Deepen your knowledge

Agent discovery, runtime routing, and guard rail design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI agents that can delegate to each other, it is worth exploring.