TL;DR: Agentic AI shifts risk from model output to machine-speed action, because agents can call APIs, inherit credentials, and execute workflows across enterprise systems, according to Salt. That breaks governance models built for human-paced review and makes identity, privilege, and API discovery the decisive controls.
NHIMG editorial — based on content published by Salt: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
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 autonomous agents create a bigger governance problem than chat-based AI assistants?
A: Chat-based assistants usually begin with a visible human prompt, so the initiation point is easier to govern and audit.
Q: What breaks when organisations rely on periodic access reviews for AI systems?
A: Periodic access reviews break when the identity scope changes between review cycles.
Practitioner guidance
- Map every agent to a discrete identity record Create an inventory of agent identities, including linked service accounts, API keys, tokens, and certificates.
- Enforce runtime policy at the API layer Log and authorise every API call made by an agent, including tool discovery and chained workflows.
- Constrain initial agent authority with task-scoped permissions Start new agents with the smallest workable permission set and expand access only after behaviour is validated in production-like testing.
What's in the full article
Salt's full analysis covers the operational detail this post intentionally leaves for the source:
- Concrete examples of how agentic AI expands the attack surface through APIs, service accounts, and delegated workflows
- Salt's framing of runtime governance controls and visibility gaps that were summarised here at a strategic level
- Implementation context for organisations building an agentic AI security posture across access control and monitoring
- The source article's full discussion of regulatory implications for autonomous systems and enterprise compliance
👉 Read Salt's analysis of agentic AI governance, API risk, and autonomous systems →
Agentic AI governance and API blind spots: what are teams missing?
Explore further
Agentic AI governance is now an identity discipline, not a model discipline. The article is right to shift attention from what the model says to what the agent can do. Once an autonomous system can authenticate, call tools, and execute workflows, IAM and NHI governance become the only durable control layer. The practical conclusion is that agent identity, permissions, and runtime action boundaries must be managed together.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How should organisations respond when an AI agent inherits access across multiple systems?
A: They should re-evaluate whether the inheritance model is actually necessary and then break the access into smaller, task-scoped permissions. If the agent can reach documents, tickets, chat, and databases from one identity, the blast radius is too large for effective governance. Cross-system reach should be treated as a privileged design choice, not a default.
👉 Read our full editorial: Agentic AI governance fails when API visibility lags behind agents