AI agent action layers expose the API fabric security gap

At a glance

What this is: This analysis argues that AI agent activity is shifting risk into the API fabric, where unmonitored machine-to-machine calls, untrusted skills, and hidden autonomy can drive exfiltration and fraud.

Why it matters: For IAM and security teams, the issue is that agent identities, delegated access, and runtime intent checks now need to be governed together across NHI and broader AI security programmes.

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%).
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Salt's analysis of agentic AI risk in the API fabric

Context

AI agent identity risk is increasingly concentrated in the API fabric, the layer of machine-to-machine connections that lets software call tools, services, and data sources. When agents can fetch code, invoke APIs, and make decisions at runtime, traditional perimeter thinking breaks down because the control point is no longer a user session but a chain of delegated actions.

Salt Security uses the Moltbook example to show how autonomous agents can operate outside human visibility while still interacting with business systems. That matters for NHI governance because agent access often looks like ordinary API traffic until a malicious skill, prompt injection, or unsafe delegation turns it into a privilege abuse problem.

Key questions

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. The key control is to limit which APIs, data sources, and write actions the agent can chain together in one session. That keeps machine-paced behaviour inside a reviewable boundary instead of relying on human-style session assumptions.

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. Human-in-the-loop keeps accountability attached to those decisions, making them easier to explain, audit, and correct. It is most valuable when the model lacks context or the decision could create privileged access.

Q: What breaks when agents can fetch untrusted skills or code automatically?

A: The trust boundary breaks between instruction intake and privileged execution. If an agent can download code, read secrets, and act on production systems in one flow, malicious input can become authorised behaviour. Security teams need sandboxing, code vetting, and permission separation before they allow those workflows in production.

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.

Technical breakdown

API fabric discovery and shadow agent traffic

The API fabric is the web of internal, external, and dynamically generated interfaces that agents use to reach services and data. In agentic systems, the challenge is not just inventorying known APIs, but detecting shadow APIs created by orchestration layers, plug-ins, and protocols such as MCP. If visibility stops at the gateway, agents can keep calling tools that security teams never classified, approved, or monitored. That creates an identity blind spot because the calling entity is a software actor with delegated privileges, not a human user.

Practical implication: teams need continuous discovery of agent-to-API paths, tied to workload identity and service ownership.

Prompt injection, untrusted skills, and auto-execution risk

Agent ecosystems often let systems retrieve skills, code, or instructions from external sources and execute them with minimal friction. That combines two known risks: untrusted input and privileged execution. If a malicious skill can read tokens, access secrets, or alter downstream requests, the agent becomes a conduit for credential theft rather than a helper. This is especially dangerous when the same identity can both fetch instructions and use tools, because the trust boundary between data ingestion and action execution collapses.

Practical implication: separate instruction ingestion from tool execution and treat downloaded skills as untrusted software.

Behavioural abuse across the agentic AI action layer

Traditional packet inspection sees API calls, but not the business intent behind sequences of calls. Agentic abuse is often behavioural rather than purely technical: a series of apparently valid requests can still form credential harvesting, data exfiltration, or automated fraud. That is why runtime protection has to look for anomalous call chains, not only malformed requests. In identity terms, the real risk is delegated privilege used outside its intended purpose, especially when agents can chain decisions faster than human review can intervene.

Practical implication: monitor for anomalous call chains and bind each agent to narrowly scoped, auditable privileges.

Threat narrative

Attacker objective: The attacker wants to convert trusted agent behaviour into a stealthy channel for secrets theft, unauthorised access, or automated abuse of business systems.

1. Entry occurs when an AI agent retrieves untrusted skills or instructions from an external source and executes them inside the agentic workflow.
2. Escalation follows when the malicious code or prompt influence uses the agent's delegated API access to read secrets, reach hidden services, or expand tool use beyond intended scope.
3. Impact is data exfiltration, privilege abuse, or automated fraud carried through normal-looking API traffic that defenders may not distinguish from legitimate agent activity.

NHI Mgmt Group analysis

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.

Shadow AI in the API fabric creates a discovery gap that compliance teams will feel first. If organisations cannot enumerate which APIs an agent uses, they cannot prove data lineage, enforce purpose limitation, or investigate misuse after the fact. That is why the most urgent control is not more logging, but reliable discovery of agent-to-service relationships. Practitioners should close the inventory gap before they attempt policy tuning.

AI agent risk now combines workload identity, untrusted code execution, and runtime authorisation into one failure mode. The article's underlying lesson is that isolated controls do not hold when an agent can ingest instructions and act on them immediately. API fabric blind spot: the organisation assumes API traffic is understood because the endpoints are known, but the agent can generate new paths, new intents, and new privilege chains faster than review processes can track. Practitioners should align controls to the chain, not the endpoint.

Governance models built for human approval do not map cleanly to autonomous execution. Human workflows assume a person can pause, inspect, and approve a request before it completes. Agentic systems can compress that entire loop into a single runtime decision, which makes classical review and exception handling too slow for meaningful containment. Practitioners should shift from after-the-fact review to pre-authorised, narrowly bounded execution with continuous monitoring.

API security and identity security are converging around the same question: who, or what, is allowed to act on sensitive data? That question now includes machine actors that can make decisions, not just call endpoints. The practical conclusion is that identity programmes need explicit coverage for agent credentials, tool permissions, and revocation paths. Practitioners should manage agentic access as a living identity lifecycle.

What this signals

Agentic AI governance is becoming an access-control programme rather than an innovation side task. Teams that already struggle with secret sprawl and overprivileged service accounts will see the same failure pattern in agents, only faster and harder to audit. The practical signal is that identity ownership, permission scoping, and revocation need to be designed for machine speed, not human workflow. AI Agents: The New Attack Surface report is a useful reference point for the current adoption gap.

Runtime visibility now matters more than static policy because agent behaviour can change after deployment. A policy written at onboarding will not catch a downloaded skill, a new tool path, or a chained API sequence that turns routine work into exfiltration. Security leaders should expect their API, IAM, and SOC teams to share telemetry and decision rights. For a broader control lens, map this to NIST AI Risk Management Framework.

API fabric blind spot: the next phase of agent security will be about proving intent, not just recording traffic. That means programme owners will need to show which agent identities were authorised, which data they could touch, and how quickly access can be withdrawn when behaviour drifts. Teams that cannot answer those questions will struggle with incident response, governance, and regulatory scrutiny.

For practitioners

• 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.
• Detect anomalous call chains at runtime Look for sequences of valid API calls that form data harvesting, privilege escalation, or exfiltration patterns, not just malformed traffic or blocked requests.
• Map AI agent governance to NHI controls Apply identity lifecycle, secret handling, and access review discipline from NHI programmes to agent credentials, tokens, and certificates used in production workflows.

Key takeaways

• AI agents expand risk into the API fabric because delegated machine identities can call tools, fetch code, and move data faster than human review can intervene.
• The most material control gap is visibility into which agent identities access which services, because without that inventory governance and compliance both fail.
• Security teams should treat agent access like a living identity lifecycle, with least privilege, runtime monitoring, and rapid revocation tied to business ownership.

Key terms

• API-first: An API-first organisation designs application interfaces before or alongside the application itself. In identity terms, that means the access model, scopes, and policy enforcement are part of the product architecture rather than added later as a retrofit.
• Agentic AI Action Layer: The agentic AI action layer is the runtime stratum where an AI agent turns intent into execution by calling tools, APIs, or workflows. It matters because risk appears when a model's output becomes an authorised action path with delegated privileges and limited human oversight.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Lethal Trifecta: A risky AI agent condition where one system can read private data, consume untrusted content, and communicate externally. When those three capabilities overlap, the agent can be tricked into disclosing sensitive information through legitimate tools without a conventional exploit.

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.

👉 Salt's full article covers the Moltbook experiment, API fabric exposure, and governance gaps in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It is designed for practitioners who need to bring delegated access, auditability, and revocation discipline into their broader identity programme.