Enterprise AI security is outgrowing governance-only models

At a glance

What this is: This is a practitioner guide to enterprise AI security, arguing that effective control requires discovery, runtime enforcement, and continuous validation across AI apps and agents.

Why it matters: It matters because AI security now overlaps NHI, autonomous behaviour, and human access patterns, so IAM teams need controls that work across all three rather than policy-only oversight.

By the numbers:

• By 2028, Gartner predicts that half of all enterprise cybersecurity incident response efforts will focus on incidents involving custom-built AI applications.
• Through 2027, Gartner predicts that manual AI compliance processes will expose 75% of regulated organizations to fines exceeding 5% of their global revenue.

👉 Read Lasso Security's guide to enterprise AI security across apps and agents

Context

Enterprise AI security is the practice of protecting AI applications, agents, connected data, and user interactions across production environments. The problem is not just policy drift, it is that AI systems can be discovered late, over-permissioned early, and validated too rarely for how fast they change.

The article separates AI security from AI governance, and that distinction matters for IAM practitioners because governance defines accountability while security enforces access, containment, and monitoring. Once agents can call tools, retrieve data, and act inside business workflows, identity controls become part of the security control plane, not a back-office recordkeeping exercise.

Key questions

Q: How should security teams govern AI agents that can call tools and access data?

A: Security teams should govern agents as privileged actors, not as chat interfaces. That means inventorying every connected tool, limiting access to only the data and actions the workflow truly needs, and logging each decision path. If the agent can retrieve, transform, and execute, identity scope and runtime monitoring become mandatory controls.

Q: Why do AI agents complicate zero trust and least privilege?

A: AI agents complicate zero trust because their behaviour can change inside a single session, while least privilege is often designed at provisioning time. A human can be reviewed after the fact, but an agent may have already used the access, delegated it, or altered its own execution path before review begins.

Q: What breaks when AI security relies only on policy and review?

A: Policy-only programmes break because they describe expected behaviour without constraining live execution. Review tells you what should have happened, not whether the agent followed a malicious prompt, retrieved restricted data, or called the wrong tool. Without runtime enforcement, control evidence arrives after the decision has already been made.

Q: What should organisations do first when building enterprise AI security?

A: Start with discovery, because you cannot govern AI systems you cannot see. Build an inventory of models, agents, extensions, and third-party connections, then classify what each one can touch. From there, add access controls, monitoring, and audit trails that match the actual runtime behaviour of the system.

Technical breakdown

Prompt injection and system prompt extraction in enterprise AI

Prompt injection is an attack that hides instructions inside user input, retrieved content, or documents so an AI system follows the attacker instead of the operator. System prompt extraction is the related problem of coaxing the model to reveal its instructions, tool access, or decision logic. In enterprise settings, these attacks matter because the model is not the only target. The real risk is that an agent can be steered into revealing or using access in ways the business never intended. Once the attacker learns the model’s boundaries, they can work around them.

Practical implication: inspect inputs, retrieved content, and model outputs as a single trust boundary, not separate security problems.

Tool calling, agentic hijacking, and multi-turn manipulation

Agentic hijacking happens when an attacker does not need to break the model directly, but instead pushes it across a sequence of interactions until it performs an unsafe action. That can include a payment change, an unauthorized API call, or delegation to a different tool than intended. The key technical point is that the dangerous step may appear legitimate in isolation. Security teams that only inspect one prompt or one output miss the accumulation effect across the conversation, where context is gradually reshaped until the agent acts outside policy.

Practical implication: monitor full interaction sequences and tool-use decisions, not just single-turn prompt filters.

RAG poisoning, retrieval boundaries, and AI supply chain exposure

Retrieval-augmented generation extends model behaviour by pulling in external documents and knowledge bases at runtime, which means the system inherits whatever trust model those sources use. If the retrieval layer does not enforce role-appropriate access, the agent may surface data that the user should never see. The article also points to supply chain risk in models, plugins, and MCP servers, where a dependency update can silently change behaviour without any enterprise-side code change. That makes the AI stack a governed dependency chain, not a standalone application.

Practical implication: apply access policy to retrieval and third-party dependencies with the same rigor as production application data paths.

Threat narrative

Attacker objective: The attacker’s objective is to turn a trusted AI system into an execution path for unauthorized actions or information disclosure.

1. Entry begins when a user, document, or connected dependency introduces malicious instructions into an AI interaction or retrieval path.
2. Credential or capability abuse occurs when the agent is induced to reveal system prompts, expose tool access, or call a sensitive API it was not meant to use.
3. Impact follows when the manipulated agent makes an unauthorized transaction, leaks confidential data, or executes a dangerous workflow inside production.

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

Policy without enforcement is not AI security. The article correctly separates governance from security, but the deeper point is that governance becomes performative when agents, tools, and data paths can change faster than policy review cycles. Security programmes need runtime enforcement, asset visibility, and decision logging because written rules do not stop prompt injection or tool misuse. The practical conclusion is that identity teams should treat AI security as an operational control stack, not a compliance document.

Shadow AI turns identity visibility into a discovery problem, not just an access problem. The article’s emphasis on AI discovery and inventory reflects a broader reality: many organisations do not know how many AI systems are active, connected, or privileged. That makes inventory a prerequisite for any entitlement model, because least privilege cannot be applied to assets that are invisible. Practitioners should read this as a warning that governance gaps start before authorisation, at the moment of untracked deployment.

Runtime enforcement is where enterprise AI security stops being theoretical. The article’s architecture section shows why inline inspection, adaptive guardrails, and continuous validation matter for non-deterministic systems. Static review can describe risk, but it cannot catch an agent that changes behaviour across a session or a dependency that updates out of band. The field implication is clear: enterprise AI security has to move from periodic assessment to continuous control verification.

Identity blast radius is now a first-class AI security metric. Once an agent can reach payment systems, internal databases, or third-party MCP servers, the scope of harm is determined by the identities and privileges attached to that agent. That makes tool inventory, permissions mapping, and dependency analysis central to security design. Practitioners should evaluate every AI deployment by what it can touch, not only by what it says.

AI supply chain risk is increasingly an identity problem. The article shows that models, plugins, and MCP servers can alter behaviour without a traditional code change, which means the trust boundary has moved to the dependency chain. This is not just software supply chain management. It is governance of machine identities, tool trust, and delegated execution. The practical conclusion is that every external connection must be treated as an identity-bearing dependency with lifecycle oversight.

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 NHI Lifecycle Management Guide is the right next stop if you need to turn discovery into provisioning, rotation, and offboarding control.

What this signals

Identity blast radius is becoming the practical measure of AI risk. As agents gain access to tools, data, and delegated workflows, the question is no longer whether AI is allowed, but how far each identity can move before containment fails. Teams that cannot map that blast radius will struggle to enforce least privilege in any meaningful way.

The governance model is also shifting from approval-centric to evidence-centric. Continuous validation, audit trails, and runtime inspection are now the signals that matter because static reviews cannot keep pace with models, plugins, and agents that change in production. The NHI Lifecycle Management Guide is a useful baseline for teams translating this into operational identity control.

Security leaders should expect AI inventory and entitlement review to converge with existing NHI controls. The same visibility problems that affect service accounts now affect copilots, agents, and third-party dependencies, which means identity programmes need a broader asset model and a tighter control loop. The gap is not only technical, it is organisational.

For practitioners

• Inventory every AI application and agent Create a complete register of sanctioned tools, developer-built agents, low-code systems, and shadow AI connected to your environment. Map owners, data sources, and business functions so the discovery layer becomes the entry point for control.
• Map tool access and retrieval boundaries Document which APIs, knowledge bases, and MCP servers each agent can reach, then compare that map to the permissions the underlying identity actually holds. Apply the NHI Lifecycle Management Guide to review provisioning, rotation, and offboarding for connected service identities.
• Enforce runtime controls on prompts and actions Inspect prompts, retrieved content, and tool calls in production, then block or quarantine behaviour that exceeds intended scope. Pair inline controls with continuous red teaming so policy changes are tested against live behaviour, not assumed from design.
• Tie AI governance to audit-ready evidence Record model inventories, access decisions, retrieval events, and tool-call histories in a form that supports incident response and compliance review. Use the OWASP Agentic AI Top 10 to prioritise threat modelling for prompt injection, tool abuse, and agent hijacking.

Key takeaways

• Enterprise AI security fails when governance exists without runtime enforcement, because policy does not stop prompt injection or unsafe tool use.
• The scale problem is already visible: many organisations are running more AI than their security teams can actually see or control.
• Discovery, access mapping, and continuous validation are the controls that turn AI security from a paper process into an operational discipline.

Key terms

• Enterprise AI security: The discipline of protecting AI systems in production, including models, agents, connected data, and tool integrations. It combines identity control, runtime enforcement, monitoring, and response so the system cannot be trusted merely because it was approved once.
• Prompt injection: A technique that embeds malicious instructions into user input, retrieved content, or documents so an AI system follows the attacker’s intent. In enterprise settings, it is dangerous because it can redirect tool use, data exposure, or execution without changing the model itself.
• Agentic hijacking: A failure mode where an AI agent is gradually steered across a conversation or workflow until it performs an action outside its intended purpose. The risk is not a single bad prompt, but the accumulation of context that alters the agent’s behaviour at runtime.
• Shadow AI: AI applications, agents, or integrations that are present in the environment but not properly inventoried or governed. Shadow AI creates identity risk because security teams cannot enforce access, lifecycle, or audit controls on assets they do not know exist.

Deepen your knowledge

Enterprise AI security, agentic access control, and runtime enforcement are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are translating AI security theory into a governed identity programme, it is worth exploring.

This post draws on content published by Lasso Security: Enterprise AI Security: Managing Risk Across AI Apps & Agents. Read the original.