Topic starter
19/12/2025 11:16 am
TL;DR: GitGuardian shows that Google ADK and A2A can let a host LLM discover agents at runtime, route work, and stop when it decides the task is complete, which removes hardcoded workflows but also shifts control over agent invocation into the model’s decision loop. Runtime orchestration only stays governable when guard rails such as secret scanning remain mandatory outside the LLM’s discretion.
Editorial analysis by NHI Mgmt Group, based on content published by GitGuardian: “Building a Multi-Agent Security Pipeline with Google's A2A Protocol and GitGuardian”.
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.
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.
Q: How should security teams govern LLM routing in production?
A: Treat routing as a policy-controlled layer.
Practitioner guidance
- 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.
Bottom line: Runtime agent orchestration creates an NHI governance problem because the model can influence which non-human identities are invoked and whether controls run.
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
👉 Read GitGuardian’s analysis of AI agent orchestration without hardcoded workflows →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 10 months ago by Abdelrahman
This topic was modified 5 days ago by NHI Mgmt Group
07/10/2026 6:13 pm
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.
A few things that frame the scale:
- Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
A question worth separating out:
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.
👉 Read our full editorial: AI agent orchestration without hardcoded workflows raises new NHI risk