AI agent visibility gaps are exposing the agentic action layer

At a glance

What this is: Autonomous AI agents are turning APIs into an agentic action layer, and many organisations cannot see or govern the machine-to-machine traffic they create.

Why it matters: IAM, PAM, NHI, and security teams need to treat agent identity, API access, and runtime behaviour as one governance problem because blind spots in any layer can let autonomous systems act outside policy.

By the numbers:

• 48.9% of organizations are essentially blind to non-human traffic, unable to monitor what their autonomous agents are doing.
• 48.3% cannot effectively differentiate legitimate AI agents from malicious bots.
• 47% of organizations have had to delay a production release due to concerns about securing APIs exposed to these autonomous systems.
• 23.5% of respondents find their existing security tools very effective at preventing attacks.

👉 Read Salt's research on the 1H 2026 state of AI and API security

Context

The primary issue here is not AI adoption itself, but the governance gap between autonomous agent behaviour and the controls most organisations still use to secure APIs. AI agents now make decisions at runtime, invoke tools, and consume internal services at machine speed, which means legacy session logic and perimeter checks are often too slow and too narrow. In API security terms, the attack surface has shifted from human-driven requests to agentic workflows that behave more like dynamic systems than static users.

That matters for IAM because these agents act like non-human identities even when organisations do not model them that way. If an AI system can authenticate, call internal APIs, use MCP servers, and trigger business actions, then identity, privilege, and auditability become inseparable from API security. The starting position described in the source is increasingly typical for organisations moving fast on agentic AI, which is exactly why visibility and policy design are now the control plane, not an afterthought.

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 do autonomous agents create more API security risk than human users?

A: Autonomous agents can chain actions, improvise workflow order, and operate at machine speed without the natural pauses humans introduce. That means a valid credential can be used for far more complex abuse before detection or review can catch up. The risk is not only access, but speed and scale of misuse.

Q: What breaks when organisations cannot distinguish human from AI agent activity?

A: Access governance loses precision immediately. If teams cannot tell whether a person or an agent triggered an action, they cannot certify access accurately, investigate incidents cleanly, or enforce policy with confidence. The result is not just weaker monitoring, but a control model that can no longer assign the right rule to the right actor.

Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?

A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.

Technical breakdown

What the agentic action layer changes in API security

The agentic action layer is the operational zone where AI agents move from reasoning to execution. An LLM may generate intent, but the actual risk appears when the agent calls APIs, accesses MCP servers, and chains actions across systems without human pacing. Traditional API security assumed known clients, stable request patterns, and human-linked sessions. Autonomous agents break those assumptions because they can improvise workflows, change timing, and alter call sequences in ways that signature-based tools do not model well.

Practical implication: treat agent-to-API traffic as a distinct control domain, not as ordinary application traffic.

Why machine-to-machine visibility is failing

Visibility fails when security tooling cannot reliably classify, trace, and correlate machine-originated activity back to a unique agent identity. The article points to a detection gap where organisations can see traffic volume but not intent, legitimacy, or ownership. That is a governance failure as much as a technical one, because without identity correlation, teams cannot tell whether an agent is performing approved work, operating outside scope, or mimicking legitimate behaviour. Shadow AI emerges when agent infrastructure appears faster than inventory and policy enforcement.

Practical implication: build inventory, attribution, and audit correlation for every agent, API, and MCP connection.

Why legacy WAFs and basic gateways are not enough

Web Application Firewalls and basic API gateways were designed for human web sessions, predictable patterns, and mostly stateless enforcement. They are effective at blocking known bad payloads or obvious abuse, but they do not understand agent goals, tool-chaining, or logical misuse of authorised access. That matters because agentic attacks often look like normal requests until they are viewed as a sequence. In this model, the failure is not simply malicious input, but authorised behaviour that becomes harmful through context and repetition.

Practical implication: add runtime policy and behavioural detection that understands sequence, intent, and privileged tool use.

Threat narrative

Attacker objective: The attacker wants to abuse trusted agentic workflows to reach internal data, trigger unauthorised actions, or operate unseen inside enterprise systems.

1. Entry occurs when an attacker gains control of exposed API credentials, a compromised agent workflow, or an over-permissioned MCP-connected integration.
2. Escalation follows when the attacker uses that trusted channel to invoke internal APIs, enumerate data, or chain agent actions faster than human review can intervene.
3. Impact is data exposure, unauthorised business actions, or release disruption caused by autonomous systems operating outside intended scope.

NHI Mgmt Group analysis

Agentic AI governance now depends on identity, not just content filtering. The source correctly shows that prompts are only one layer of risk, because the real execution path runs through APIs, MCP servers, and connected systems. That means the identity of the agent, the scope of its privileges, and the traceability of its actions matter more than perimeter controls alone. For practitioners, this reframes AI security as a governance problem spanning IAM, NHI, and runtime enforcement.

Shadow AI is really Shadow NHI. When autonomous agents create undocumented endpoints or call internal services outside security oversight, they behave like unmanaged non-human identities with dynamic privileges. That is a more precise and useful concept than treating them as generic AI risk, because it points to inventory, ownership, lifecycle, and revocation gaps. Practitioners should recognise that every uncatalogued agent path is an access path that can outlive policy.

Legacy API controls are being asked to do identity work they were never designed for. WAFs and simple gateways can block malformed traffic, but they cannot govern agent intent, tool sequencing, or machine-speed privilege abuse. This is why the control conversation is shifting toward agentic security posture management and identity-aware detection. Practitioners should treat API governance, NHI governance, and AI governance as a single operating model.

48.9% blind spots are a governance failure, not just an observability problem. The operational gap is that organisations cannot validate what their agents are doing, which means they cannot confidently attest to access, accountability, or policy compliance. That weakens incident response, audit readiness, and executive reporting at the same time. For practitioners, the lesson is simple: if you cannot attribute agent action, you do not control agent action.

API growth is now an AI risk multiplier. The report's finding that nearly half of organisations saw API growth of 51% to 100% in a year explains why governance debt is compounding so quickly. More APIs mean more machine identities, more policy exceptions, and more places for undocumented agent behaviour to hide. Practitioners should expect AI adoption to expose access control debt already sitting in the API estate.

What this signals

Agentic security programmes will increasingly be judged on attribution, not just blocking rates. If teams cannot answer which agent performed which API action, they will struggle to prove policy compliance, investigate incidents, or support board-level assurance. The control objective is shifting from filtering requests to governing machine identity and behaviour across the full workflow.

Agentic action layers will force IAM and security operations to converge. The more that AI systems call internal services, the more access governance, runtime monitoring, and investigation need to share the same telemetry. That creates a strong case for aligning API visibility with identity governance and with standards such as the NIST AI Risk Management Framework.

Blind spots around machine-to-machine traffic will become a release-management issue, not only a security issue. When nearly half of organisations cannot see agent activity, product teams slow down because they cannot prove safety before launch. The practical response is to treat agent inventory, policy coverage, and audit correlation as release gates for any system that invokes enterprise APIs.

For practitioners

• Map every agent to a unique identity Create a registry that ties each autonomous agent, MCP server, and API integration to an owner, business purpose, and revocation path. Without a unique identity and accountable owner, you cannot prove which agent performed which action or enforce least privilege over time.
• Correlate API traffic to agent intent Instrument telemetry so every high-risk call can be traced back to the specific agent, workflow, and privilege scope that generated it. Prioritise correlation for tool use, data pulls, and transaction actions where machine-speed abuse is most likely.
• Replace static API checks with behavioural policy Augment gateways and WAFs with runtime controls that understand request sequences, unusual tool chaining, and deviations from approved agent behaviour. Keep the policy tied to business function, not just endpoint reputation.
• Control shadow MCP and undocumented integrations Inventory MCP servers and other machine-to-machine connectors, then remove or quarantine any integration that lacks formal ownership, approval, or monitoring. Shadow AI becomes harder to exploit when every connector is explicitly governed.

Key takeaways

• AI agents are exposing a governance gap between autonomous runtime behaviour and the controls most organisations still use for APIs.
• The reported blind spots are material: nearly half of organisations cannot monitor machine-to-machine traffic, and only a minority trust their current tools.
• Practitioners need agent identity, runtime policy, and audit correlation before autonomous workflows scale further.

Key terms

• Agentic Action Layer: The operational layer where AI agents turn reasoning into executable actions through APIs, tools, and connected services. It matters because the security risk is not only what the model says, but what the agent is allowed to do at runtime across enterprise systems.
• 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.
• 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.
• Agentic Posture Management: Agentic posture management is the continuous discovery and monitoring of AI agents, their tools, and their permissions. It extends beyond one-time review by tracking what the agent can reach, what data it can access, and how those capabilities change as new skills and integrations are added.

What's in the full report

Salt's full research covers the operational detail this post intentionally leaves for the source:

• Survey methodology and the full response breakdown from more than 300 security leaders, useful if you need to benchmark your programme.
• Expanded findings on agentic security posture management and agentic detection and response, including how Salt frames the control model.
• The report's discussion of machine-to-machine visibility, Shadow AI, and the Agentic Action Layer in more implementation detail.
• The source article's view of how executive scrutiny, board concern, and release delays are shaping AI security decisions.

👉 Salt's full report covers the survey results, control gaps, and agentic security model in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security practitioners a practical foundation for governing autonomous systems that act like identities.