Cross-cloud AI agent discovery is becoming an IAM control point

At a glance

What this is: This piece argues that cross-cloud AI agent discovery is now an IAM control point because security teams cannot govern model choice, tool access or runtime behaviour without a live inventory of agents.

Why it matters: IAM, IGA and platform security teams need a single view of AI agents because governance breaks down when business units can build agents across multiple clouds and no-code platforms outside central oversight.

Context

Cross-cloud AI agent discovery is the governance problem that appears when organisations can create agents in managed cloud services, no-code builders and custom cloud environments without a shared inventory. In practice, that means the security team may not know which agent owns which model, tools, prompts or data connections.

For IAM and NHI programmes, the issue is not just discovery for its own sake. Once an organisation builds agents across multiple platforms, identity scope, tool access and delegation boundaries stop being manageable from a single control plane, so governance has to start at inventory time.

Key questions

Q: How should security teams evaluate running AI agent platforms inside their own cloud environment instead of a separate hosted deployment?

A: Security teams should evaluate whether the platform can inherit existing cloud controls without creating a parallel trust domain. The key test is whether policies, permissions, monitoring, and isolation all remain inside the customer account with minimal extra configuration. If deployment still requires special exceptions, manual review, or broad permissions, the security benefit of self-hosting is much smaller.

Q: Why does incomplete AI asset inventory create so much risk for AI security testing?

A: Incomplete inventory breaks the testing programme before it starts because you cannot validate systems you cannot see. AI deployments often span cloud services, endpoints, browsers, local models, and internal infrastructure, so hidden assets escape policy, testing, and monitoring. That leaves gaps in governance, increases shadow AI exposure, and makes security evidence unreliable when teams need it most.

Q: What are the signs that AI governance is failing in the enterprise?

A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk. Another indicator is weak visibility into who is using which tools and what data they are sending. If teams cannot answer those questions, governance is not working as intended.

Q: What happens when multi-agent delegation is not mapped?

A: Permissions can propagate farther than intended, especially when parent agents, sub-agents, APIs and databases are connected through undocumented chains. The result is an expanded attack and misuse surface that policy cannot reliably constrain because no one can prove where authorisation begins or ends.

How it works in practice

Why cross-cloud agent discovery fails as a governance model

AI agents built in separate services such as Bedrock, Azure AI Foundry and Copilot Studio do not naturally converge into one inventory. Each platform exposes different metadata, different permission surfaces and different lifecycle events, so a security team sees fragments instead of an authoritative record. That fragmentation matters because the security decision is not only whether an agent exists, but which model it uses, which tools it can reach and whether its permissions match its intended scope. When discovery is incomplete, governance becomes reactive and policy enforcement starts after deployment instead of before use.

Practical implication: centralise discovery across cloud platforms before attempting policy enforcement or risk assessment.

AI-BOMs and dependency graphs as control evidence

An AI Bill of Materials is more than an asset list. In this context it is the structured evidence that ties an agent to its model version, system prompt, tools, retrieval sources, guardrails and third-party components. The dependency graph then shows how those components connect, including sub-agents, APIs and databases, which is essential when permissions propagate through delegation chains. This is where governance becomes architectural: if the graph is missing, security teams cannot tell whether a tool call, data path or downstream permission is legitimate. The inventory is therefore the control surface for both authorization and change detection.

Practical implication: treat AI-BOM completeness and dependency mapping as required evidence for agent approval and review.

Runtime policy depends on discovery hygiene

The article links discovery to red teaming and runtime protection because those controls depend on a current view of the agent. If the inventory is stale, red-team targeting can miss the real tool surface and runtime policy can block the wrong path while leaving the actual path exposed. That is especially important for low-code and no-code agents, where business users may change prompts, tools or model selections without engineering involvement. The control lesson is that discovery is not a one-time onboarding step. It is the prerequisite for every downstream decision about access scope, guardrails and behavioural monitoring.

Practical implication: wire discovery updates into change management so red teaming and runtime controls operate on current agent state.

NHI Mgmt Group analysis

Cross-cloud AI agent discovery is now an IAM dependency, not an inventory nice-to-have. The moment agents can be created in multiple clouds and no-code platforms, governance loses the ability to answer basic ownership and scope questions. That makes discovery the point where IAM, NHI and AI security intersect, because access cannot be governed for an identity that is not yet visible. Practitioners should treat undiscovered agents as unmanaged identities until proven otherwise.

AI-BOMs create the minimum viable control evidence for agent governance. A live record of model, prompt, tool set, retrieval sources and orchestration framework is what lets teams review whether access matches intent. Without that record, policy checks are blind to drift, and drift is where agent risk accumulates. The practitioner takeaway is to make AI-BOM completeness a gating condition for approval, not a documentation afterthought.

Runtime enforcement inherits the quality of discovery upstream. If security teams do not know where agents live, they cannot measure whether guardrails reflect the current tool surface or whether delegated permissions have expanded. That is a structural governance problem, not just a tooling gap. The implication is that cross-cloud visibility must be managed as a living identity control plane, not a periodic audit artefact.

Low-code and no-code agent builders widen the gap between who creates an agent and who owns the risk. Business teams can now introduce new runtime identities without touching traditional engineering workflows, which means policy must follow the builder location as well as the deployment location. Discovery therefore becomes the mechanism that restores accountability across teams. Practitioners should align review and approval workflows to the places where agents are actually created.

Identity blast radius is the right concept for multi-agent environments. Once a parent agent can delegate to sub-agents, APIs and databases, the relevant question is not just what exists, but how far a single identity can propagate privilege. Discovery and dependency graphs make that blast radius visible. The field needs to move from static inventory thinking to propagation-aware governance.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

AI agent discovery is becoming the control plane for runtime governance. As organisations build agents outside engineering teams, the practical question is no longer whether an agent exists but whether security can observe its full identity surface before it is used. That pushes discovery ahead of policy, red teaming and runtime blocking.

Identity blast radius is the useful lens for multi-agent programmes. A parent agent that can delegate to sub-agents, APIs and data stores changes the governance problem from a single access decision to a propagation problem. Teams should prepare to review where privilege can travel, not just where it starts.

For practitioners

• Map every agent source to a single inventory Connect managed cloud AI services, no-code builders, cloud environments and CI/CD repositories into one continuously updated discovery process so the organisation can see every agent in one place.
• Require an AI-BOM before approval Make model version, system prompt, tools, retrieval sources, guardrails and orchestration framework mandatory fields before an agent can move into production review.
• Trace delegation chains for every multi-agent flow Document which parent agents can pass permissions to sub-agents, APIs and databases so hidden privilege propagation can be reviewed against intended scope.
• Tie red teaming to current inventory state Use the discovered agent graph as the target set for posture testing so static, multi-turn and high-agency attacks align to the actual runtime surface.
• Govern model choice as an access decision Set explicit policy for which foundation models are approved for internal, external-facing and restricted use, then review model selection alongside tool access and data reach.

Key takeaways

• Cross-cloud AI agent discovery is now a governance requirement because agents are being created in multiple environments outside a single control plane.
• Without a live inventory, teams cannot validate model choice, tool access or delegated permissions across business-built and engineering-built agents.
• The practical control shift is from periodic review to continuously updated discovery that feeds approval, red teaming and runtime enforcement.

Key terms

• AI Agent Discovery: AI Agent Discovery is the process of finding and cataloging software agents that operate with some independence across systems, data, and workflows. It identifies where agents run, what they can access, which identities they use, and how they connect to tools, APIs, and other services for governance and security.
• AI bill of materials: An inventory of the components used by an AI development environment, including models, plugins, hooks, skills, and agent integrations. It gives security teams visibility into what is operating in the stack so they can assess trust, dependency risk, and governance coverage.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.