TL;DR: Enterprise AI governance now has to cover prompts, outputs, tool calls, access permissions, and third-party integrations because shadow AI, prompt injection, and autonomous agents create runtime risk that policy documents alone cannot control, according to Lasso Security. The decisive shift is from documenting AI usage to enforcing traceable controls at the interaction layer.
At a glance
What this is: This is an analysis of enterprise AI governance and its key finding is that runtime control, not policy alone, is now the governance boundary.
Why it matters: It matters because IAM, NHI, and human access programmes all break down when AI tools, agents, and data flows outpace visibility, approval, and auditability.
👉 Read Lasso Security's analysis of enterprise AI governance and runtime controls
Context
Enterprise AI governance is the operational layer that controls how AI tools, models, and agents are used, what data they can see, and which actions they can take. The core problem is that traditional IT governance assumes systems are deterministic and centrally managed, while AI usage now spreads across teams, tools, and third-party integrations faster than security can inventory it.
For IAM teams, this is no longer just a model-risk issue. It is a visibility, access, and accountability problem that affects human users, NHI-backed integrations, and AI agents that can trigger downstream actions. Once prompts, outputs, and tool calls become business pathways, governance has to move from policy statements to enforceable runtime controls.
Key questions
Q: How should security teams govern AI tools that employees adopt outside approval paths?
A: Start with continuous discovery, then bind each tool to the identity using it, the data it can reach, and the controls applied at runtime. Approval lists alone do not stop shadow AI because users can route around them. Governance only works when inventory, access policy, and monitoring are tied together.
Q: Why do AI agents create governance problems for IAM teams?
A: AI agents can cross application boundaries, invoke tools, and influence business workflows in ways that traditional access reviews do not capture well. IAM teams must therefore govern the identity behind the agent, the permissions it receives, and the evidence trail showing what actions it took. Without that, accountability becomes fragmented.
Q: What do organisations get wrong about prompt and output controls?
A: They often treat prompt hygiene as a training issue instead of a runtime control issue. The better model is to inspect prompts and outputs inline, classify sensitive content, and block or redact data before it leaves policy boundaries. That shifts governance from user behaviour advice to enforceable control.
Q: Who is accountable when third-party AI systems process sensitive data?
A: The enterprise remains accountable, even when the model or agent is provided by a third party. That means contracts, logging, access restrictions, and audit evidence must show how the system was governed in practice. Delegated processing does not delegate responsibility.
Technical breakdown
Runtime governance for prompts, outputs, and tool calls
Enterprise AI governance becomes operational when controls sit at the interaction layer, not only in policy documents. That means inspecting prompts before they reach a model, evaluating outputs before they are released, and governing tool calls that connect the model to APIs, databases, and workflows. The architectural point is simple: AI risk is created in motion, where data, identity, and execution converge. Without runtime enforcement, security teams can know a tool exists without knowing what it did, what it accessed, or whether it crossed policy boundaries.
Practical implication: put policy enforcement where AI actions occur, not only where models are approved.
Shadow AI discovery and identity-aware access controls
Shadow AI emerges when employees, teams, or developers adopt copilots, browser tools, or agents without central approval or inventory. Discovery is therefore an identity problem as much as a tooling problem, because the organisation must know who is using which AI system, from where, and with what entitlements. Identity-aware access controls extend least privilege to AI interactions by binding use to role, session context, and data sensitivity. That matters because broad AI permissions can expose regulated data, create invisible integrations, and expand the blast radius of a single account or agent.
Practical implication: continuously inventory AI usage and restrict high-risk interactions by identity and context.
Auditability, compliance, and third-party AI oversight
Audit-ready AI governance depends on immutable logs, traceable policy decisions, and a current view of which AI systems are in production. This is especially important when third-party models, copilots, plugins, or agents are embedded into business workflows, because accountability remains with the enterprise even when processing happens elsewhere. The governance model therefore has to show who used the system, what data it touched, which controls applied, and what was blocked or remediated. That is the difference between procedural approval and provable control.
Practical implication: maintain evidence trails that tie AI activity to users, data classes, and enforcement decisions.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime AI governance is now an access-control problem, not a policy problem. The article correctly shows that prompts, outputs, and tool invocation are where AI risk becomes real. That makes the control plane the decisive layer, because static policy cannot prevent a model from exposing data or calling a tool at runtime. For practitioners, the programme question is whether access decisions can be enforced at the moment of interaction.
Shadow AI is an identity visibility failure before it is an AI risk. When employees adopt copilots and agents outside approval paths, security loses the ability to answer a basic governance question: who is interacting with which AI system under what controls. That breaks inventory, recertification, and accountability across IAM and NHI programmes alike. The implication is that discovery and entitlement mapping must be treated as a shared control surface, not separate workstreams.
Enterprise AI governance must extend least privilege into machine-to-machine execution paths. The article’s third-party AI and agent examples show that broad permissions become dangerous when AI systems can invoke APIs and influence business processes. In NHI terms, this is a governance gap around delegated execution, because the enterprise is trusting an identity that can act across systems with limited human visibility. Practitioners should treat agent permissions as policy-bound privileges with full audit evidence.
AI governance becomes credible only when it is audit-grade at runtime. Regulators do not need more policy language, they need proof of control. The article points toward the right operating model, one that can show what data was used, which actions were blocked, and how exceptions were handled. That makes runtime traceability a board-level governance requirement, not an implementation detail.
From our research:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
- The governance lesson carries forward into AI programmes, as shown in OWASP Agentic Applications Top 10, where runtime control and delegated action risks converge.
What this signals
Runtime control is becoming the differentiator between visible AI use and governable AI use. Enterprises that already struggle to inventory non-human identities will find AI adoption compounds the same problem through copilots, agents, and embedded model access. The practical signal is that discovery, monitoring, and recertification should be unified across human and machine identities rather than run as separate programmes.
Shadow AI expands the identity perimeter faster than policy teams can respond. With 72% of organisations already experiencing or suspecting a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities, the governance gap is no longer theoretical. Teams should expect more unmanaged AI access paths to appear in business units, developer workflows, and third-party integrations.
Auditability will increasingly decide whether AI governance is defensible. Security teams should prepare for evidence requests that ask not only which AI systems exist, but who used them, what data they accessed, and which controls fired. That pushes enterprise AI oversight closer to identity governance, data control, and security monitoring than to policy management alone.
For practitioners
- Build continuous AI discovery into identity inventory Inventory sanctioned and shadow AI tools across endpoints, browsers, and developer workflows, then map each system to the user or service identity that can reach it. This closes the visibility gap before you try to enforce policy.
- Extend least privilege to prompts, outputs, and tool invocation Apply role, session, and data-sensitivity controls to AI interactions so high-risk models, datasets, and actions are constrained by context rather than by blanket approval.
- Log policy decisions as audit evidence Capture which prompts were blocked, which outputs were redacted, which tool calls were denied, and which identities were involved so audit and incident review can reconstruct decisions.
- Review third-party AI integrations as delegated access Treat copilots, plugins, RAG pipelines, and agents as externally mediated access paths that require approval, monitoring, and periodic recertification.
Key takeaways
- Enterprise AI governance fails when controls exist only on paper and not at runtime.
- Shadow AI and third-party integrations turn visibility into the first governance requirement.
- Audit-grade logging, identity-aware access, and inline policy enforcement are now baseline expectations.
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 prompt injection, tool use, and autonomous agent governance risks. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Secret and identity control issues arise when AI systems get broad delegated access. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access management must extend to AI interactions and delegated access. |
Treat AI-connected service identities as NHIs and review entitlements and rotations regularly.
Key terms
- Enterprise AI governance: The operational discipline for controlling how AI systems are used inside an organisation. It combines access control, monitoring, audit logging, and policy enforcement so prompts, outputs, tool calls, and data flows can be governed at runtime rather than only by policy documents.
- Shadow AI: AI tools, copilots, or agents used without formal approval, inventory, or oversight. In practice, shadow AI expands the security perimeter because teams may move sensitive data into unmanaged systems that bypass standard review, logging, and access governance.
- Runtime enforcement: The act of applying policy while an AI system is actively processing data or taking actions. It matters because many AI risks only emerge during execution, when prompts, retrieved context, outputs, and tool calls can be inspected, blocked, redacted, or constrained.
- Identity-aware access control: Access control that evaluates who is making the request, the session context, and the sensitivity of the data or action before allowing AI interaction. For AI programmes, it extends least privilege into model usage, tool invocation, and delegated system access.
Deepen your knowledge
Enterprise AI governance, shadow AI discovery, and runtime access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for AI tools and agents from the same access model you use for NHI, it is worth exploring.
This post draws on content published by Lasso Security: Enterprise AI Governance for Modern Enterprises Seeking Visibility, Control & Compliance. Read the original.
Published by the NHIMG editorial team on 2026-04-20.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org