API security governance is shifting from visibility to policy enforcement

At a glance

What this is: Salt argues that API security governance is moving beyond visibility and toward policy enforcement because organisations still underestimate API sprawl and struggle to control posture across the lifecycle.

Why it matters: For IAM and security teams, the shift matters because API governance increasingly depends on enforceable access boundaries, not inventory alone, especially where APIs expose sensitive data and services.

By the numbers:

• According to Salt, there was a 400% increase in unique API attackers in the last year.

Context

API security is not just about finding every API. It is about governing how APIs are allowed to behave, who or what can call them, and whether their posture stays within policy as environments change. In modern application stacks, API sprawl is often wider than teams realise, which creates a governance gap between discovery and control.

That gap matters because APIs often expose high-value data and services through machine-to-machine pathways that are easy to overlook in traditional security programmes. In identity terms, the issue intersects with access boundaries, service authentication, and policy enforcement across the API lifecycle rather than at a single perimeter checkpoint.

Key questions

Q: When do API security controls fail in practice?

A: They fail when authentication is weak, scopes are too broad, endpoints are exposed without validation, or secrets are copied into too many places to revoke quickly. In that state, even a small leak can become durable access. The real test is whether one compromised credential can be invalidated before it is reused elsewhere.

Q: Why do APIs create so much risk in modern web applications?

A: APIs often carry the real business logic of an application, including data access, account actions, and administrative functions. If they are over-permissioned or weakly authenticated, attackers can bypass the browser layer entirely and act directly against sensitive services. That makes API authorisation a core governance control, not a backend detail.

Q: What are the signs that an API control program is failing in practice?

A: Common warning signs include spikes in 403 responses, bursts of schema violations, sequential ID access, repeated webhook IDs, and tokens reused across services. Those patterns usually mean authorization is weak, contract enforcement is drifting, or replay protection is incomplete. Teams should correlate runtime signals with negative tests and owner metadata to find the broken control quickly.

Q: How should organisations govern APIs that expose sensitive data?

A: They should treat those APIs as controlled access surfaces, not just technical endpoints. That means defining policy for exposure, authentication, and acceptable behaviour, then verifying that runtime activity stays within those bounds. Governance should align to the business value of the data and the identities allowed to reach it.

Technical breakdown

Why API visibility does not equal governance

API discovery tells you what exists, but it does not tell you whether the API is allowed to exist in that state. In practice, teams can inventory endpoints, yet still miss exposure created by weak authentication, permissive access, inconsistent versioning, or drift between intended and actual behaviour. Governance requires policy evaluation against the live API estate, not periodic counting. That is why posture management becomes a control layer, not a reporting layer: it codifies what acceptable API exposure looks like and checks whether reality matches that standard.

Practical implication: treat API discovery as an input to enforcement, not as evidence that risk is controlled.

How API posture governance changes the control model

An API posture governance engine moves the question from ‘what do we have?’ to ‘what is allowed?’ That means policies can be written around external requirements, internal standards, and operational expectations, then evaluated continuously against API behaviour and configuration. This is materially different from passive visibility because it introduces a governing rule set that can surface misalignment before it becomes exploitability. In an IAM-adjacent sense, it is closer to authorization governance than asset discovery, because it defines acceptable access and usage conditions for machine-facing interfaces.

Practical implication: define policy conditions for API exposure, authentication, and behavioural boundaries before you rely on monitoring.

Why behavioural analytics matter for API abuse detection

API attacks often blend into normal application traffic because the attacker is abusing valid pathways rather than breaking in through obvious malware or noisy intrusion techniques. Behavioural analytics help identify low-and-slow abuse, unusual call patterns, and anomalous sequences that inventory tools will never surface on their own. The key point is that API security needs both visibility and interpretation: knowing that an API exists is not enough if defenders cannot tell when its usage has drifted outside intended behaviour. That is especially important where APIs underpin customer data, partner integrations, and internal service communication.

Practical implication: pair posture controls with behavioural detection so you can catch abuse that looks legitimate at the transport layer.

Threat narrative

Attacker objective: The attacker wants to use legitimate-looking API access to reach sensitive information or business functions without triggering strong defensive signals.

1. Entry begins when attackers target exposed APIs embedded in modern microservices and distributed application stacks.
2. Credential or authentication weaknesses let them use valid API paths to query or manipulate sensitive data without needing traditional endpoint compromise.
3. Abuse escalates through repeated low-and-slow requests or poorly governed access paths, allowing attackers to stay below basic detection thresholds.
4. The impact is unauthorized access, data theft, or broader abuse of business-critical API workflows.

NHI Mgmt Group analysis

API governance is now an authorization problem, not an inventory problem. The central failure in many API security programmes is assuming that knowing an API exists means the organisation understands what it is allowed to do. In reality, exposure, behaviour, and policy drift evolve faster than periodic review cycles. Practitioners should treat API policy enforcement as a live control plane, not a compliance afterthought.

API sprawl creates a governance gap that traditional security stacks do not close. Microservices and distributed architectures expand the number of machine-facing entry points faster than teams can manually classify them. That makes posture enforcement, behavioural baselining, and access boundary definition more important than static discovery reports. The practical conclusion is that teams need controls that operate at the same speed as API change.

API security is increasingly an identity-adjacent discipline. The article’s real signal is that API protection now depends on how services authenticate, authorise, and consume policy across machine-to-machine pathways. That puts API governance close to IAM, even when the primary asset is not a human user account. The practitioner takeaway is to align API controls with identity policy, not treat them as separate worlds.

Low-and-slow API abuse is a governance blind spot. Attackers do not need to break the interface if they can operate within normal traffic shapes and exploit weak policy boundaries. This is why posture enforcement and behavioural detection have to work together. Practitioners should assume that legitimate-looking API activity may still be malicious until policy and context prove otherwise.

What this signals

API posture governance: this article’s clearest signal is that API security is moving from asset discovery to policy enforcement. Practitioners should expect greater pressure to prove not just that APIs are visible, but that their exposure, authentication, and behavioural boundaries are enforceable in practice.

For identity and security teams, the practical consequence is convergence. API callers, service identities, and authorization policy can no longer be managed as separate concerns when the attack path runs through machine-to-machine access and business workflows.

For practitioners

• Define enforceable API posture policies Write policy for authentication strength, allowed exposure, versioning, and approved business usage so the control can be checked continuously rather than reviewed manually.
• Tie API governance to IAM policy Map API callers, service identities, and access boundaries to existing identity and authorization rules so machine-to-machine access is governed consistently.
• Baseline API behaviour by workflow Establish normal call sequences, volumes, and data access patterns for critical APIs so low-and-slow abuse can be distinguished from legitimate service traffic.
• Review API exposure against business criticality Prioritise the APIs that reach sensitive data or regulated workflows, then verify whether their actual posture matches the policy the organisation expects.

Key takeaways

• API security now breaks when organisations mistake visibility for governance, because inventory does not enforce policy.
• The most material risk is not just that APIs exist, but that attackers can abuse legitimate paths and low-and-slow traffic patterns.
• Teams should align API posture, behavioural detection, and identity policy so access boundaries are enforced at runtime.

Key terms

• API posture governance: API posture governance is the ongoing discipline of defining, measuring, and enforcing how APIs are exposed, secured, and used across an organization. It covers authentication, authorization, inventory, schema control, rate limits, logging, versioning, and risk review, so APIs remain discoverable, least-privileged, and aligned with security and compliance requirements.
• API sprawl: API sprawl is the uncontrolled growth of application programming interfaces across systems, teams, and environments. It creates duplicated endpoints, inconsistent authentication, weak ownership, and hidden data exposure. In security terms, API sprawl expands the attack surface, complicates inventory and governance, and makes policy enforcement, monitoring, and lifecycle control harder to sustain.
• Low And Slow API Attack: A low and slow API attack is a stealthy abuse pattern that spreads malicious activity over an extended period instead of creating a burst of traffic. The attacker uses small, repeated requests to stay beneath normal detection thresholds while gradually probing weaknesses or extracting data from APIs.
• Machine-to-Machine Access: Machine-to-machine access is communication where one software system or workflow reaches another without a human session in the middle. It is governed by credentials, policy, and trust boundaries, and it becomes risky when the access path is broad, poorly logged, or hard to revoke.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader access problems that modern API programmes inherit.