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

At a glance

What this is: This is a Salt webinar recap showing why API security has moved beyond gateway and WAF coverage toward context-aware discovery, runtime detection, and build-time integration.

Why it matters: It matters because APIs increasingly expose sensitive business functions and data, and IAM, PAM, and security teams need to treat API access, lifecycle, and telemetry as part of identity governance, not only application security.

By the numbers:

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

👉 Read Salt's webinar recap on Finastra's API security journey

Context

API security has become a governance problem, not just a perimeter problem. As APIs carry more sensitive data and business-critical transactions, controls that focus only on gateway filtering or inline inspection miss how services are discovered, changed, and abused across the full API lifecycle. In identity terms, the same pressure that exposes non-human identities in cloud and SaaS environments also shows up in API access paths, where authentication, authorization, and telemetry need to work together.

The Finastra discussion is a useful example because it sits at the intersection of application security, data protection, and financial-services oversight. The organisation needs to distinguish normal change from malicious behaviour, preserve sensitive data in its own environment, and satisfy regulators and partners at the same time. That is typical of mature API programmes in regulated environments, where the control problem is less about having tools and more about aligning build-time and runtime governance.

Key questions

Q: How should security teams govern APIs that support third-party and partner integrations?

A: They should treat partner-facing APIs as governed access paths, not just technical interfaces. That means maintaining endpoint inventories, mapping exposed data, applying policy based on business context, and monitoring for behavioural deviation. Where APIs underpin regulated workflows, IAM, application security, and compliance teams should share the same policy model and response process.

Q: Why do WAFs and gateways fall short for modern API security?

A: Because they mainly see traffic patterns, not business context. Modern API abuse often uses valid endpoints, legitimate credentials, and request sequences that look normal until you understand the service and data being targeted. Teams need contextual discovery and runtime detection to identify abuse that generic perimeter controls miss.

Q: What do security teams get wrong about API security scanning?

A: They often treat API scanning as a vulnerability-only exercise. In practice, API findings frequently point to authentication failures, overexposed data, and broken trust between services. That means the response must involve IAM, token governance, and service identity review, not just patching the API surface.

Q: Who should own API security when regulators and partners both depend on the same service layer?

A: Ownership should be shared across security, application, IAM, and platform teams, with clear accountability for discovery, policy, monitoring, and incident response. In regulated environments, the organisation also needs a defensible story for what data each API exposes and how that exposure is controlled over time.

Technical breakdown

Why WAFs and gateways miss modern API abuse

Web application firewalls and API gateways were built to enforce policy at the edge, but modern API abuse often happens in ways that look legitimate at first glance. Attackers target valid endpoints, sequence requests to mimic normal usage, and exploit business logic rather than simple payload signatures. That makes context essential: the security system has to understand which APIs exist, what data they expose, who should call them, and how behaviour changes over time. In practice, this is closer to identity-aware authorisation and behavioural baselining than classic perimeter filtering.

Practical implication: teams need API discovery plus behavioural detection, not only inline blocking at the gateway.

How runtime and build-time API security complement each other

Build-time controls reduce the number of exposed weaknesses before code reaches production, while runtime controls detect abuse that only appears once APIs are live and connected to partners, customers, and internal services. The two phases solve different problems. Build-time controls help identify unsafe design, missing authentication, and unintended exposure. Runtime controls watch for account takeover, abnormal request patterns, and misuse that slips through development checks. A mature API programme links both phases so that development, security, and operations see the same risk picture.

Practical implication: integrate API security into CI/CD and keep runtime telemetry aligned to the same policy model.

Why sensitive-data visibility matters in API security

API security fails when teams can see traffic but cannot see what data the API actually exposes. Data classification in this context means mapping endpoints to the sensitive records, transactions, or fields they can return or modify, then using that knowledge to inform policy and regulatory reporting. This is especially important where third parties or business partners consume the API, because the security question becomes who can reach the data, under what conditions, and how that exposure is monitored. Without this mapping, controls remain generic and response becomes slower and less accurate.

Practical implication: classify API-exposed data by endpoint and use that mapping to drive policy, logging, and partner assurance.

Threat narrative

Attacker objective: The attacker aims to use legitimate-looking API access to steal data, take over accounts, or interfere with financial workflows without triggering conventional perimeter controls.

1. Entry occurs through exposed or poorly governed APIs that present valid business endpoints to external or partner-facing users.
2. Escalation follows when attackers abuse normal-looking requests, reuse accounts, or exploit weak behavioural controls to move beyond intended access.
3. Impact lands as account takeover, sensitive data exposure, or manipulation of business-critical API transactions.

NHI Mgmt Group analysis

API security is becoming a runtime identity problem. The central issue is no longer only whether an API is reachable, but whether the calling identity, request pattern, and data exposure are all governed at runtime. That makes API security closer to identity governance than to traditional perimeter defence. For regulated organisations, the practical conclusion is that API telemetry, authorisation, and lifecycle controls need to be treated as one control plane.

Context is the named concept that separates detection from noise. Security teams need to know which API is being called, what it normally does, and whether the request matches expected business behaviour. Without that context, defenders cannot reliably distinguish legitimate change from malicious manipulation. The result is either missed abuse or overblocking that harms business operations. Practitioners should therefore build policy around service context, not only traffic volume.

Build-time and runtime controls must be joined, not sequenced. API programmes often fail when development teams see one toolset and security teams see another. That split creates blind spots between design, deployment, and active use, especially in partner ecosystems where APIs change quickly. In identity terms, the same governance gap appears when access is approved in one system and enforced in another. Practitioners should align policy, telemetry, and response across the full lifecycle.

Regulated ecosystems need data exposure mapping, not just endpoint inventories. Inventory tells you what exists, but exposure mapping tells you what can leak, who can reach it, and which controls must surround it. That distinction matters when banks, fintechs, and other third parties depend on the same API layer. The governance conclusion is straightforward: without endpoint-to-data visibility, compliance reporting and incident response will both lag behind the risk.

Identity controls now extend into API behaviour. Where APIs underpin customer journeys and partner integrations, access governance cannot stop at human users and service accounts. The organisation has to understand how API credentials, partner access, and behavioural anomalies interact. That does not make every API issue an IAM issue, but it does mean identity teams should be in the room when API security architecture is defined.

What this signals

Context-aware API governance is becoming a prerequisite for secure digital ecosystems. As services expose more data and more partner integrations, teams need policy that understands the difference between a valid request and a valid outcome. That is the same governance challenge that appears in NHI programmes, where credentials may be technically valid but operationally out of scope. Practitioners should expect API monitoring, identity governance, and data classification to converge more tightly over the next planning cycle.

API access is now part of the identity surface, not a separate security island. For many programmes, the most useful next step is to connect API telemetry to identity controls, especially where service accounts, tokens, and partner credentials are involved. This is where the Ultimate Guide to NHIs remains relevant: it frames how lifecycle, rotation, and visibility controls map to operational risk.

Detection will keep failing where exposure mapping is absent. The organisation may have tooling, but without knowing which endpoints expose which data, response teams will continue to triage symptoms rather than causes. That makes data classification and endpoint ownership the practical control investment, especially in regulated sectors where auditability and partner assurance matter as much as raw detection volume.

For practitioners

• Implement API discovery with data exposure mapping Create an inventory that links each API endpoint to the data classes it can read, write, or expose. Use that map to prioritise monitoring and compliance reporting for the highest-risk services.
• Correlate build-time findings with runtime behaviour Integrate API security findings into CI/CD so developers and security teams share the same policy model. Then compare live traffic against expected behaviour to spot account takeover and unusual request sequencing.
• Separate normal change from malicious deviation Define what approved API change looks like for each service, partner, and environment. This prevents teams from treating every anomaly as an attack while still surfacing deviations that represent abuse.
• Treat partner-facing APIs as governance boundaries Apply stricter logging, approval, and review to APIs used by banks, fintechs, and other external parties. These are the paths where business trust and attack exposure overlap most directly.
• Include identity teams in API policy design Bring IAM and security architecture together when deciding how API credentials are issued, monitored, and revoked. That keeps access governance aligned with how APIs are actually consumed in production.

Key takeaways

• API security now depends on context, because valid traffic can still be malicious when it targets business logic and sensitive data.
• The biggest operational gap is the split between discovery, build-time controls, and runtime monitoring, which leaves organisations blind between design and production.
• Security teams should align API governance with identity and data controls so partner access, service credentials, and sensitive exposure are managed as one system.

Key terms

• API security context: The surrounding business and technical information that explains what an API is supposed to do, who should use it, and what data it should expose. Context is what lets security teams separate legitimate traffic from suspicious behaviour when credentials and endpoints themselves look valid.
• API-Based Email Security: API-based email security integrates with the mail platform through application interfaces rather than sitting in front of traffic. This lets security teams inspect delivered messages, automate remediation, and connect email actions to mailbox and identity context in cloud-native environments.
• Build-time API security: Security checks applied before an API reaches production, usually during development, testing, and CI/CD pipelines. The purpose is to catch exposure, weak authentication, and unsafe design early, before live traffic or partner integrations turn those weaknesses into operational risk.
• Data exposure mapping: The practice of linking each API endpoint to the specific data it can return, modify, or reveal. It gives security and compliance teams a practical view of where sensitive information lives in the API layer and which controls must surround it.

What's in the full article

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

• Finastra’s API security evaluation criteria, including how the team decided what problem it needed to solve.
• The runtime and CI/CD integration patterns Salt described for supporting detection and response across the API lifecycle.
• The handling of sensitive data within the company’s own environment, including how the hybrid approach supports privacy requirements.
• The Q&A discussion on internal microservices, multi-cloud environments, and the relationship between API gateways and API security tools.

👉 Salt's full session covers the Finastra discussion, architecture choices, and workflow integration details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of real operational risk. It is designed for practitioners who need to connect identity controls to broader security architecture and governance.