AI security gaps are slowing adoption and raising breach costs

At a glance

What this is: This analysis argues that AI security has shifted from a technical safeguard to a prerequisite for production adoption because autonomous behaviour, data access, and accountability gaps now drive both risk and deployment delays.

Why it matters: For IAM, PAM, and NHI practitioners, the lesson is that AI agents cannot be governed as ordinary software accounts, because delegated authority, runtime actions, and auditability now sit at the centre of adoption decisions.

By the numbers:

• 37% of enterprises cite security and compliance as the number one reason AI initiatives slow down or fail to reach production.
• More than 80% of enterprises report that AI agents access sensitive data, often daily.

👉 Read LEVO's full analysis of AI security as the blocker to production adoption

Context

AI security is the discipline of governing AI systems so they behave safely, predictably, and within policy while handling data and tools at runtime. The primary gap is that traditional perimeter controls and static reviews assume deterministic systems, while AI agents make decisions dynamically and can invoke APIs, retrieve context, and act with delegated authority.

That matters because the article ties adoption to trust, not just capability. Where AI systems have genuine access to sensitive data or operational tools, identity and access governance becomes part of AI security rather than a separate control plane, and that is already typical in enterprises trying to move beyond proof of concept.

Key questions

Q: What breaks when AI agents are given access without identity governance?

A: What breaks is accountability. The organisation may see actions, logs, and alerts, but it cannot reliably tie them to a governed identity with clear scope and revocation. That creates uncontrolled blast radius, especially when agents can reach sensitive systems through shared tokens, delegated service accounts, or broad API access.

Q: Why do AI agents that exceed their intended scope create security and compliance risk?

A: AI agents create risk when they can read, move, or disclose data without the same controls applied to human users. Once an agent accesses unauthorised systems or sensitive information, it can expose credentials, spread data to new locations, and weaken auditability. That increases breach impact, complicates investigations, and makes it harder to prove compliance with privacy and security obligations.

Q: How can organisations tell whether their AI security model is actually working?

A: They should test whether the control stack can explain who acted, what data was touched, and what purpose the action served. If those three signals cannot be correlated in one incident view, the model is likely monitoring access without governing behaviour. That is a visibility gap, not a complete AI security posture.

Q: Should organisations prioritise AI agent governance before expanding autonomous workflows?

A: Yes. The article shows that AI creates both faster discovery and deeper trust exposure, so scaling autonomy without governance multiplies risk. Teams should establish ownership, visibility, and behavioural control first, then expand only where they can explain the agent’s access, decisions, and downstream effects.

Technical breakdown

Runtime AI security versus static application security

Traditional application security assumes known execution paths and testable code states. AI systems do not behave that way. Agents receive high-level goals, retrieve context, chain tool calls, and make decisions at runtime, so the most important control points emerge only while the system is operating. Static reviews can validate code, but they cannot fully predict tool misuse, prompt manipulation, or data leakage when the runtime decides what happens next. That is why AI security needs continuous inspection of prompts, outputs, tool calls, and policy decisions, not just pre-deployment approval.

Practical implication: Security teams need runtime visibility and enforcement, not only pre-release testing or periodic review.

Agent identity and delegated authority

When AI agents act on behalf of users or systems, they become non-human actors with their own accountability requirements. In practice, that means an agent identity must be distinguishable from the human who initiated the task, and each action should be tied to scope, policy, and audit trail. Without this, organisations cannot answer who acted, under what authority, or whether the behaviour stayed within intended boundaries. This is where NHI governance intersects directly with AI security: delegated authority without first-class identity produces an audit gap, not just a technical one.

Practical implication: Treat agents as governed identities with scoped permissions, ownership, and immutable logs.

Prompt injection, data flow, and tool misuse

Prompt injection succeeds because AI systems blend external input, system instructions, and retrieved context inside the same decision loop. That makes untrusted content capable of steering behaviour unless the system separates instruction sources and validates outputs before action. The same runtime design also creates data-flow risk: sensitive data can move from prompts to retrieval layers to tools without the clear checkpoints that traditional DLP or IAM designs expect. Tool misuse follows from the same weakness when agents can call APIs or MCP-connected services without fine-grained authorisation.

Practical implication: Validate inputs, segment instruction sources, and authorise every tool call as a discrete action.

Threat narrative

Attacker objective: The objective is to hijack agent behaviour so the attacker can use trusted AI workflows as a proxy into data, systems, or decisions.

1. Entry occurs when an attacker or manipulated input reaches the agent through prompt injection, untrusted retrieval content, or weak tool boundaries.
2. Escalation follows when the agent accepts the malicious instruction and uses delegated authority to access sensitive data or invoke connected tools beyond intended scope.
3. Impact is realised through data leakage, unauthorised actions, or corrupted business decisions that persist until runtime monitoring detects the misuse.

NHI Mgmt Group analysis

AI governance debt is now an enterprise blocker: organisations that treat AI security as a later-stage control accumulate operational debt that directly slows production adoption. The article shows that security and compliance are no longer afterthoughts but gating criteria for deployment, especially where agents can access internal data and tools. That means AI programmes now fail or scale based on governance maturity as much as model capability. The practitioner conclusion is straightforward: if governance cannot prove control, AI will stay trapped in pilot status.

Agent identity is the missing control plane: AI systems that act autonomously create a non-human identity problem, not just a software security problem. A runtime action without first-class attribution leaves teams unable to map authority, scope, or responsibility, which weakens auditability and board confidence. This is where identity governance, PAM thinking, and AI security converge. The practitioner conclusion is to govern agents as identities with lifecycle, ownership, and revocation, not as anonymous automation.

Runtime visibility is the named concept that matters most here: the article’s core security failure mode is the absence of runtime visibility into how AI systems reason, access data, and invoke tools. Static review cannot expose midstream policy violations or agent misuse because the decisive behaviour happens during execution. That makes runtime visibility the control that turns AI from an opaque risk into something governable. The practitioner conclusion is to prioritise live monitoring before expanding autonomous scope.

Security-first AI adoption is becoming a market filter: the article makes clear that organisations with stronger control surfaces will move faster because they can approve AI use with less manual oversight and less compliance friction. In regulated sectors, that matters more than experimentation volume. The market implication is that secure AI enablement is now part of competitive strategy. The practitioner conclusion is to align security architecture with rollout speed, not just with incident prevention.

Traditional perimeter thinking does not match agentic behaviour: AI systems move trust decisions inside the runtime, where firewall, gateway, and human-centric IAM assumptions are weakest. That shift is especially relevant where MCP-connected tools, internal APIs, and delegated credentials intersect. The practitioner conclusion is to re-evaluate where authorisation occurs and ensure policy enforcement follows the action, not just the request.

What this signals

Runtime visibility will become the differentiator in AI security programmes: organisations that can observe agent behaviour as it happens will reduce manual review and shorten the path from pilot to production. That matters because static governance artefacts do not prove safe operation in live workflows, especially where agents call tools and handle sensitive data. The control question is shifting from whether an AI model is accurate to whether the runtime is governable.

AI governance debt will show up as IAM debt: once agents begin acting on behalf of users and services, missing attribution, weak revocation, and over-broad tool access become identity problems as much as AI problems. The practical signal is whether your IAM and PAM processes can explain delegated authority without special exceptions. Where they cannot, security teams should expect stalled deployments and heavier compliance friction.

More than 1 in 5 non-human identities are still judged insufficiently secured, which should sharpen agent governance priorities. That figure is a warning that the baseline for machine identity control remains uneven even before AI agents add autonomous action. For readers building AI programmes, the next step is to align agent identity controls with established identity governance rather than inventing a parallel process.

For practitioners

• Define first-class agent identities Assign each AI agent a unique identity, owner, and policy scope so actions can be attributed, audited, and revoked like any other privileged actor.
• Enforce least privilege on tool access Limit every agent to the minimum APIs, datasets, and MCP-connected services required for the task, and remove broad default permissions before production rollout.
• Instrument runtime monitoring and alerting Monitor prompts, tool calls, data movement, and policy decisions in production so abnormal behaviour can be detected while the session is active.
• Separate trusted instructions from untrusted input Treat user prompts, retrieved documents, and external content as untrusted by default, then validate outputs before the agent can act on them.
• Build revocation and rollback paths Create a fast way to disable agent access, revoke credentials, and stop tool execution when behaviour drifts from policy or a control gap is found.

Key takeaways

• AI security is now a production gate, not an optional hardening layer, because governance gaps slow adoption and increase business risk.
• Runtime behaviour, delegated authority, and attribution are the controls that matter most when AI agents can access data and tools.
• Identity governance for agents is becoming a prerequisite for scale, auditability, and credible compliance evidence.

Key terms

• Runtime ai security: Runtime AI security is the set of controls applied while a model is actively handling prompts and responses. It focuses on what the system sees, says, and does in production, rather than relying only on pre-deployment testing or static policy documentation.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.
• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.

What's in the full article

LEVO's full analysis covers the operational detail this post intentionally leaves for the source:

• Specific runtime security patterns for prompt injection, data leakage, and agent misuse in production environments
• Operational guidance on how AI security and compliance controls affect pilot-to-production decisions
• Examples of where autonomous agents access sensitive data and how that changes governance expectations
• The source's broader discussion of why security guardrails determine whether AI delivers ROI

👉 LEVO's full post expands on runtime risk, governance gaps, and the business impact of insecure AI.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need a practical framework for governing non-human actors alongside broader security programmes.