AI agent security risks are outpacing legacy IAM controls

At a glance

What this is: This is an analysis of the main security risks created by AI agents, with prompt injection, over-privileged access, shadow AI, and non-human identity sprawl identified as the core governance issues.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern software that can act, choose tools, and touch business systems, not just authenticate and pass data around.

By the numbers:

• Gartner projects that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% just a few years earlier.
• 2026, ly half of cybersecurity professionals view agentic AI as the leading attack vector heading into 2026, while only a minority of organizations have implemented AI-specific security controls.

👉 Read SALT's analysis of the top security risks of AI agents

Context

AI agent security is the governance problem created when software can choose actions, call tools, and interact with enterprise systems rather than simply generating output. That changes the identity question from who can log in to what an acting system can reach, modify, or reveal across APIs, SaaS platforms, and internal workflows.

For IAM teams, the challenge is not hypothetical. The article argues that AI agents inherit credentials, permissions, memory, and integrations in ways that resemble non-human identities, but with added runtime decision-making that traditional controls do not fully anticipate. That makes visibility, privilege scope, and lifecycle ownership central to the discussion.

The starting position is typical of many enterprises: adoption is accelerating faster than governance, and security teams are being asked to secure agent behaviour after deployments already exist.

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 do security teams get wrong about Shadow AI?

A: They often treat Shadow AI as an approval problem for software, when it is usually also an identity problem. The hidden risk can be an undocumented token, an over-permissioned service account, or an autonomous agent with unreviewed reach. Inventory the identity layer before you decide the tool is the issue.

Q: Who is accountable when an AI agent exceeds its intended scope?

A: Accountability should follow the delegation chain, not stop at the agent label. The human requester, the policy owner, and the team that granted underlying access all matter, because the agent acts within a permission model someone designed. If the chain is unclear, the governance model is already too weak.

Technical breakdown

Why prompt injection works against AI agents

Prompt injection is an instruction hijack, not a conventional application exploit. The attacker embeds text that steers the agent's reasoning, often inside content the agent is already trusted to read such as email, documents, web pages, or tickets. Because the system is interpreting language rather than enforcing a fixed command set, malicious instructions can redirect tool use, override system prompts, or alter task execution without breaking the surrounding application. Indirect prompt injection is especially difficult because the malicious content arrives through normal retrieval paths. Traditional security tools can inspect files and traffic, but they do not understand whether a sentence is trying to manipulate an AI system.

Practical implication: treat retrieved content as an input control problem and add instruction filtering, content trust rules, and tool-use boundaries.

How over-privileged AI agent identities expand blast radius

AI agents frequently operate through service accounts, OAuth grants, delegated user access, and API keys. Once those permissions are broader than the task requires, the agent becomes an identity with a large blast radius. Unlike a human user, an agent can traverse systems quickly, chain API calls, and act across environments without the normal friction that limits misuse. The article also notes a common pattern: permissions accumulate over time as teams add capabilities, integrations, and exceptions. That turns a narrow deployment into a high-value non-human identity with unclear ownership and excessive reach.

Practical implication: inventory agent identities, reduce delegated scope, and review permissions as if each agent were a privileged workload account.

Why shadow AI and insecure integrations are supply chain problems

Shadow AI appears when employees activate AI features or connect agents without security oversight. The technical risk is not only the agent itself, but the permissions and integrations it inherits from external services, plugins, and MCP servers. Each connection can expose memory, credentials, and sensitive business data to a new trust boundary. In practice, this is a supply chain problem in identity form: a trusted integration becomes the path through which an agent gains unexpected reach. Once persistent OAuth access exists, the control failure is governance drift, not just technical misconfiguration.

Practical implication: subject every AI integration to third-party review, then continuously revalidate permissions, provenance, and access persistence.

NHI Mgmt Group analysis

AI agents should be treated as acting identities, not just software features. The article is right to move the discussion away from model output and toward access, delegation, and runtime action. Once an agent can call APIs and execute workflows, it sits inside the identity plane and must be governed there. That means IAM, PAM, and NHI controls are no longer adjacent to AI security, they are the control surface practitioners must use.

Prompt injection exposes an instruction-trust gap that legacy security tools cannot close. Firewalls, endpoint tools, and DLP can inspect artefacts, but they cannot reliably tell whether a piece of text is trying to steer an agent's actions. The security model assumed content was passive and decisions were external to the system. Practitioners should read this as a boundary failure between text, trust, and tool invocation.

Non-human identity sprawl becomes more dangerous when the identity can decide what to do next. The article describes a familiar NHI pattern, but agentic behaviour increases the blast radius because permissions are not only exercised, they are selected at runtime. That makes ownership, scope, and lifecycle review more fragile. The practical conclusion is that AI agents belong in the same governance inventory as service accounts, with tighter scrutiny where action authority exists.

Shadow AI is a governance problem before it is a detection problem. Organisations are not just discovering unsanctioned tools, they are discovering unsanctioned access paths that persist through SaaS permissions and connected workflows. Once OAuth grants and integrations are embedded, the organisation has to manage an access estate it did not intentionally design. That should push teams toward continuous discovery and approval discipline, not one-time onboarding checks.

OWASP Agentic AI Top 10 gives the category a control vocabulary, but it does not remove the need for identity governance. The article correctly points to emerging frameworks, yet the underlying issue remains who or what is allowed to act. Security leaders should use agentic frameworks to structure threat thinking, then map those risks back to NHI inventory, least privilege, and observability. The discipline is still identity governance, only applied to systems that initiate work.

From our research:

• 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.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows how identity sprawl compounds once control gaps appear.
• For a broader governance baseline, see Ultimate Guide to NHIs , 2025 Outlook and Predictions for the lifecycle patterns that agentic systems now inherit.

What this signals

Agentic adoption will force identity programmes to converge on a single control plane for human, workload, and agent access. The practical issue is not whether AI agents exist in your environment, but whether your current IAM and NHI processes can inventory, approve, and revoke them with the same discipline used for other privileged identities.

Prompt trust, access trust, and integration trust are becoming one governance problem. As more business processes move through AI-driven workflows, the distinction between application security and identity security weakens. Teams that already manage service accounts, OAuth grants, and privileged integrations should expect the same controls to extend into agent oversight.

For practitioners

• Inventory every AI agent and connected integration Build a live register of agents, service accounts, OAuth grants, MCP servers, plugins, and external assistants. Include owner, purpose, permissions, and business system reach so security teams can see where agentic access exists.
• Shrink delegated permissions to task scope Remove broad inherited access from agent identities and align each permission set to a specific business function. Reassess any agent that can read, modify, approve, or provision across multiple systems.
• Add continuous review to AI-connected OAuth access Treat persistent OAuth permissions as a standing governance issue, not a one-time approval. Revalidate whether the integration still needs access, whether the owner still exists, and whether the scope has drifted beyond the original use case.
• Test agents against prompt injection and tool misuse Red-team indirect prompt injection, malicious content retrieval, and unsafe tool calls before production use. Validate that the agent cannot escalate from ordinary content consumption into privileged action without explicit guardrails.
• Govern third-party AI tools as supply chain dependencies Require security review, provenance checks, and post-deployment monitoring for plugins, assistants, and MCP servers. Any integration that can expose credentials or memory should be treated as a dependency with ongoing trust management.

Key takeaways

• AI agents create an identity governance problem because they can act, select tools, and touch enterprise systems, not just generate text.
• The article's strongest signal is that prompt injection, over-privilege, and shadow AI all widen blast radius through non-human identity sprawl.
• Security teams should respond by inventorying agent identities, tightening delegated access, and continuously reviewing every connected integration.

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.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• 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.

What's in the full article

SALT's full article covers the operational detail this post intentionally leaves for the source:

• The article's full breakdown of prompt injection patterns across direct and indirect delivery paths
• Detailed mitigation guidance for least privilege, logging, monitoring, and adversarial testing
• A closer look at OWASP Top 10 for Agentic Applications and how it maps to AI agent risk
• The vendor's explanation of how to build governance around APIs, SaaS platforms, and MCP-connected agents

👉 SALT's full article covers prompt injection, over-privilege, and governance controls in more implementation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.