Who is accountable when API-layer attacks on AI agent workflows bypass legacy WAF coverage?

Accountability sits with the teams that own application security, API governance, and web access control, because they are responsible for matching controls to current traffic patterns. If WAF rules do not understand agentic behavior, organisations must update detection, logging, and response processes. Governance should cover both exposed APIs and internal agent-driven workflows.

Why This Matters for Security Teams

API-layer attacks against AI agent workflows expose a gap that traditional perimeter thinking often misses: the request may be authenticated, the endpoint may be known, and the WAF may still be blind to the harmful action taking place inside the agent’s tool use. That shifts accountability toward the teams responsible for application security, API governance, and detection engineering, because they own the controls that can actually see intent, sequence, and tool invocation. Guidance from OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to governance, monitoring, and misuse resistance as core responsibilities rather than optional add-ons.

The practical issue is that a legacy WAF is usually tuned for signatures, paths, payload patterns, and classical web abuse. Agent workflows introduce new failure modes: tool abuse, indirect prompt injection, privilege escalation through APIs, and multi-step abuse that looks normal at the request layer but abnormal at the workflow layer. In mature environments, accountability also extends to the owners of the agent platform, because they control prompt templates, tool permissions, logging, and kill-switches. In practice, many security teams encounter this only after an agent has already been used as the attack path, rather than through intentional control design.

How It Works in Practice

Operational accountability should be assigned by control plane, not by where the traffic first arrives. A WAF team can remain responsible for web-layer filtering, but the application security, API governance, and AI platform owners must own the controls that inspect agent actions, enforce authorization at each tool call, and preserve evidence for response. This is especially important when the same API is used by humans, services, and autonomous agents with different trust assumptions.

Effective programs usually break the problem into layers:

• API authentication and authorisation that distinguish human sessions from machine and agent identities.
• Per-tool and per-action policy checks so the agent cannot exceed its allowed scope.
• Structured logging of prompts, retrievals, tool calls, and responses for correlation and investigation.
• Detection rules that look for workflow abuse, unusual tool sequencing, and repeated failed actions.
• Incident response playbooks that can revoke tokens, disable tools, or pause agent execution quickly.

For adversary tradecraft and attack mapping, MITRE ATLAS adversarial AI threat matrix helps teams frame model and agent abuse, while MITRE ATT&CK Enterprise Matrix remains useful for the surrounding identity, credential, and lateral movement behaviours that often accompany the attack. Security teams should also watch advisories and campaign reporting such as Anthropic’s first AI-orchestrated cyber espionage campaign report, because it shows how quickly attackers adapt tool-enabled automation. These controls tend to break down when agents are allowed broad tool access across fragmented microservices because no single owner can see the full execution chain.

Common Variations and Edge Cases

Tighter agent controls often increase engineering overhead and reduce automation speed, so organisations have to balance risk reduction against release friction and operational complexity. There is no universal standard for exactly how much authority an AI agent should have, which means accountability must be explicit in policy, not assumed from existing WAF or appsec ownership.

Two edge cases matter most. First, internal agent workflows can be more dangerous than public APIs because they often inherit privileged network access and bypass user-facing controls. Second, some attacks never reach a classic blocked request state at all, because the agent is induced to misuse legitimate endpoints in a sequence that appears authorised step by step. Current guidance suggests the right response is to pair perimeter controls with policy enforcement, telemetry, and human override points, not to treat the WAF as the primary control.

Frameworks such as the CSA MAESTRO agentic AI threat modeling framework reinforce that accountability should follow the system owner who can change permissions, logging, and agent guardrails. Where legal or regulatory obligations apply, the accountable team should also ensure retention, escalation, and change control are defined for agent-driven abuse scenarios. The practical failure point is usually not policy absence, but ownership gaps between the WAF, the API gateway, and the team running the agent workflow.

Related resources from NHI Mgmt Group

• Who is accountable when AI-enabled attacks bypass legacy access controls?
• Who is accountable when machine-speed attacks bypass manual response workflows?
• Why do broad API scopes create more risk for human and AI agent workflows?
• Who is accountable when an AI agent reads restricted files through a bypass?