By NHI Mgmt Group Editorial TeamDomain: AI SecuritySource: AktoPublished November 25, 2025

TL;DR: AI systems are now connected to MCP, plugins, cloud platforms and multi-agent ecosystems, which expands the attack surface beyond conventional software and makes prompt injection, shadow AI, data poisoning and supply chain abuse harder to contain, according to Akto. Static security models are no longer enough when tools can act, retrieve and expose data at runtime.


At a glance

What this is: This is an analysis of the top AI security risks in 2026, with prompt injection, shadow AI, data poisoning and third-party integration risk identified as the core failure modes.

Why it matters: It matters to IAM practitioners because AI assistants and agents now depend on permissions, tool access and connected data sources, which turns access governance into a live control problem across NHI and human identity programmes.

By the numbers:

  • 78% of CISOs saying AI-driven threats are already having major impact on their organizations.
  • AI agents have already performed actions beyond their intended scope in 80% of organisations, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
  • 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Akto's analysis of the top AI security risks and mitigation strategies


Context

AI security risks are no longer limited to model accuracy or bad outputs. The real governance gap is that modern AI systems can call tools, query databases, use MCP connections and act inside enterprise workflows, which means access control now shapes security outcomes as much as model quality does. For IAM and PAM teams, that creates a direct identity security question: who or what is allowed to act, retrieve, delegate and persist in the AI stack?

The article frames AI security as a lifecycle problem spanning training, deployment, inference and runtime monitoring. That is directionally correct, but the operational challenge for practitioners is narrower and harder: ensuring AI agents, copilots and connected services only have the minimum access required, with visibility into how those permissions are actually used. In identity terms, this is a governance problem around NHI sprawl, delegated access and uncontrolled tool use.


Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: What breaks when organisations ban shadow AI instead of governing it?

A: Bans often push AI use into personal accounts, unmanaged devices, and hidden workflows, which removes visibility from security and makes data exposure harder to detect. The control failure is not usage itself, but concealment. A better model is to approve fast, workable alternatives and enforce policy on identity, data handling, and logging.

Q: How should security teams reduce prompt injection risk in AI agents?

A: Security teams should reduce prompt injection risk by constraining what enters the context window, limiting tool permissions, and separating untrusted retrieval content from privileged instructions. The practical goal is not perfect detection. It is to ensure that a successful injection cannot trigger wide data access, uncontrolled writes, or irreversible actions through a delegated identity.


Technical breakdown

Why MCP-connected AI systems expand the attack surface

Model Context Protocol connects AI systems to tools and data sources, which makes the security model materially different from a standalone model. Once an LLM can call external services, it is no longer just producing text. It is operating inside a trust chain that includes authentication, authorization, data handling and session context. That creates new failure modes such as tool abuse, context poisoning and unauthorized retrieval. The risk is not only in the model output, but in the actions the model can trigger through connected services.

Practical implication: inventory every MCP integration, map its permissions and treat each connector as an access path that needs explicit review.

Prompt injection and runtime manipulation in agentic AI

Prompt injection works because many AI systems still treat instructions and untrusted content as separable when, in practice, they are often mixed in the same runtime context. Attackers embed instructions in web pages, documents or messages so the agent overrides its intended behaviour, leaks data or misuses tools. In agentic systems, this becomes more dangerous because the system can take action, not just generate output. The core architectural issue is that the model cannot reliably infer which instruction source is authoritative without external controls.

Practical implication: enforce runtime guardrails, content validation and tool restrictions before an agent can act on external input.

Shadow AI and the identity gap in AI governance

Shadow AI is not only an application inventory problem. It is an identity and access problem because unmanaged AI usage often brings unmanaged credentials, unsanctioned tokens and unreviewed data flows. When employees use public AI tools or autonomous agents without oversight, the organisation loses visibility into where sensitive data goes and which permissions are effectively exposed. That creates a governance gap similar to unmanaged service accounts, except the activity can be faster, broader and harder to detect.

Practical implication: extend discovery, policy and access review processes to AI tools, agents and the secrets they use.


Threat narrative

Attacker objective: The attacker aims to hijack AI-driven workflows so the system leaks data, abuses connected tools or performs actions the business did not authorise.

  1. Entry begins when attackers exploit prompt injection, shadow AI usage or exposed third-party integrations to influence an AI system's runtime context. Escalation follows when the agent trusts malicious instructions, accesses connected tools or retrieves data beyond the intended scope. Impact occurs when the compromised AI system leaks sensitive information, executes unauthorised actions or amplifies downstream business and compliance risk.

NHI Mgmt Group analysis

AI security has become an access governance problem, not just a model safety problem. Once AI systems connect to databases, cloud services and plugins, the decisive question is what they can reach and under what conditions. That makes IAM, PAM and NHI controls central to AI risk management, especially where agents can act autonomously or on behalf of a user. Practitioners should treat AI permissions as live entitlements, not static configuration.

Shadow AI is the named concept security teams need to operationalise. Unapproved AI tools are often introduced through normal productivity behaviour, which means the control gap begins with discovery and visibility. The governance failure is not simply that users experiment with new tools, but that organisations cannot reliably see which identities, tokens and datasets those tools touch. That is why AI inventory, approval workflows and access monitoring now sit on the same risk plane as classic NHI sprawl.

Prompt injection reveals the trust boundary failure inside agentic systems. The problem is not that all external content is malicious, but that the runtime cannot always distinguish instruction from input without help. That makes AI guardrails, content filtering and tool scoping necessary controls, not optional hardening. For identity programmes, the lesson is clear: an AI agent with broad delegated access can convert a single malicious instruction into a wide blast radius.

Least privilege must extend to AI agents the same way it does to service accounts. The article’s runtime protection theme is directionally right, but the deeper issue is entitlement scope. If an agent can access mail, docs, APIs and operational systems without task boundaries, then compromise becomes a business process issue, not just a security event. Practitioners should align AI governance with NHI lifecycle and privileged access discipline.

The market is moving toward continuous governance because one-time review cannot keep up with probabilistic systems. AI security is now shifting from point-in-time assessment to runtime monitoring, policy enforcement and behavioural controls. That trend validates the need for cross-functional oversight across security, compliance, legal and IT, because the risks are no longer confined to the model team. Teams should expect AI governance to look increasingly like identity governance with more dynamic execution.

What this signals

Shadow AI will keep turning into an identity problem before it becomes a governance headline. If organisations cannot see which AI tools are using which credentials, policy enforcement will remain partial and reactive. The better programme signal is not more generic AI awareness, but tighter linkage between AI discovery, access review and secrets governance. The right benchmark is whether every agent and tool has a named owner and a revocation path.

Runtime control will become the practical dividing line between AI experimentation and AI operations. Static review cannot keep pace with systems that change context and choose actions at runtime. Teams should expect pressure to formalise guardrails, logging and behavioural controls around any AI system that can touch enterprise data or operational workflows. That is especially true where AI is effectively acting as a non-human identity.

Agentic systems will push identity teams to collapse the gap between NHI and application governance. A workflow that uses tokens, plugins and delegated API access is already an access-control surface, even if the business calls it an AI feature. Programmes that separate IAM, PAM and AI security too rigidly will miss the combined blast radius. The strongest response is a shared control model that covers identity, data and runtime decisions.


For practitioners

  • Discover all AI systems and connected identities Build a live inventory of AI models, agents, plugins, MCP connections, service accounts and tokens. Include unsanctioned tools used by business teams so shadow AI is visible before a data event forces discovery.
  • Scope every AI agent to task-bound access Apply least privilege to agents, copilots and automated workflows, with separate entitlements for retrieval, write actions and tool execution. Review whether any agent can reach data or systems that exceed its business purpose.
  • Enforce runtime guardrails on prompts and tools Filter untrusted content, constrain tool invocation and block unsafe actions at runtime rather than relying only on pre-deployment testing. Use policy checks that can stop an agent before it completes a delegated action.
  • Tie AI governance to NHI controls Treat agent tokens, API keys and service credentials as governed NHIs with lifecycle ownership, logging and revocation paths. Where AI systems use delegated access, require the same offboarding and review discipline as for other privileged identities.
  • Test for prompt injection and data leakage continuously Run adversarial testing against prompts, documents, web inputs and third-party integrations on an ongoing basis. Include scenarios where the agent is induced to reveal secrets, access unauthorised systems or alter workflow outputs.

Key takeaways

  • AI security risk in 2026 is driven by connected systems, not just model errors, because agents now operate across tools, data and cloud services.
  • The strongest evidence in the field shows agent overreach is already common, which makes visibility and task-scoped access the immediate control priorities.
  • Security teams should govern AI agents as identities with boundaries, logging and runtime controls, or they will inherit a much wider blast radius than they can review manually.

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 MITRE ATT&CK address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10Prompt injection and agent misuse are central risks in the article.
NIST AI RMFMANAGEThe article is about ongoing AI risk controls and runtime protection.
NIST CSF 2.0PR.AC-4Least-privilege access to AI tools maps directly to access control governance.
NIST SP 800-53 Rev 5AC-6Least privilege is the primary control implication of over-privileged AI agents.
MITRE ATT&CKTA0006 , Credential Access; TA0008 , Lateral MovementThe article describes credential leakage and tool-driven movement across systems.

Map AI misuse scenarios to credential access and lateral movement to prioritise monitoring and containment.


Key terms

  • 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.
  • Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
  • Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
  • Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

What's in the full article

Akto's full blog covers the operational detail this post intentionally leaves for the source:

  • Step-by-step mitigation guidance for prompt injection, shadow AI and data poisoning across live AI environments
  • Practical runtime protection examples for filtering prompts, constraining tool use and detecting unsafe agent behaviour
  • A fuller breakdown of AI security posture management for discovery, monitoring and policy enforcement
  • Source examples and mitigation summaries for AI systems connected to MCP, plugins and external tools

👉 Akto's full blog expands the threat examples, runtime controls and response guidance for AI security teams.

Deepen your knowledge

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 to connect identity controls to modern automation and agentic AI risk.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org