Notifications
Clear all
Topic starter
02/08/2026 12:03 pm
TL;DR: AI agents operating through APIs can coordinate, fetch untrusted skills, and chain actions without human visibility, creating a governance gap across the API fabric, according to Salt Security. The control problem is no longer just API exposure, but whether identity, intent, and runtime authorisation can keep pace with agentic behaviour.
NHIMG editorial — based on content published by Salt: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- 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%).
Questions worth separating out
Q: How should security teams govern AI agents that call APIs instead of using a UI?
A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login.
Q: Why does human-in-the-loop matter for identity and access management?
A: IAM decisions affect who can reach sensitive systems, so errors have direct security consequences.
Q: What breaks when agents can fetch untrusted skills or code automatically?
A: The trust boundary breaks between instruction intake and privileged execution.
Practitioner guidance
- Discover every agent-to-API path Build an inventory of the APIs, microservices, and SaaS endpoints each AI agent can reach, including dynamically created or shadow paths exposed through orchestration layers and MCP-style integrations.
- Separate instruction intake from tool execution Treat externally sourced skills, prompts, and executable logic as untrusted inputs, and isolate them from the privileges used for production actions or secret access.
- Bind each agent to least-privilege delegated access Issue narrow, auditable permissions for every agent identity, then revoke anything that is not tied to a specific service owner, workflow, or business purpose.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- The article walks through Moltbook's agent-only interaction model and why API-only behaviour changes the threat surface.
- It explains the lethal trifecta of agent risk and ties it to data access, tool execution, and untrusted inputs.
- It describes practical governance gaps around visibility, contextual policy, and behavioural monitoring that this analysis only summarises.
- It frames the API fabric as a control plane for agentic AI and shows how the vendor positions runtime protection.
👉 Read Salt's analysis of agentic AI risk in the API fabric →
AI agent action layers and API fabric risk: are controls keeping up?
Explore further
02/08/2026 1:09 pm
Agentic AI governance is now an API identity problem, not just an AI policy problem. Once agents can call tools, fetch skills, and trigger workflows, the security boundary shifts to delegated machine identities and the permissions attached to them. That means IAM, PAM, and NHI governance need to cover the action layer, not just login events. Practitioners should treat every agent as a governed identity with measurable scope.
A question worth separating out:
Q: Who is accountable when an AI agent uses delegated access incorrectly?
A: Accountability should follow the delegated authority chain, not stop at the agent label. The relevant owners are the teams responsible for the human identity, the service identity, the workflow, and the policy that allowed the action path. If those responsibilities are not explicit, incident review will be incomplete and remediation will focus on the wrong layer.
👉 Read our full editorial: AI agent action layers expose the API fabric security gap
