AI agent visibility gaps are exposing the agentic action layer

At a glance

What this is: Salt’s report argues that AI agents have shifted enterprise risk to the API and MCP layer, where visibility into machine-to-machine traffic is still poor.

Why it matters: IAM, API security, and AI governance teams need to treat autonomous agents as governed actors with observable identities, not just model outputs, because their real risk appears in the workflows they invoke.

By the numbers:

• 48.9% of organisations are entirely blind to machine-to-machine traffic.
• 48.3% of organisations cannot distinguish legitimate AI agents from malicious bots.
• 78.6% of security leaders report increased executive scrutiny of AI security risks.
• Only 23.5% of respondents find their existing security tools very effective.

Context

AI agents change the control plane because they do not behave like human users. They consume APIs, chain tool calls, and operate through MCP-connected workflows, which means security teams must govern execution paths, not just prompts.

Salt’s analysis places this in the broader identity and access problem space: once agents become decision-making actors inside production workflows, visibility, authorisation, and accountability have to extend to non-human behaviour. That makes API governance and agent identity part of the same security conversation, not separate programmes.

The report’s starting position is becoming typical rather than exceptional as enterprises move from experimentation to operational deployment of autonomous agents.

Key questions

Q: What breaks when AI agents can reach exposed internal APIs?

A: The break point is governance, not just security tooling. Once an agent can call exposed internal APIs, it can chain permissions, query sensitive data, and trigger workflows at machine speed. That turns a single weak endpoint into a broad access path. Teams need to assume discoverability and chaining, then constrain each callable service with authentication, scoping, and runtime policy.

Q: Why does the agentic action layer create more risk than prompt security alone?

A: The agentic action layer creates more risk because the damage happens where the agent executes actions, not where it generates text. A secure prompt does not stop an over-permissioned agent from calling internal APIs, chaining tools, or moving data across systems. Governance must therefore cover authorisation, endpoint inventory, and runtime monitoring.

Q: What are the signs that AI agent observability is failing?

A: The main signs are missing tool metadata, disconnected traces between agent hops, unexplained retries, and an inability to reconcile a successful call with the actual state change it caused. If operators can see that a tool ran but cannot prove what it changed, observability is not yet enough for production control.

Q: How should teams govern AI agents that can reach APIs, events, and memory?

A: Teams should govern those agents as runtime identities, not as isolated integrations. That means enforcing policy at execution time, logging every tool and data access, and binding actions back to a clear initiating workflow or identity. If the control plane cannot show who acted, what they reached, and why, the programme does not have usable governance.

Technical breakdown

Why the agentic action layer changes API security

The agentic action layer is the set of APIs, tools, and connected services that an AI agent uses to carry out work. Unlike a human session, agent activity can branch dynamically, invoke undocumented paths, and make decisions at machine speed. That breaks assumptions behind legacy monitoring, which was designed around predictable requests and user-driven workflows. When Model Context Protocol servers sit between the model and the enterprise system, they become part of the trust boundary and a new place where access, routing, and logging need governance.

Practical implication: security teams need inventory and policy coverage for the agent-to-API path, not just the application front end.

Why legacy web application firewalls miss autonomous behaviour

Web Application Firewalls and basic API gateways are good at filtering known patterns, but they do not understand agent intent or chained tool use. An agent may issue many small, legitimate-looking calls that together create an unsafe outcome, such as bulk data access or unauthorized workflow execution. Traditional controls also struggle when agents create or discover endpoints that are outside the known application map. That makes static signatures and rate limits insufficient on their own.

Practical implication: add behaviour-aware controls that can correlate multi-step agent activity across sessions and services.

Identity-aware intent analysis for machine actors

Identity-aware intent analysis ties traffic back to a unique non-human identity and then evaluates whether the pattern matches approved purpose. This matters because the question is no longer only whether a request is authenticated, but whether the authenticated agent is acting within its intended function. In NHI terms, the control problem is authorisation, ownership, and continuous monitoring of the machine identity, especially where APIs and MCP servers are being orchestrated by autonomous software.

Practical implication: bind every agent to an owned identity and alert when its observed behaviour diverges from its declared scope.

Threat narrative

Attacker objective: The attacker’s objective is to use machine-speed access through trusted agentic pathways to reach data, workflows, or operational actions that security teams cannot easily distinguish from normal automation.

1. Entry occurs when an AI agent gains access to enterprise systems through legitimate API credentials or an MCP-connected workflow.
2. Credential or permission abuse follows when the agent uses that access to invoke undocumented endpoints or chain tool calls beyond its intended scope.
3. Impact emerges as sensitive data is exposed, business workflows are manipulated, or malicious bots are mistaken for legitimate agents.

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

Agentic action layer visibility is now the governance problem, not a side issue: once AI agents operate through APIs, MCP servers, and internal services, security controls must follow the action path rather than the model prompt. The real exposure is in the execution layer where non-human actors can reach sensitive systems without human-style sessions. Practitioners should treat agent traffic as governed production behaviour, not experimental AI usage.

Shadow AI becomes Shadow API consumption when agents outgrow monitoring assumptions: undiscovered or unmanaged agents do not just create policy gaps, they create unreviewable access paths across the service landscape. That is a direct identity governance problem because the enterprise can no longer say who or what is acting, under which authority, and for what purpose. The practical conclusion is that inventory and ownership of machine identities must extend into agentic workflows.

Legacy perimeter tools are misaligned with autonomous decision-making: WAFs, static rate limits, and signature-based detection were not built to understand logic-based abuse spread across many small calls. This is where the security model fails in practice, because the risk sits in the sequence of actions, not a single malicious packet. Practitioners should re-evaluate whether their detection stack can correlate multi-step agent behaviour across the full workflow.

Agentic governance now overlaps with API security and NHI controls: the article’s core signal is that human-centric security models no longer capture the risk of systems acting with delegated authority. The named concept here is agentic action layer sprawl: uncontrolled growth in agent-to-API and agent-to-tool pathways that outpaces discovery, authorisation, and monitoring. Teams should build controls around identity, scope, and observability before agents become core operational dependencies.

Salt’s data shows the control gap is already operational, not theoretical: executive scrutiny is rising while confidence in current tools remains low, which means board-level concern is outpacing technical visibility. That gap is especially relevant for identity programmes, because agent authorisation, session monitoring, and lifecycle ownership now sit on the same risk path. Practitioners should plan for machine actors to be governed with the same discipline as privileged users, but with stronger runtime control.

From our research library:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Agentic action layer sprawl: the fastest-growing risk is not model output itself but the ungoverned expansion of agent-to-API and agent-to-tool pathways. When those pathways are invisible, authorisation becomes guesswork and incident response loses context. Teams should expect identity governance to move closer to runtime control for machine actors.

Salt’s figures on autonomous AI adoption and access scope show why this is becoming a programme issue rather than a niche engineering concern. When security leaders expect AI to run major infrastructure functions and over-privileged systems are far more likely to fail, the control point shifts to identity, scope, and continuous validation.

For practitioners

• Map agent-to-API dependencies Build an inventory of every AI agent, MCP server, and downstream API it can invoke, then record the business purpose and owner for each path.
• Bind each agent to a unique identity Assign non-shared credentials or workload identities so every agent action can be traced, scoped, and revoked without affecting other systems.
• Monitor machine-to-machine traffic for drift Baseline normal agent behaviour and alert on unusual call sequences, bulk pulls, new endpoints, or tool use outside approved workflows.
• Reassess legacy API controls Test whether gateways and WAFs can detect chained, logic-based abuse rather than only malformed requests or simple rate anomalies.
• Create offboarding rules for shadow agents Define how to disable undocumented agents, revoke their access, and remove their API paths when ownership is unclear or the use case ends.

Key takeaways

• AI agents are pushing security teams to govern the execution layer, where APIs, MCP servers, and delegated access create the real exposure.
• The visibility gap is already material, with organisations struggling to distinguish legitimate automation from malicious traffic and to monitor machine-to-machine behaviour.
• Identity-bound authorisation and runtime monitoring are the controls that change the risk equation, because prompt filtering alone cannot govern autonomous action.

Key terms

• Agentic action layer: The agentic action layer is the runtime zone where AI agents choose tools, query data, and execute tasks. It is not the model itself. In governance terms, this is where identity, privilege, and policy enforcement must meet actual machine behaviour.
• Machine-to-Machine Traffic: Automated traffic generated by systems, services, or agents rather than human users. For fraud and identity teams, the issue is not whether the traffic is machine-originated, but whether it is trusted, traceable, and aligned to the scope that was actually approved.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Identity-Aware Intent Analysis: Identity-aware intent analysis is a detection approach that ties behaviour to the specific machine identity performing it, then checks whether the observed actions fit the expected purpose. It helps distinguish legitimate orchestration from abuse in machine-to-machine environments.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and agentic AI identity. It gives practitioners a common language for governing delegated access across identity and security programmes.