Notifications
Clear all
Topic starter
01/08/2026 8:53 pm
TL;DR: AI agents are moving into enterprise workflows with API access, delegated permissions, and tool use, creating risks that traditional controls were not built to govern, according to Salt Security and cited industry research. The security problem is no longer model safety alone; it is identity, privilege, and governance for systems that can act.
NHIMG editorial — based on content published by SALT: Top Security Risks of AI Agents
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory every AI agent and connected integration Build a live register of agents, service accounts, OAuth grants, MCP servers, plugins, and external assistants.
- Shrink delegated permissions to task scope Remove broad inherited access from agent identities and align each permission set to a specific business function.
- Add continuous review to AI-connected OAuth access Treat persistent OAuth permissions as a standing governance issue, not a one-time approval.
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
👉 Read SALT's analysis of the top security risks of AI agents →
AI agent security risks: are your identity controls keeping up?
Explore further
01/08/2026 9:02 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AI agent security risks are outpacing legacy IAM controls
