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.
At a glance
What this is: Salt argues that AI agent action layers create a security gap because agents operate through API traffic, fetch untrusted skills, and act outside human visibility.
Why it matters: This matters because IAM, PAM, and API security teams now have to govern machine actions that may be dynamic, opaque, and driven by untrusted inputs rather than fixed user workflows.
Context
AI agent action layers are the runtime and API pathways that let agents call tools, move data, and trigger downstream actions without a human in the loop. The governance gap appears when those calls are treated as ordinary machine-to-machine traffic even though the actor can select actions, fetch code, and alter behaviour dynamically.
The problem is not just exposure at the API edge. It is the lack of control over identity, intent, and runtime authorisation once an agent starts chaining requests across internal services, SaaS systems, and shadow integrations. In that environment, traditional API monitoring can see traffic but still miss the security meaning of the actions.
For identity and access teams, this is an NHI governance issue as much as an API security issue. If the agent identity is not inventoried, scoped, and monitored as a distinct actor, the organisation has no reliable way to govern what the agent can do or whether its actions remain within policy.
Key questions
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: Why do AI agent action layers create more risk than ordinary API traffic?
A: Because the risk is not just that an API was called, but that the caller can choose actions, sequence tools, and alter behaviour at runtime. That makes identity and intent part of the security decision. When those signals are missing, the organisation cannot tell whether the call was legitimate automation or agentic misuse.
Q: What are the signs that API governance is failing at runtime?
A: Common signs include undocumented endpoints, duplicated ownership, inconsistent responses, rising retry loops, and frequent discovery of APIs that are not in the catalogue. Those signals show that the live estate and the formal control model no longer match. Once that happens, security and reliability teams are managing assumptions instead of actual behaviour.
Q: How can organisations govern sensitive agent actions without blocking automation?
A: Use a split model. Allow low-risk actions to proceed under tightly scoped, short-lived credentials, but route irreversible or high-impact actions through explicit human approval. That keeps automation usable while preserving accountability where the business impact is highest. The key is to separate routine execution from delegated authority, not to approve everything the same way.
Technical breakdown
Why agent action layers create a distinct control plane problem
An action layer is the operational layer where an AI agent selects tools, invokes APIs, and passes outputs to the next step in a task chain. That is different from a normal application flow because the actor can change its path at runtime. In practice, the enterprise must govern not just the API endpoint but the combination of identity, intent, and execution context that surrounds each call. If that context is missing, packet inspection and gateway rules only show that an API was used, not whether the action was authorised for that agent in that moment.
Practical implication: Map agent identities to the specific actions they can perform and treat action-layer governance as a separate control surface from ordinary API management.
How untrusted skills and prompt injection become execution risk
When agents automatically fetch skills or executable logic from external sources, they are effectively importing code and instructions into the task flow. That creates a prompt injection and tool-execution problem at the same time, because the agent may follow hostile instructions embedded in content it retrieved. If those skills can read secrets, call external services, or write back to systems, the impact is not limited to model output quality. It becomes a direct path to credential exposure, data movement, and unauthorised actions across connected services.
Practical implication: Put approval, provenance, and sandboxing controls around agent-delivered skills before they can reach production identities or sensitive data.
Why behavioural detection matters more than static rule checks
Agentic systems can chain multiple small actions into a larger outcome that does not look malicious at the level of any single request. That is why static allowlists and simple API packet inspection are insufficient. Security teams need behavioural context, such as unusual sequencing, abnormal tool choice, or access to data that the agent does not normally need for a given task. This is especially important where agents can use APIs, MCP-based tools, and shadow services in the same workflow. The detection problem is therefore about recognising intent drift over time, not just blocking obvious bad traffic.
Practical implication: Use behavioural analytics to spot multi-step agent workflows that remain individually valid but collectively exceed the approved task boundary.
Threat narrative
Attacker objective: The objective is to turn a trusted agent workflow into a covert path for data theft, privilege expansion, or automated abuse across connected systems.
- Entry occurs when an AI agent is allowed to operate through ordinary API and tool connections without explicit visibility into every downstream call.
- Credential or code abuse follows when the agent fetches untrusted skills or consumes malicious instructions that can expose secrets and alter its behaviour.
- Escalation happens as the agent chains API calls across services, expanding from a single task into broader access, data movement, or automated fraud.
- Impact is the unauthorised exfiltration of data, privilege escalation, or other downstream business abuse carried out through the API fabric.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agent action layers are becoming a governance boundary, not just a technical integration layer. When agents can choose tools, fetch skills, and chain API calls, the control problem shifts from simple authentication to action authorisation. Traditional API controls were designed for predictable service flows, not for software that changes its own path at runtime. The practical conclusion is that organisations need a distinct policy layer for agent actions, not just broader API visibility.
Untrusted skills create a new form of secret exposure risk for NHIs. The article’s most important identity signal is that the agent can ingest external logic and then use that logic to reach private keys and other sensitive assets. That makes the agent itself a non-human identity with a supply chain problem around its executable inputs. OWASP-NHI and OWASP-AGENTIC both point to the same governance failure: uncontrolled execution paths attached to a machine identity.
API fabric blindness is the core failure mode this article exposes. The organisation may see traffic, but it cannot explain which AI actor made the call, why it made it, or whether the call was within policy. That is a governance failure, not just a tooling gap, because it prevents auditability, data lineage, and accountability. The practitioner takeaway is that identity, intent, and telemetry must be bound together before agentic use cases scale.
Behavioural control will matter more than point-in-time approval. Agentic systems can complete harmful sequences without tripping a single request-level rule. That means governance has to detect cross-call patterns, unusual task drift, and hidden use of shadow services. The field should expect API security and NHI governance to converge around runtime behavioural policy as the default control model.
Regulatory pressure will follow the control gap. Once agents can move data and trigger actions without a clear human operator, evidence requirements under frameworks such as the EU AI Act become harder to satisfy. Organisations will need to show who or what acted, what data was touched, and which policies constrained the action. The practical implication is that auditability now belongs in the design phase, not after deployment.
From our research library:
- Gartner predicts that by the end of 2026, 40% of enterprise apps will feature task-specific AI agents.
- Read next: Agentic AI Identity Guide
What this signals
API fabric blindness: the real risk is not just exposed endpoints, but the inability to explain which agent made each call, why it was made, and whether the action stayed inside policy. That means agent identity has to be governed as part of the control plane, not treated as a logging afterthought.
Enterprises should expect agentic workflows to force convergence between API security and NHI governance. Once an autonomous system can fetch skills, chain calls, and touch sensitive data, the programme question becomes whether runtime authorisation is tied to task intent strongly enough to resist prompt injection and shadow integrations.
For practitioners
- Inventory agent identities and their reachable APIs Build a live register of each agent, the APIs it can call, and the data domains those calls can reach. Treat unknown or dynamically discovered endpoints as shadow integration risk, not harmless convenience.
- Constrain skill ingestion and executable inputs Block agents from auto-executing untrusted skills, downloaded code, or prompt-supplied instructions unless provenance, approval, and sandboxing checks have passed.
- Bind authorisation to task context Require policy decisions to consider actor identity, requested action, target data sensitivity, and task purpose before a call is allowed to proceed.
- Monitor for multi-step behavioural drift Look for sequences of individually valid calls that together reveal data scraping, secret access, or privilege expansion across the API fabric.
Key takeaways
- AI agents turn the API layer into a governance problem because the control challenge is now about action intent, not just endpoint exposure.
- Untrusted skills and runtime tool selection create a direct route from agent behaviour to secret exposure, privilege expansion, and automated abuse.
- The practical fix is to bind identity, task scope, provenance, and behavioural monitoring together before autonomous workflows are allowed into sensitive systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10, OWASP API Security Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Agents using APIs without clear runtime trust checks fit this authentication gap. |
| NHI-05 — Overprivileged NHI | The article’s core risk is agents doing more through APIs than they should be allowed to do. | |
| NHI-02 — Secret Leakage | Untrusted skills that can read private API keys create a direct secret exposure path. | |
| Recommendation — Tie agent authentication to task context and verify each runtime action before granting access. Restrict agent permissions to the minimum API scope needed for each task. Prevent agents from accessing or exporting secrets from tool outputs and downloaded skills. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The article centres on agents choosing and chaining tools and APIs in unsafe ways. |
| ASI09 — Human-Agent Trust Exploitation | Moltbook shows agents influencing one another and consuming untrusted content as if it were safe. | |
| Recommendation — Constrain which tools agents can invoke and block unapproved tool chaining. Treat agent-supplied content and peer instructions as untrusted inputs until verified. | ||
| OWASP API Security Top 10 | API6 — Unrestricted Access to Sensitive Business Flows | Agentic workflows can trigger high-risk business actions if flow-level controls are weak. |
| Recommendation — Apply flow-level checks so agents cannot complete sensitive business processes without explicit policy. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article describes secret theft and data exfiltration through malicious skills and API calls. |
| Recommendation — Map agent abuse paths to credential access and exfiltration techniques in your detections. | ||
Key terms
- Agent Layer: The agent layer is the part of an AI workload where the system makes runtime decisions and takes actions. It includes prompt handling, tool calls, code execution, network access, and data retrieval. In security terms, this is where control-plane visibility ends and behavior-based risk begins.
- API Fabric: API fabric is the connected layer that lets applications, services, and data exchange information through APIs in a coordinated way. It typically includes API gateways, service discovery, policy enforcement, authentication, observability, and lifecycle controls, so teams can manage traffic, access, and dependencies across distributed systems consistently.
- Untrusted Skill: An untrusted skill is external executable logic, code, or instruction content that an AI agent can import into its workflow. It matters because the skill can read secrets, alter agent behaviour, or create a hidden execution path into sensitive systems.
- Behavioural Drift: Behavioural drift is the gradual change in what an identity does compared with what it was originally approved to do. For AI agents, drift can come from prompt changes, model updates, expanded integrations, or altered workflows, which makes access review alone an incomplete control.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners building durable controls around machine identities, access scope, and governance.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org