What breaks when API security focuses only on single requests?

Why This Matters for Security Teams

api security that evaluates each call in isolation can miss the real attack surface: a sequence of valid requests that becomes harmful only when chained. That is especially dangerous for NHIs, service accounts, and AI agents, because the identity is often trusted to complete a workflow, not just a single transaction. NIST’s control model in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that access control and auditability must account for context, not just authentication.

This is where teams often underestimate blast radius. A request can look benign, yet still be one step in a sequence that reaches records, changes entitlements, or triggers approval logic. NHIMG research on the Ultimate Guide to NHIs highlights how widespread this problem is: 97% of NHIs carry excessive privileges, which means a workflow can accumulate power long before any single API call appears suspicious. In practice, many security teams encounter abuse only after an attacker or agent has already combined several individually valid calls into an outcome that no isolated request would justify.

How It Works in Practice

The correct control boundary is the workflow, not the request. A single API call often has no obvious risk on its own, but a series of calls can reveal intent: enumerate records, fetch a token, change a setting, then commit the change. For autonomous software, this is even more pronounced because agents can plan, retry, branch, and chain tools in ways that human users rarely do. Static per-endpoint allowlists and simple role checks do not capture that behavior.

Security teams should evaluate the full context around each step: who or what is acting, what state changed before, what resource is next, and whether the action fits the declared task. In mature environments, that means tying request authorization to workflow policy, not just identity. Use short-lived credentials, step-up checks for sensitive transitions, and telemetry that correlates request sequences across services. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports this broader view of least privilege, logging, and change control, while NHIMG’s State of Non-Human Identity Security shows why it matters operationally: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes multi-step abuse hard to detect.

• Correlate calls into sessions or task runs, not isolated events.
• Bind authorization to action sequence, state, and downstream impact.
• Use time-limited secrets and revoke them when the workflow ends.
• Alert on unusual call chaining, privilege escalation, or repeated retries.

These controls tend to break down when legacy APIs are loosely coupled and shared across many services, because the sequence context is lost between gateways, logs, and downstream applications.

Common Variations and Edge Cases

Tighter workflow-aware control often increases engineering overhead, requiring organisations to balance stronger abuse prevention against system complexity and latency. That tradeoff is real, especially in distributed estates where every service owner interprets “normal” differently. Current guidance suggests the highest-value protections should focus on workflows that can move money, expose data, approve access, or mutate configuration.

Edge cases appear in event-driven systems, batch jobs, and agentic pipelines. A request may be harmless at ingestion time, yet dangerous after a queue, retry, or asynchronous approval path. There is no universal standard for this yet, but best practice is evolving toward policy checks at each trust boundary and runtime correlation across the whole path. The McDonald's McHire AI Chatbot Default Credentials incident is a good reminder that weak controls at one step can cascade into a much larger exposure, while the T-Mobile Breach illustrates how identity and access failures can expand well beyond the first touched system. Practitioners should treat multi-step authorization as the default assumption, not the exception, whenever an identity can chain actions across systems.

Related resources from NHI Mgmt Group

• What breaks when security teams rely only on DSPM for AI agent governance?
• What is MCP in the context of AI security?
• What are the security risks associated with AI agents?
• What is the difference between workload identity and API keys for AI agents?