API security fails when discovery, posture, and runtime are split

At a glance

What this is: This is a Salt Security blog post arguing that API security needs discovery, posture governance, and runtime threat protection to stop reconnaissance, compliance gaps, and service disruption.

Why it matters: It matters to IAM and security practitioners because APIs often expose identity, authorisation, and data access paths that become unmanaged attack surfaces when discovery, controls, and response are disconnected.

👉 Read Salt's analysis of API discovery, posture governance, and runtime threat protection

Context

APIs have become a primary control surface for modern digital services, but they are also a governance problem when inventory, policy enforcement, and monitoring do not move together. In practice, teams often protect the known APIs they can see while missing shadow, deprecated, or poorly documented interfaces that still carry sensitive data and access paths. That is where API security intersects with identity governance, because every API call reflects an authorisation decision, a trust boundary, or a delegated access path that must be controlled.

The article’s core argument is that runtime defence alone is not enough. A programme that cannot continuously discover APIs, classify what they expose, and connect findings to remediation will struggle to reduce risk, especially where APIs bridge human users, service accounts, third-party integrations, and automated workflows. This is typical of mature API environments rather than an edge case.

Key questions

Q: How should security teams govern API access for AI agents and service accounts?

A: Security teams should treat API access as a governed identity path, not a transport detail. That means assigning ownership to each machine consumer, limiting scopes to specific tasks, enforcing token binding where possible, and maintaining audit logs that tie every call to an identity and policy decision.

Q: Why do shadow APIs create such a large security gap?

A: Shadow APIs bypass ownership, policy enforcement, and change control, so defenders cannot reliably classify the data they expose or the identities that can reach them. That makes them ideal for reconnaissance and data extraction. If an API is not in the live inventory, it is effectively outside governance.

Q: How can security teams tell whether API risk controls are actually working?

A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why. If the control is effective, suspicious traffic should be slowed, challenged, or blocked before it reaches core systems, while legitimate integrations continue to function normally.

Q: Who is accountable when API access controls fail?

A: Accountability should sit with the team that owns the API lifecycle, including design, deployment, access scope, and retirement. Security may set policy, but engineering and product owners must own the data and behaviour exposed by each interface. Without explicit ownership, APIs tend to outlive their controls and inherit stale permissions.

Technical breakdown

Continuous API discovery and shadow API inventory

API security starts with knowing what exists. Continuous discovery means observing traffic, code paths, and configuration signals to build an inventory of live endpoints, including shadow APIs and deprecated interfaces that are still reachable. This matters because static inventories drift quickly in agile and cloud-native environments. If the security team only protects documented services, attackers can pivot through forgotten endpoints that still accept tokens, session data, or machine-to-machine requests. Discovery is therefore a control function, not just a reporting exercise. It establishes the scope for classification, monitoring, and policy enforcement.

Practical implication: maintain a live API inventory and tie every newly observed endpoint to an owner, data classification, and access policy.

Behavioural threat detection in API traffic

Behavioural detection looks at request patterns, response content, and session context rather than relying on known signatures alone. That is important because API attackers often begin with reconnaissance, enumerate objects, probe parameters, and gradually escalate to data extraction without tripping traditional rule sets. Two-way inspection helps identify anomalies such as unusual access sequences, token misuse, or high-volume enumeration across endpoints. The value is not just alerting, but separating normal application behaviour from automated abuse and account takeover patterns. In identity terms, this is where API authorisation telemetry becomes evidence of trust abuse.

Practical implication: use behavioural baselines and response-aware analytics to detect reconnaissance and token abuse before large-scale exfiltration begins.

API posture governance across the full lifecycle

Posture governance means checking APIs for exposure, policy drift, weak authentication assumptions, and leaked sensitive data from development through production. The article is right to frame lifecycle coverage as a security issue, because many failures originate before runtime, where undocumented endpoints, overexposed data fields, or weak controls enter the environment. For IAM teams, the closest parallel is identity lifecycle governance: if an API or integration is not continuously governed, it becomes a standing trust relationship that outlives its intended use. That creates compliance, resilience, and privilege-management problems at the same time.

Practical implication: embed API security checks into build, deploy, and change workflows so posture gaps are caught before they become persistent exposure.

Threat narrative

Attacker objective: The attacker wants to find an ungoverned API path that provides data access, account abuse, or operational disruption without triggering conventional perimeter controls.

1. Entry typically begins with reconnaissance against exposed or poorly inventoried APIs, especially shadow or deprecated endpoints that still respond to requests.
2. Escalation follows when the attacker abuses weakly governed tokens, overexposed parameters, or undocumented trust relationships to enumerate data or actions.
3. Impact occurs when the attacker exfiltrates sensitive data or disrupts services before defenders can correlate the behaviour across the API estate.

NHI Mgmt Group analysis

API security becomes an identity governance problem the moment tokens, service accounts, and delegated access cross application boundaries. The article focuses on traffic inspection and posture, but the deeper issue is who or what is allowed to invoke which API and for how long. If access is not continuously governed, APIs become durable trust channels that outlive the business intent behind them. Practitioners should treat API inventory and authorisation control as part of IAM, not just application security.

Continuous discovery is the named control gap this article exposes. Shadow and deprecated APIs are not merely visibility issues, they are governance failures because they bypass ownership, review, and policy enforcement. Once an endpoint exists outside the live inventory, neither compliance reporting nor runtime analytics can fully compensate. Teams should operationalise discovery as a control plane, not a dashboard.

Static rules cannot carry modern API defence on their own. The article correctly contrasts behaviour-based analysis with signature detection because API abuse often looks like normal application traffic until the final stages of extraction. That means detection engineering must focus on sequences, not isolated events, and on trust abuse rather than only malicious payloads. Practitioners should align API telemetry with identity signals so anomalous access can be interpreted in context.

API lifecycle governance is increasingly part of broader Zero Trust architecture. If every API call is a policy decision, then continuous verification must extend to machine-to-machine interactions, third-party integrations, and automated workflows. This is where NIST Cybersecurity Framework 2.0 and NIST SP 800-53 style access and monitoring controls intersect with application security. Organisations should govern APIs as living access paths, not static technical endpoints.

The market is moving toward unified visibility, policy, and runtime response because fragmented tooling leaves blind spots between teams. Security leaders should expect API programmes to be measured less by the number of scanned endpoints and more by whether unknown endpoints, sensitive data exposure, and response workflows are linked end to end. That shift favours governance maturity over point detection. Practitioners should evaluate whether their current operating model can actually close the loop.

What this signals

API security programmes are increasingly constrained by the same visibility problem that affects NHI governance. If service accounts, tokens, and integrations are not tracked as identities, discovery tools can identify endpoints without clarifying who can legitimately use them. That creates a governance gap that neither posture dashboards nor runtime alerts close on their own. Practitioners should expect API risk reviews to merge application telemetry with identity ownership and entitlement data.

Continuous discovery is the practical dividing line between managed and unmanaged API risk. Once teams know which endpoints exist and which identities can reach them, they can apply policy, logging, and response consistently. Where that inventory is stale, the programme becomes reactive and compliance reporting turns into retrospective archaeology. Linking inventory to the NIST Cybersecurity Framework 2.0 helps structure the work across govern, identify, protect, detect, respond, and recover.

API lifecycle control should be treated as a precursor to broader trust architecture decisions. The same patterns that govern secrets, offboarding, and third-party access in NHI programmes now apply to APIs that mediate critical business flows. That means security leaders should not measure success only by blocked attacks, but by whether unknown interfaces, unmanaged tokens, and response latency are shrinking over time.

For practitioners

• Build a live API inventory Continuously discover APIs across production, shadow, and deprecated surfaces, then assign an owner, data classification, and authentication method to each endpoint. Use the inventory to drive review, not just reporting. The live API inventory should be reconciled with change management every release cycle.
• Baseline normal API behaviour Profile request frequency, object access patterns, response sizes, and user or token context so reconnaissance stands out before exfiltration begins. Feed anomalies into detection workflows that include identity context for service accounts and third-party tokens.
• Embed posture checks in delivery pipelines Scan for exposed sensitive data, weak auth assumptions, and undocumented endpoints during build and deploy stages rather than waiting for runtime alerts. Tie failures to release gates so posture drift is prevented before it reaches production.
• Align API governance with IAM controls Treat API tokens, service accounts, and integration credentials as governed identities with explicit ownership, rotation, and revocation triggers. Where APIs connect third parties or automation, require periodic entitlement review and offboarding evidence.
• Test incident response for API abuse Run scenarios for credential misuse, enumeration, and data scraping so response teams know how to isolate endpoints, revoke tokens, and preserve evidence without breaking dependent services. The response plan should include both technical containment and business-service triage.

Key takeaways

• API security breaks down when discovery, posture, and runtime protection are managed as separate problems.
• Unowned endpoints, unmanaged tokens, and static detection create the governance gaps attackers exploit for reconnaissance and data theft.
• Security teams should treat API inventory and identity governance as one operating model, not parallel programmes.

Key terms

• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• API Posture Governance: API posture governance is the continuous assessment of API exposure, authentication assumptions, and sensitive data handling across the lifecycle. It extends beyond runtime monitoring by checking whether the API is still intended, owned, and correctly protected as the service changes.
• Behavioural API Detection: Behavioural API detection identifies abuse by analysing request sequences, response patterns, and session context instead of relying only on signatures. It is used to spot reconnaissance, token misuse, and data scraping that may look normal until the attacker reaches the extraction phase.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

What's in the full article

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

• Real-time API traffic analysis methods for detecting abnormal request and response patterns.
• Compliance reporting outputs for API usage, vulnerabilities, and remediation evidence.
• Lifecycle coverage for discovery, posture governance, and runtime threat protection across APIs.
• Deployment considerations for integrating API security into existing SOC workflows.

👉 Salt's full post covers the API traffic analysis, compliance reporting, and operational response detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It gives security and IAM practitioners a practical way to connect identity governance to the broader security programmes they already run.