TL;DR: Enterprise AI agent creation is spreading beyond R&D into business teams, expanding exposure to sensitive data, uncontrolled access, and unauthorized actions as agents connect to internal systems, according to Lasso Security. Build-time discovery and dependency mapping matter because security cannot rely on post-deployment review when agent trust, access, and delegation are established before production.
At a glance
What this is: This is a product-led analysis of AI security posture management for enterprise agents, with the key finding that build-time discovery and dependency mapping are becoming necessary before agents reach production.
Why it matters: It matters because IAM, NHI, and emerging agent governance programmes now have to control who or what builds, connects, and delegates access across AI agents before those paths harden into standing risk.
👉 Read Lasso Security's analysis of secure-by-design AI agents and AI-SPM
Context
AI agent security posture management is the discipline of finding, mapping, and governing agents before they reach production. The article’s core claim is that agents are now being built outside traditional engineering teams, which shifts risk from isolated development workflows into business processes that connect to internal resources, APIs, databases, and applications.
That changes the identity problem as much as the security problem. Once an agent can connect to multiple internal components, the question is no longer only whether the agent is allowed to run, but who owns it, what it can reach, how delegation is structured, and whether the organisation can see those links early enough to prevent overreach. Use the OWASP NHI Top 10 and the Ultimate Guide to NHIs as the baseline for that governance model.
Key questions
Q: How should security teams govern AI agents that connect to internal systems?
A: Security teams should treat AI agents as governed identities, not just applications. That means assigning ownership, capturing dependencies, and reviewing what each agent can reach before deployment. The main failure mode is letting agents inherit access to APIs, databases, or business apps without a clearly mapped delegation boundary.
Q: Why do AI agents create more governance risk than ordinary automation?
A: AI agents create more governance risk because they can combine tools and internal resources into a live workflow that changes as the task evolves. Unlike fixed automation, the access path may involve multiple non-human identities and delegated permissions, which makes visibility and accountability harder to maintain.
Q: What breaks when AI agent discovery is delayed until after deployment?
A: When discovery is delayed, security teams lose the chance to catch ownership gaps, hidden dependencies, and over-broad access before the agent starts operating. At that point, the workflow may already be connected to sensitive systems, and the risk becomes embedded in production behaviour rather than caught in review.
Q: How should organisations prioritise fixes for AI agent security findings?
A: Organisations should prioritise the agents with the widest connected footprint, the highest business criticality, and the most unclear ownership. That approach focuses remediation where the delegation chain creates the greatest operational exposure, instead of treating every finding as equal.
Technical breakdown
AI agent discovery and dependency graphs
AI-SPM starts with discovery, then turns each agent into a dependency graph that links its creator, owner, creation time, usage, and connected components. That graph is not just inventory. It is the control surface that shows how the agent reaches LLMs, APIs, databases, sub-agents, MCPs, and business applications, and where the trust boundary shifts from one component to another. In identity terms, the graph exposes how many non-human identities are participating in one workflow, and where governance can fail if any link is invisible.
Practical implication: security teams need an authoritative agent inventory that includes ownership and dependency relationships, not just a list of deployed models.
Delegation chains, MCPs, and missing authorisation boundaries
A connected agent rarely acts alone. It relies on a chain of tools and services, and each handoff creates a delegation boundary that can be weak, absent, or misunderstood. When the article refers to sub-agents, APIs, databases, and MCPs, the technical issue is not only connectivity but delegated authority: which component can call what, under which context, and with what inherited permissions. That is where agentic risk starts to resemble NHI sprawl, except the access path can be created dynamically by the workflow itself.
Practical implication: teams should map authorisation boundaries per component and verify that delegated access is explicitly scoped at every handoff.
Build-time remediation and the closed loop to development
The article’s build-time posture model matters because it collapses the gap between finding a weakness and pushing the fix to the people who built the agent. In practice, that means static scanning, component-level findings, and ownership routing all happen before the agent is promoted. The stated MTTR improvement reflects a broader governance point: the earlier the control plane sees the agent, the less likely risk is to become embedded in production behaviour. This is closer to secure-by-design identity governance than to post-incident cleanup.
Practical implication: security findings should flow directly into engineering workflows before deployment gates are cleared.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI agent posture management is becoming an identity governance problem, not just an application security problem. The article shows agents being created across business functions and connected to internal resources long before security teams would traditionally review them. That means the governance question is no longer only whether the agent is secure, but whether the organisation can identify, own, and scope its non-human identities at creation time. Practitioners should treat agent discovery as a lifecycle control, not an after-the-fact scan.
Build-time visibility is the real control gap this article exposes. Reactive security fails because agents can inherit access paths, sub-agent dependencies, and tool connections before anyone has a complete picture of the workflow. The missing control is not awareness in the abstract, but authoritative visibility into how the agent is assembled and what authority each linked component receives. Practitioners should re-evaluate whether their current review process can still catch risk before production.
Delegation chain drift: when an AI agent connects to LLMs, APIs, databases, MCPs, and sub-agents, the security boundary moves faster than most governance processes can track. That is the named concept this article sharpens. It describes the point where the architecture becomes a chain of inherited permissions and the organisation loses clarity on where one identity’s authority ends and another begins. Practitioners should map delegation as a first-class identity object, not an implementation detail.
Continuous posture management is now the baseline for AI agents that behave like operational identities. The article’s model assumes agents can be built by non-R&D teams and used to automate decisions and access internal systems. That creates a governance expectation similar to NHI lifecycle management, but with faster creation, broader ownership, and more frequent change. Practitioners should align agent governance with the same discipline used for service accounts, but extend it to creation-time context and dependency graphs.
Security and development have to share one control plane if agents are going to be governed before launch. The article’s closed-loop model matters because it routes findings back to the teams responsible for the agent while the workflow is still being built. That reduces the chance that access, tool use, or component flaws become standing production risk. Practitioners should judge agent security by whether findings can be acted on inside the build process, not by whether they can be detected later.
From our research:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to the State of Non-Human Identity Security.
- That includes 38% with no or low visibility and 47% with only partial visibility, which shows how quickly delegated access can outpace governance even before AI agents are added.
- For a broader lifecycle lens, the Ultimate Guide to NHIs explains how visibility, ownership, and access scope should be treated as one governance problem.
What this signals
Delegation chain drift: AI agent programmes will increasingly fail at the seams between creation, ownership, and access review, because those seams are where risk is easiest to hide. The governance response is to treat dependency graphs as identity artefacts and to align them with lifecycle review, not just security scanning.
As organisations broaden agent use beyond engineering teams, the control gap will look less like one missing tool and more like a missing operating model. Teams that already struggle to see third-party OAuth access or service-account sprawl will find that agent governance magnifies the same issue, only faster and with more moving parts.
This is where external standards matter. The OWASP NHI Top 10 and the Ultimate Guide to NHIs give teams a language for ownership, scope, and visibility that can be extended into agent programmes without pretending that agent behaviour is static.
For practitioners
- Create a complete AI agent inventory Track every agent, its owner, creator, creation time, usage, and connected components so security has a current map of the estate rather than scattered project lists.
- Map delegation boundaries for each agent Record which LLMs, APIs, databases, sub-agents, MCPs, and applications each agent can reach, then verify where authorisation boundaries are missing or inherited too broadly.
- Route findings into the build workflow Push scan results to the development team responsible for the agent before promotion so remediation happens while the architecture is still changing.
- Prioritise agents with the widest blast radius Rank agents by business criticality, connected systems, and number of delegated components, then fix the most exposed chains first.
Key takeaways
- AI agent posture management is emerging as a governance control for non-human identities that can be created outside traditional security workflows.
- The article’s core evidence is that discovery, ownership, and dependency mapping must happen before deployment, or risk becomes embedded in production behaviour.
- The most effective control is not a late-stage scan but a closed loop that routes findings back into the build process while the agent architecture is still changing.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Covers agent discovery, tool use, and delegation risks in AI workflows. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Agent discovery and ownership are core NHI governance requirements. |
| NIST CSF 2.0 | PR.AC-4 | Delegated access to internal systems requires continuous access control governance. |
Inventory agent identities and enforce explicit ownership, scope, and lifecycle controls.
Key terms
- AI Security Posture Management: AI Security Posture Management is the continuous process of discovering, assessing, and governing AI systems before they reach production. In agent programmes, it extends beyond model risk to ownership, dependencies, tool connections, and delegated access so security can see how the system will behave in live operations.
- Delegation Chain: A delegation chain is the sequence of identities, tools, and services that pass authority from one component to another. For AI agents, it shows where an action originates, what permission is inherited, and where governance can fail if one link is missing or over-scoped.
- Agent Dependency Graph: An agent dependency graph is a structured map of everything an AI agent relies on to function, including models, APIs, databases, sub-agents, and business applications. It gives security teams a way to see both technical connectivity and identity relationships in one view.
- Non-Human Identity: A non-human identity is any credentialed digital entity that acts in a system without being a person, including service accounts, API keys, tokens, certificates, bots, workloads, and AI agents. Governance focuses on ownership, scope, rotation, and offboarding because these identities often outlive the context that created them.
Deepen your knowledge
AI agent discovery, ownership mapping, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance around agentic access and delegated workflow control, it is worth exploring.
This post draws on content published by Lasso Security: Build Secure-By-Design Agents with Lasso. Read the original.
Published by the NHIMG editorial team on 2026-06-04.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org