API security governance is shifting from visibility to policy enforcement

At a glance

What this is: This is Salt Security’s view on why API security remains a large and under-governed problem as API estates expand and AI intensifies attacker tactics.

Why it matters: It matters to IAM and security teams because APIs often sit on top of identity, authorization, and secrets controls, so weak governance can expose human and non-human access paths alike.

By the numbers:

• According to the State of API Security Report Q1 2023, there was a 400% increase in unique API attackers last year.
• Companies sometimes underestimate the number of APIs they have by a factor of 10 or 100, according to Salt Security.

👉 Read Salt Security's analysis of API security governance, AI risk, and posture management

Context

API security becomes a governance problem once teams can no longer reliably see what exists, who can reach it, and what each endpoint is allowed to do. That gap is especially relevant to identity programmes because APIs depend on credentials, tokens, service accounts, and policy decisions that are often treated as implementation details rather than control points. The first order issue is API sprawl, but the deeper issue is that access control and posture management are usually fragmented across teams.

Salt Security’s article argues that awareness and education still lag the speed of API adoption, which is why organisations continue to underestimate risk and misjudge exposure. The identity angle is straightforward: APIs are part of the control plane for both human and non-human access, and weak API governance expands the blast radius of compromised secrets, over-privileged integrations, and opaque third-party connections.

Key questions

Q: How should security teams govern API access across humans, services, and agents?

A: Security teams should govern API access by identity type, caller context, and action scope, not by whether the API is internal or protected by a gateway. Human users, service accounts, partner applications, and automated agents need different policy treatment because they create different trust and revocation problems. The control objective is to make each API call answerable at runtime.

Q: Why do APIs become high-risk when organisations scale quickly?

A: APIs become high-risk because scale increases the number of hidden trust relationships. Each new integration can introduce tokens, service accounts, partner access, and data exposure paths that are hard to track. If teams cannot see those relationships clearly, they cannot enforce least privilege or remove stale access before it is abused.

Q: What do teams get wrong about API discovery and monitoring?

A: Teams often treat discovery as a one-time project, but shadow APIs appear through rapid releases, SaaS integrations, and forgotten code paths. Monitoring must be continuous and connected to ownership workflows, otherwise a discovered API can stay exposed long after the finding is logged. The control objective is persistence of visibility, not a single scan result.

Q: Who is accountable when API posture drifts from policy?

A: Accountability should sit with the business owner of the API, the security team enforcing policy, and the platform team operating the control. If those roles are unclear, posture drift becomes nobody’s problem until an incident forces attention. Clear ownership and review cadences are the difference between managed risk and inherited risk.

Technical breakdown

Why API sprawl creates governance blind spots

APIs are hard to govern because they are not always visible as discrete assets in the way endpoints or servers are. They proliferate through microservices, app modernisation, partner integrations, and internal automation, which means inventory alone is never enough. Security teams need to understand API purpose, exposure, authentication method, and data access path. When those controls live in separate platforms or teams, organisations lose the ability to answer basic questions about what is reachable, who is using it, and whether the current policy matches the business need.

Practical implication: build authoritative API inventory and ownership mapping before trying to enforce posture or access policy.

How attackers abuse API authentication and authorisation paths

API abuse usually works because the API is trusted too broadly or the authentication pattern is weakly governed. Attackers target valid tokens, over-permissioned service accounts, exposed endpoints, or business logic that allows actions beyond intended scope. In identity terms, APIs often become the enforcement point for machine-to-machine access, so flaws in token handling, scope design, or secret exposure become direct paths to data access. That is why API security cannot be separated from IAM, PAM, and secrets governance.

Practical implication: review API authentication scopes, token lifetimes, and service account privileges as part of identity control assurance.

What API posture governance changes operationally

API posture governance moves the conversation from discovery to policy. Instead of only detecting an API or scanning it for known issues, the control model compares actual API configuration and behaviour against approved policy, baseline requirements, and compliance rules. That includes authentication settings, exposure, data handling, and lifecycle state. This matters because many API risks are not classic vulnerabilities but misaligned governance choices that leave endpoints exposed or over-trusted for too long.

Practical implication: use policy-based checks to continuously assess API posture against internal standards and external obligations.

Threat narrative

Attacker objective: The attacker wants to exploit trusted API access paths to reach sensitive data or business logic without triggering obvious endpoint-focused controls.

1. Entry often begins through exposed or poorly inventoried APIs that attackers can identify faster than teams can classify them.
2. Escalation happens when weak authentication, overscoped tokens, or privileged integrations allow actions beyond intended access.
3. Impact follows when attackers use API trust paths to extract data, manipulate business logic, or move deeper into connected systems.

NHI Mgmt Group analysis

API posture governance is becoming a control-plane issue, not a point-solution feature. Once organisations have thousands of APIs, manual review cannot keep pace with change, and that creates a governance gap between what policy says and what production actually permits. The relevant discipline is no longer only detection, but continuous comparison of exposure, authentication, and data access against approved intent. Practitioners should treat API posture as part of core security governance.

API trust boundaries mirror NHI risk, even when the article does not use that language. APIs are commonly consumed by service accounts, tokens, and automation workflows, which means an API decision often becomes an NHI decision in practice. That makes API governance adjacent to secrets management, lifecycle control, and least privilege, especially where third-party integrations are involved. Security teams should align API governance with identity governance rather than isolating it in the application layer.

Posture visibility without lifecycle control creates a false sense of assurance. Discovery tells you that an API exists, but it does not tell you whether the endpoint is still needed, whether the token behind it has been rotated, or whether the business owner still understands its access scope. The gap is operational, not theoretical. Practitioners should connect API inventories to ownership, review, and decommissioning workflows.

Low-and-slow API abuse is a policy failure before it is a detection failure. If an API can be queried repeatedly under legitimate credentials, security tools may see normal traffic until the damage is already underway. That is why rate of change, privilege scope, and approved business context matter as much as telemetry. Teams should design controls that reduce trust before they rely on alerting to catch misuse.

Named concept: API governance debt. This is the accumulated gap between the number of APIs in production and the organisation’s ability to inventory, classify, policy-check, and retire them. It grows every time teams ship new integrations without lifecycle ownership or consistent posture review. The practical consequence is that security effort gets trapped in remediation while exposure keeps expanding.

What this signals

API security programmes are moving toward continuous policy enforcement because discovery alone cannot keep pace with integration sprawl. For teams that manage identity-heavy environments, the real issue is not just API exposure but the credential, token, and service-account paths attached to that exposure. The control model needs to unify inventory, privilege, and posture review before operational trust outstrips governance.

API governance debt: as API counts rise faster than lifecycle controls, organisations accumulate invisible trust relationships that are expensive to unwind. That debt shows up in stale integrations, over-scoped tokens, and incomplete decommissioning. Teams should expect API governance to become a cross-functional programme spanning IAM, application security, and platform engineering.

For practitioners, the signal is that API security is no longer a specialist niche. It is increasingly part of the broader identity control stack, and that means access reviews, secrets rotation, and third-party oversight now matter at the API layer as much as they do in IAM. The programmes that align those controls will have fewer blind spots and faster remediation.

For practitioners

• Establish an authoritative API inventory Create a single source of truth for API ownership, authentication model, data sensitivity, and production status. Include internal, partner, and shadow APIs so policy can be enforced against a complete estate.
• Tie API policy to identity controls Map each API to the service accounts, tokens, and secrets that can reach it, then review scope, lifetime, and privilege as part of identity governance. This is where many hidden access paths are created.
• Continuously compare posture to policy Use posture checks to verify authentication settings, exposure, and data handling against approved baseline rules. Treat exceptions as lifecycle items with owners and expiry, not one-time findings.
• Retire unused APIs and stale integrations Build a decommissioning workflow that removes inactive endpoints, revokes associated credentials, and confirms downstream dependencies are updated. That limits attack surface and reduces latent trust.

Key takeaways

• API security is becoming a governance challenge because organisations often cannot see, classify, or retire their API estate with confidence.
• Identity controls matter here because APIs are frequently mediated by tokens, service accounts, and secrets that expand the blast radius of weak policy.
• The practical response is continuous API posture enforcement tied to inventory, ownership, and lifecycle control, not discovery alone.

Key terms

• API Posture Governance: API posture governance is the practice of continuously checking API configuration, exposure, authentication, and data handling against approved policy. It goes beyond discovery by asking whether each API is still needed, correctly controlled, and aligned to security and compliance requirements.
• API-first governance: API-first governance is the practice of enforcing access and control decisions at the programmatic interface rather than relying on what a user can see or click. In a SOC, that means permissions, approval gates, and logs must be attached to the action path the agent actually uses.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.

What's in the full article

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

• How Salt frames API posture governance in terms of policy authoring, assessment, and compliance checks
• The company’s specific examples of how its API security lifecycle messaging maps to customer use cases
• Its discussion of AI-assisted API attack detection and the operational claims behind that approach
• The investor and partner context Salt uses to position its market trajectory

👉 Salt Security's full post covers API attack trends, posture governance, and the company’s view of market maturity

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It gives practitioners a structured way to connect identity controls to the broader security programmes they run.