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

At a glance

What this is: This is an analysis of cross-cloud AI agent discovery and AI-BOM inventorying, with the key finding that security teams still lack continuous visibility into where agents are built and what they can access.

Why it matters: It matters because IAM, NHI, and autonomous governance all fail when teams cannot see the full agent estate, the delegated permissions behind it, or the runtime boundaries that should constrain it.

By the numbers:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read Lasso Security's analysis of cross-cloud AI agent discovery and AI-BOM governance

Context

AI agent discovery is the control problem that appears before policy, red teaming, or runtime enforcement can do any useful work. In practice, organisations are building agents in managed cloud platforms, low-code tools, and code repositories at the same time, which means the security team often sees fragments rather than a complete estate.

For IAM and NHI programmes, the issue is not just where the agent runs. It is who built it, which model it uses, what tools it can call, which data sources it can reach, and whether any cross-environment inventory exists that can keep pace as the configuration changes.

Cross-cloud visibility is typically the starting position that most teams assume they already have, but the article shows that assumption is often false. When discovery is incomplete, governance becomes reactive and the organisation cannot reliably scope risk across internal, customer-facing, or delegated agent workloads.

Key questions

Q: How should security teams inventory AI agents across multiple cloud platforms?

A: Security teams should treat every cloud platform, low-code builder, repository, and CI/CD pipeline as a discovery source. The goal is a living inventory that includes the agent owner, model, prompt, tools, data sources, and deployment context so governance is based on evidence rather than platform silos.

Q: Why does AI-BOM visibility matter for agent governance?

A: AI-BOM visibility matters because an agent’s behaviour is defined by its components, not by a single account record. When teams can see the model, prompt, tools, retrieval sources, and dependencies together, they can evaluate actual reach, delegated trust, and change impact with far more precision.

Q: What breaks when AI agent discovery is incomplete?

A: When discovery is incomplete, security teams cannot reliably assign ownership, scope permissions, or detect cross-environment drift. That creates blind spots in policy enforcement and red teaming, especially where business units build agents outside the main engineering path.

Q: How should organisations govern model selection for AI agents?

A: Organisations should treat model selection as a governance decision, not a local implementation detail. Approved models, restricted models, and external-facing models should be defined centrally so business teams cannot expand risk simply by choosing a different foundation model.

How it works in practice

Cross-cloud AI agent discovery and inventory

Discovery is the process of finding every agent across managed AI platforms, cloud environments, repositories, and CI/CD pipelines, then turning those findings into a living inventory. In this case, the inventory is not just a list of applications. It becomes the identity boundary for the agent estate, because model selection, prompts, tools, retrieval sources, and orchestration frameworks all shape what the agent can do. A point-in-time export is not enough when teams can change prompts or add tools after deployment. Practical control depends on continuous discovery across platforms that do not share a common governance plane.

Practical implication: establish continuous discovery across cloud and low-code platforms before trying to govern agent permissions or runtime policy.

AI-BOM and dependency graph visibility

An AI bill of materials, or AI-BOM, captures the components that define an agent, including the model version, system prompt, tools, retrieval sources, and dependencies. The dependency graph extends that inventory by showing how agents connect to APIs, databases, sub-agents, and external services. This matters because delegation chains create permission paths that are easy to miss if the team only reviews the parent workload. Once dependencies are mapped, static analysis can compare configured scope with actual reach and surface contradictions between intended behaviour and connected privilege.

Practical implication: require an AI-BOM for each agent and use the dependency graph to review delegated access paths and hidden transitive trust.

Model access control for agent governance

Model governance is not just a procurement question. The choice of foundation model changes the security boundary because different models are approved for different use cases, risk levels, and external exposure. If teams can choose models locally without security input, policy drift happens quickly across business units and cloud platforms. The article’s architecture shows that model policy belongs alongside inventory, not after it, because the model is part of the control surface that determines how the agent behaves and which downstream risk posture it inherits.

Practical implication: tie model approval policy to discovered agent inventories so model selection cannot happen outside security governance.

NHI Mgmt Group analysis

Cross-cloud AI agent discovery is now an identity control, not just an inventory task. Once agents can be created in Bedrock, Azure AI Foundry, Copilot Studio, Vertex AI, or code repositories, the old assumption that security can govern from a single console breaks down. The estate becomes distributed before it becomes visible, which means governance starts from absence rather than control. Practitioners should treat discovery as the first identity boundary for agentic systems.

AI-BOMs create the minimum viable evidence for agent governance. Security teams cannot reason about risk if they do not know the model, prompt, tools, retrieval sources, and dependencies that define an agent’s behaviour. That is a non-human identity problem with architectural consequences, because permissions are shaped by composition rather than by a single account record. Runtime governance gap: this is the failure mode exposed when an agent’s real control surface is spread across multiple builders and platforms. Practitioners should require a continuously updated AI-BOM before approving access or deploying policy.

Delegation chains make hidden privilege the default unless the graph is explicit. Multi-agent systems, sub-agents, and connected services can propagate permissions in ways that do not appear in a conventional app review. The article’s graph-based approach reflects the right direction for NHI governance because it exposes where authority is inherited, expanded, or left undefined. Practitioners should assume that every unmapped dependency is an unreviewed trust path.

Model choice is an access decision, not a technical preference. If business teams can select models independently, security loses the ability to enforce which stacks are acceptable for internal, external, or restricted use cases. That is why model policy belongs with identity governance and not only with AI platform administration. Practitioners should treat model approval as part of access governance, especially where the agent can reach sensitive data or production systems.

This topic reinforces the broader shift from static secret management to continuously governed agent estates. Discovery, assessment, and runtime protection only work when the organisation can see the full population of agents and how they change over time. That makes visibility the prerequisite for least privilege, not a complement to it. Practitioners should organise controls around the lifecycle of the agent, not around the lifecycle of a single deployment.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• A separate finding from the same survey shows that only 44% of organisations have implemented any policies to manage their AI agents, even though 92% agree that governing them is critical to enterprise security.
• For a deeper view of how this governance gap maps to practice, read the NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that apply once agents become governed identities.

What this signals

Runtime discovery is becoming the gatekeeper for agent governance. As organisations spread AI build activity across managed platforms, cloud environments, and code pipelines, the security programme can no longer assume a complete inventory exists at the point of policy review. The practical shift is toward discovery-driven governance, where ownership, model choice, and tool access are evaluated from the living estate rather than a project register. This is where the discipline starts to resemble NHI governance more than application security, because the object being managed is an evolving identity surface, not a static workload.

AI-BOMs are the bridge between inventory and enforceable policy. Once the organisation can map models, prompts, tools, retrieval sources, and sub-agents, it can begin to align access decisions with actual behaviour instead of platform labels. That makes the AI-BOM a control artifact, not just documentation. Teams that want to operationalise this pattern should align it with the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, especially where tool delegation and runtime drift are part of the estate.

Model selection now functions as an identity governance signal. When business units can choose models without security review, policy fragmentation follows quickly across internal and external use cases. With 70% of organisations already granting AI systems more access than human employees in the same role, according to the 2026 Infrastructure Identity Survey, the next phase is not more visibility alone but tighter control over what is allowed to become an agent in the first place.

For practitioners

• Build a cross-platform agent inventory first Map every low-code, no-code, repository-built, and cloud-native agent across managed AI platforms and cloud accounts. Include ownership, model, prompt, tool access, data sources, and deployment context so security can see the full population rather than isolated projects.
• Require an AI-BOM for every discovered agent Track the foundation model version, system prompt, connected tools, MCP servers, retrieval sources, guardrails, and dependency set. Use that record as the baseline for review when any of those elements changes.
• Review delegated permissions in multi-agent graphs Trace sub-agents, APIs, and external services to identify where permissions propagate beyond the parent agent. Pay special attention to boundaries that are assumed rather than explicitly defined.
• Tie model approval to governance policy Separate approved models for internal, external-facing, and restricted use cases. Block business-unit teams from selecting foundation models outside policy, even if the platform allows them to do so.
• Feed discovery into red teaming and runtime policy Use the inventory to target adversarial testing at the actual agent surface, then translate findings into inline policy updates at the proxy, API, or AI gateway layer.

Key takeaways

• Cross-cloud AI agent discovery is the prerequisite for any credible governance model because the estate is already distributed across managed platforms, cloud accounts, and development pipelines.
• The AI-BOM is the control artifact that turns agent composition into something security teams can review, test, and enforce.
• Practitioners should treat model approval, delegated tools, and dependency graphs as identity governance issues rather than isolated AI platform settings.

Key terms

• AI-BOM: An AI bill of materials is a structured inventory of the components that define an AI agent, including the model, prompt, tools, retrieval sources, and dependencies. In practice, it is the evidence base for review, change control, and risk assessment when the agent evolves after deployment.
• Agent Discovery: Agent discovery is the process of finding every AI agent across cloud platforms, low-code tools, repositories, and deployment pipelines. It matters because governance cannot start until the organisation can see where the agent exists, who owns it, and what it can reach.
• Delegation Chain: A delegation chain is the path by which authority flows from one component to another, such as a parent agent, sub-agent, API, or connected service. The security issue is not just the direct grant, but the inherited permissions and hidden trust paths that appear as the chain lengthens.
• Model Governance: Model governance is the set of controls that decides which foundation models can be used for which agent types and use cases. It links platform choice to security policy, because the model selection influences data exposure, tool behaviour, and the risk profile of the resulting agent.

Deepen your knowledge

AI agent discovery, AI-BOM governance, and delegated access review are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance programme for distributed agent estates, it is worth exploring.

This post draws on content published by Lasso Security: Discover Every AI Agent Your Organization Builds, Across Every Major Cloud Platform. Read the original.