How should security teams detect multi-step API attacks that look legitimate at the request level?

Why This Matters for Security Teams

Multi-step API attacks are hard to catch because each individual request can look normal: valid auth, expected headers, and plausible parameters. The risk sits in the sequence, not the single call. That is why request-level allowlists and perimeter filters often miss business-logic abuse, credential replay, and low-and-slow probing that stays inside nominal limits.

For NHI and agent-heavy environments, this gets worse because service accounts, OAuth apps, and AI-driven workloads can generate high-volume, high-variance traffic without a human in the loop. NHI Management Group research shows only 1.5 out of 10 organisations are highly confident in securing NHIs, and 85% lack full visibility into third-party vendors connected via OAuth apps in The State of Non-Human Identity Security. That visibility gap is exactly where multi-step abuse hides. Security teams should pair API telemetry with identity context, rate anomalies, and sequence analysis, using NIST Cybersecurity Framework 2.0 to structure detection coverage. In practice, many security teams discover the attack only after a clean-looking chain of calls has already reached sensitive data or privileged actions.

How It Works in Practice

Effective detection starts by treating an API session as a behaviour stream. Build baselines for normal call order, timing, object access patterns, token reuse, and error rates for each client, workload, and tenant. Then correlate weak signals across time windows so that small deviations become meaningful when linked together. This is closer to threat hunting than classic alerting.

Practitioners usually combine four layers:

• Sequence correlation: flag unusual call chains, such as search, enumerate, enrich, then export.

• Identity context: tie requests to the NHI, OAuth app, or service principal rather than only the IP or session token.

• Behavioural baselining: compare request cadence, object fan-out, and token scope usage against normal peers.

• Incident stitching: merge low-confidence alerts into one case when they share actor, token, target object, or timing.

This approach aligns with attack-path thinking in the MITRE ATT&CK Enterprise Matrix, where initial access, discovery, and exfiltration are often separated by many benign-looking actions. For NHI-specific investigation patterns, the 52 NHI Breaches Analysis is useful for seeing how compromised identities are abused over time rather than in one obvious burst. Current guidance also suggests enriching telemetry with business-object metadata, because changing customer IDs, record IDs, or tenant IDs is a common tactic in API abuse.

These controls tend to break down in high-cardinality environments with unstable client behaviour, where noisy autoscaling and ephemeral workloads make “normal” hard to define.

Common Variations and Edge Cases

Tighter sequence detection often increases false positives, so teams have to balance sensitivity against analyst load. That tradeoff matters most when legitimate workflows are non-linear, such as mobile apps, retries, queued jobs, batch integrations, or AI agents that can chain tools unpredictably.

There is no universal standard for this yet, but best practice is evolving toward context-aware scoring rather than fixed signatures. For example, an API call that is harmless alone may become suspicious if it follows unusual credential refreshes, touches many object IDs, or comes from an NHI with recently expanded scope. The Ultimate Guide to NHIs - Key Challenges and Risks and the Top 10 NHI Issues both reinforce that weak monitoring and over-privileged identities are frequent root causes, so detection should be paired with scope reduction and rotation hygiene. Where legitimate automation is highly variable, teams should suppress on known workflow signatures but keep a separate watchlist for unusual fan-out, cross-tenant access, and repeated object enumeration.

In practice, the hardest cases involve authorized integrations that are already trusted, because attackers deliberately imitate the timing and shape of normal service traffic.

Related resources from NHI Mgmt Group

• How should security teams detect email attacks that look legitimate at first glance?
• How should security teams correlate email, IdP, and SaaS signals to detect identity attacks that look legitimate in each system on its own?
• How should security teams detect attacks that look like normal user activity?
• How should security teams test multi-step API workflows for abuse paths?