API security now depends on runtime context, not just gateway controls

At a glance

What this is: This is an analysis of why API security now depends on runtime context, with Salt arguing that gateway-centric controls no longer provide enough visibility into malicious traffic, sensitive data exposure, and abnormal behaviour.

Why it matters: IAM, API, and security teams need this shift because APIs now sit at the centre of business-critical services, so identity, authorisation, and runtime signals must be governed together.

By the numbers:

• 91% of those surveyed experienced a security incident in the last 12 months.
• API traffic for Salt customers has grown 51% while malicious traffic has grown at 211%.
• Malicious traffic has grown at 211%.

Context

API security is the governance problem that appears when business services, third-party integrations, and sensitive data all flow through the same application interface. Traditional gateway and WAF controls can filter traffic, but they do not reliably explain whether a request is normal, whether it should be authorised in context, or whether it is exposing data in ways regulators and partners will care about.

This article uses Finastra as the operational example, but the underlying pattern is broader: organisations are discovering that API security is no longer just about the edge. Where APIs are the connective tissue for banking, fintech, and internal microservices, runtime context becomes a control requirement, not a nice-to-have.

Key questions

Q: Where do gateway controls fail in API security programmes?

A: Gateway controls fail when they are treated as the whole control plane. They can block obvious bad traffic, but they usually cannot determine whether an API call is consistent with real business behaviour, identity scope, or data sensitivity. Once attackers stay inside normal-looking request patterns, runtime context becomes essential for separating legitimate use from abuse.

Q: Why does API traffic growth increase abuse risk?

A: When API usage grows, defenders get more legitimate noise to separate from malicious behaviour. That creates more opportunities for attackers to hide low-and-slow activity inside normal traffic volumes, especially where APIs drive customer workflows and sensitive data exchange. Growth alone is not the risk. The risk is that detection becomes harder unless behaviour is analysed in context.

Q: What are the signs that API security monitoring is failing?

A: API monitoring is failing when teams cannot see request patterns, access failures, or unusual traffic in real time. Common signs include rising error rates without explanation, repeated probing that goes undetected, missing authentication logs, and delayed incident response. If logs are incomplete or not reviewed continuously, attackers can abuse APIs for longer before anyone notices.

Q: How should IAM teams govern API access patterns that are designed for developers first?

A: Treat developer-facing API patterns as identity design decisions, not just application plumbing. Review authentication method, token scope, revocation path, and logging at the point the pattern is introduced, because those choices often become inherited control assumptions once the system is in production.

Technical breakdown

Why gateway controls miss API abuse patterns

API gateways and WAFs are built to enforce coarse traffic rules, not to understand application behaviour in context. They can see requests and responses, but they usually cannot tell whether a sequence of calls is consistent with a real user journey, a compromised token, or an attacker chaining low-and-slow abuse across endpoints. That limitation matters because API attacks often look like legitimate business traffic until behaviour is correlated over time. Runtime API security adds that behavioural layer, combining call patterns, identity context, and data sensitivity so defenders can distinguish expected variation from abuse.

Practical implication: treat gateways as enforcement points, not as sufficient API security visibility.

Runtime context and sensitive data exposure

Runtime context means understanding what an API is doing, who or what is calling it, what data it touches, and whether that pattern is expected for that workload. In practice, this turns API security into a correlation problem across identity, request behaviour, and data flow. That is especially important where sensitive data is embedded in business-critical services, because exposure can occur even when the endpoint itself is not obviously vulnerable. Context also helps separate benign changes, such as a modified API version, from malicious behaviour that tries to hide inside normal operational noise.

Practical implication: map API calls to business context and data sensitivity before you decide whether an event is suspicious.

Why build-time and runtime controls both matter

API security breaks down when teams split responsibility between development and operations without shared visibility. Build-time controls help discover APIs, validate design assumptions, and reduce exposed risk before deployment. Runtime controls then detect abuse, account takeover, and abnormal usage once the service is live. The article’s core point is that neither side is enough alone. A security programme that only watches production traffic can miss design flaws, while a programme that only reviews code can miss live exploitation patterns.

Practical implication: connect CI/CD governance to runtime detection so API security decisions are consistent across the lifecycle.

Threat narrative

Attacker objective: The attacker’s objective is to exploit trusted API flows to reach sensitive services, abuse accounts, and extract or manipulate data at scale.

1. Entry occurs through legitimate API access paths, where malicious requests blend into ordinary service traffic and evade coarse perimeter filtering.
2. Credential or session abuse allows the attacker to make calls that appear valid at the transport layer but are abnormal in behavioural context.
3. Escalation happens when the attacker uses business-critical API flows to reach sensitive data or account functions that traditional application controls do not inspect closely enough.
4. Impact is achieved through account takeover, data exposure, or repeated abuse of high-value services before the pattern is recognised.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.

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

API security has become a runtime governance problem, not just an edge-control problem. Gateways and WAFs can still filter traffic, but they do not provide enough context to judge intent, sequence, or data sensitivity. That gap matters most where APIs sit in the core of financial and partner ecosystems. Practitioners should treat runtime correlation as part of API governance, not an optional monitoring layer.

Context is the differentiator because normal-looking API traffic is where abuse hides. Attackers increasingly work inside legitimate access patterns, which means static allow and deny rules are too blunt to carry the whole load. The useful control question is no longer only whether a request reached the API, but whether that request belongs in that business and identity context. Teams should design detection around expected behaviour, not just endpoint presence.

API security now intersects directly with identity governance and NHI controls. API calls are frequently made by service accounts, tokens, and other non-human identities, so authorisation decisions are inseparable from credential lifecycle, token scope, and workload trust. That makes this a governance issue for IAM and NHI teams as much as for application security. Practitioners should align API telemetry with identity scope and entitlement review.

Build-time and runtime controls form a single control plane in mature programmes. The article shows why organisations cannot separate API discovery, CI/CD integration, and live attack response into disconnected workflows. The important shift is from isolated tooling to lifecycle governance over the API itself. Practitioners should assess whether their current model can see the same API from design through production.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: NHI Authentication Guide

What this signals

Runtime context is becoming the practical boundary for API security. The control question is shifting from whether an API is exposed to whether the organisation can explain each call in business and identity terms. That is where API security starts to overlap with workload identity, token governance, and service-account review, not just application defence.

API governance now has an NHI dimension. Many API calls are made by tokens and service accounts rather than people, so lifecycle control over non-human identities directly affects abuse detection. Teams that cannot link API telemetry to credential scope will struggle to separate legitimate automation from misuse.

Finastra’s operating model shows the direction of travel for sensitive environments. Security teams need evidence that data exposure, workflow integration, and runtime detection are all tied together before an incident forces the issue. The programme signal is clear: if API security still lives only at the gateway, the governance model is lagging behind the threat.

For practitioners

• Map API traffic to runtime context Correlate caller identity, endpoint sequence, data touched, and business workflow so abuse can be separated from legitimate variation.
• Classify APIs by data sensitivity Identify which APIs expose regulated or operationally sensitive data and prioritise deeper monitoring on those services first.
• Integrate security into CI/CD and runtime workflows Connect API discovery and design review to live detection and response so development and security teams work from the same inventory.
• Review token scope and service account use Check whether service accounts, tokens, and other non-human identities have access scopes that still make sense for current API behaviour.

Key takeaways

• API security now depends on understanding runtime behaviour, not only on filtering traffic at the gateway.
• The article’s data shows a widening gap between legitimate API growth and malicious activity, which makes contextual detection more important.
• IAM and security teams need a shared view of identity scope, sensitive data, and live API behaviour to govern access effectively.

Key terms

• Runtime Context: Runtime context is the set of signals used to judge whether an AI agent's behaviour is appropriate while it is acting. It includes identity, data access, model behaviour, posture, and environment. In practice, it is the difference between checking permission and evaluating purpose.
• API Behavioural Monitoring: API behavioural monitoring observes how authenticated requests accumulate over time, rather than judging each request in isolation. It correlates identities, objects, frequency, and sequence to detect misuse that stays syntactically valid and rate-limit compliant. This is the control layer perimeter inspection lacks.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• API Data Exposure: API data exposure occurs when an interface reveals more sensitive information than the business or regulator would consider appropriate for the calling context. The risk is not only broken access control, but also over-broad data returned through otherwise valid API calls.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps practitioners connect identity governance to the broader security decisions their programmes now depend on.