NIST API security shifts from guidance to runtime governance

At a glance

What this is: NIST SP 800-228 frames API security as a full lifecycle control problem, with the central finding that discovery, authentication, authorization, and runtime enforcement must work together to stop shadow APIs and access abuse.

Why it matters: For IAM practitioners, the article matters because APIs are where human, service, and AI-driven access patterns converge, so identity governance, token control, and runtime policy now directly shape enterprise security outcomes.

By the numbers:

• 85 % of enterprises in the Asia-Pacific experienced an API-related incident in the previous year, at an average cost exceeding US$580,000.
• 97 % of AI-related breaches lacked proper API access controls, showing that weak API governance remains a major failure mode in AI deployments.
• The market for API security reached US$11.62 billion in 2025 and is projected to grow at 17.39 % CAGR through 2033.
• 84 % of security professionals suffered an API incident despite having dedicated resources, showing that visibility alone does not equal control.

👉 Read LEVO’s analysis of NIST SP 800-228 and API security governance

Context

APIs now sit on the critical path for modern enterprise identity and access, which means weak API governance can turn into credential abuse, authorization bypass, or uncontrolled data exposure. NIST SP 800-228 treats that problem as a lifecycle issue, not a point-in-time control, and the article argues that the same discipline is needed wherever service identities, user tokens, and machine-to-machine calls intersect.

For IAM and NHI programmes, the governance gap is familiar: teams often know how to secure the identity layer in theory, but they do not always maintain inventory, policy consistency, or runtime enforcement across every API path. That makes the subject especially relevant to organisations trying to align API security with [Ultimate Guide to NHIs](https://nhimg.org/the-ultimate-guide-to-non-human-identities), [Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs](https://nhimg.org/the-ultimate-guide-to-non-human-identities#lifecycle-processes-for-managing-nhis), and [Ultimate Guide to NHIs , Standards](https://nhimg.org/the-ultimate-guide-to-non-human-identities#standards).

Key questions

Q: How should security teams implement API security in the software delivery lifecycle?

A: They should place controls where the risk is introduced. Use design reviews for auth models and OAuth scopes, SAST and secrets detection during development, SCA at build time, DAST before release, and runtime monitoring in production. That sequence catches code-level flaws before attackers can exploit them and avoids relying on gateways to fix issues that already shipped.

Q: Why do weak API controls create such high risk for AI systems?

A: AI services depend on APIs to fetch data, trigger actions, and exchange context, so a weak token or missing authorization check can affect the whole decision chain. When API access is broad or poorly scoped, AI workflows can leak data, execute unauthorized actions, or inherit bad inputs at scale.

Q: What breaks when API inventories are incomplete?

A: When inventories are incomplete, teams cannot reliably know which APIs exist, what data they expose, or which identities and tokens can reach them. That breaks risk assessment, ownership, logging coverage, and incident scoping. The result is usually delayed remediation, hidden exposure, and inconsistent control enforcement across production services.

Q: Which frameworks map best to NIST-style API governance?

A: NIST Cybersecurity Framework 2.0, NIST SP 800-53, and the NIST AI risk guidance are the most relevant references when APIs support sensitive business processes or AI services. Teams should map inventory, access control, monitoring, and response expectations to those frameworks rather than treating API security as a standalone exercise.

Technical breakdown

API inventory and shadow API discovery

NIST SP 800-228 starts with the premise that you cannot secure what you cannot enumerate. An API inventory should capture ownership, schema, exposure, and security requirements so teams can distinguish sanctioned interfaces from shadow APIs created outside governance. In practice, inventory is not just documentation. It is the control surface that determines whether authentication, schema validation, logging, and retirement policies can be enforced consistently across design and runtime. Without a complete inventory, API security becomes reactive and incomplete.

Practical implication: maintain a living API inventory linked to ownership, schema, and exposure so security controls can be applied before deployment.

Authentication, authorization, and token governance

The guideline ties API security to zero-trust principles by requiring both the caller and the user identity to be verified. That means strong authentication, fine-grained authorization, and careful token handling are all part of the same control chain. OAuth and mutual TLS provide complementary assurance, while field-level authorization helps prevent overexposure even when the endpoint itself is valid. This is where API security overlaps directly with identity governance, because a valid token is only safe if its scope, lifetime, and downstream use are tightly controlled.

Practical implication: scope API tokens narrowly, enforce field-level authorization where needed, and validate service identities as rigorously as human identities.

Runtime enforcement, telemetry, and abuse detection

At runtime, NIST emphasises layered controls such as schema validation, rate limiting, throttling, logging, and behavioural inspection. These controls reduce the blast radius of malformed requests, scraping, denial-of-service attempts, and data exfiltration. The architecture matters too. Gateways, service meshes, sidecars, and egress controls each enforce policy at different points in the request path, and mature programmes combine them rather than relying on a single choke point. Continuous telemetry closes the loop by making abuse visible while it is still actionable.

Practical implication: push enforcement as close to the service as possible and pair it with telemetry that can detect anomalous request patterns early.

Threat narrative

Attacker objective: The attacker wants to exploit trusted API paths to reach sensitive data, privileged actions, or downstream systems without triggering effective detection or authorization controls.

1. Entry occurs through an exposed or undocumented API that was not captured in inventory, giving the attacker a path around governance controls.
2. Escalation follows when weak authentication, over-broad token scope, or missing field-level authorization lets the attacker expand from valid access to sensitive operations.
3. Impact arrives through data scraping, unauthorized modification, denial of service, or abuse of AI-connected API flows that expose regulated or business-critical data.

NHI Mgmt Group analysis

API security is now an identity governance problem, not just an application security problem. The article makes clear that APIs are where service identities, user identities, and AI-connected calls converge, which means token scope, lifecycle, and authorization boundaries are part of identity governance. If teams treat APIs only as code paths, they miss the control plane that actually governs who and what can act. Practitioners should align API security with IAM, PAM, and NHI governance rather than leaving it to isolated engineering teams.

Shadow API discovery is the named concept enterprises should track. An undiscovered API is not merely an inventory issue. It is a governance gap that prevents authentication, telemetry, and retirement controls from being applied at all. That makes discovery a prerequisite for NIST CSF-style identification and protection work, and it also mirrors the NHI lifecycle problem of unmanaged accounts and tokens. Practitioners should treat API discovery as a standing control, not a periodic project.

Runtime enforcement determines whether API policies are real or aspirational. The article’s emphasis on gateways, service meshes, sidecars, and egress controls reflects a broader market shift toward enforcement close to the workload. That matters because access policy that exists only in design documents does not stop scraping, injection, or field-level exfiltration in live systems. Practitioners should assume that any API without runtime policy is effectively outside governance.

AI systems inherit API security weakness immediately. The article’s AI breach data shows that API access control failures are now a core AI risk, not a side issue. AI services call APIs to retrieve data, trigger actions, and exchange context, so poor token governance or weak authorization can corrupt model-driven workflows as quickly as it can expose data. Practitioners should connect API security directly to AI governance and NHI controls for machine-to-machine access.

NIST SP 800-228 is best read as an operating model for continuous control, not a compliance checklist. The lifecycle view matters because APIs evolve faster than static reviews, and the article’s own remediation examples show that discovery, validation, and telemetry only work when they are maintained continuously. Practitioners should use the framework to harden control ownership, measurement, and escalation paths across the full API estate.

What this signals

Shadow API discovery will become a board-relevant control as AI and microservices expand the number of machine-to-machine trust paths. The practical issue is not just exposure, but whether teams can prove that every reachable interface has an owner, policy, and monitoring path. For identity teams, that makes API governance a sibling problem to NHI lifecycle management rather than a separate engineering concern.

API access control is now part of AI risk management, and weak token scope will keep surfacing in breach analysis. The same access path that lets a service function also lets it leak data, so AI governance and API governance will increasingly be judged together. Teams should anchor policy to NIST AI guidance and to identity-centric controls that limit privilege at the point of use.

Runtime policy, not documentation, will define whether an API estate is actually governable. The organisations that mature fastest will be the ones that can enforce policy close to the workload and then measure whether blocked requests, schema violations, and anomalous traffic are trending down. That is the difference between control design and control evidence.

For practitioners

• Build a continuously updated API inventory Track every API with owner, schema, exposure level, and security requirement so governance can be enforced before deployment and revisited at runtime.
• Tighten token scope and field-level authorization Limit API tokens to the smallest workable scope and apply field-level controls for sensitive responses, especially where service identities and user identities intersect.
• Deploy layered runtime enforcement Combine gateways, service meshes, sidecars, and egress controls so policy is enforced as close as possible to each service instance rather than only at a central choke point.
• Instrument telemetry for abuse detection Log caller identity, blocked requests, schema violations, and unusual request volumes so teams can detect scraping, misuse, and shadow API activity quickly.
• Map API governance to identity controls Treat API access as an IAM and NHI problem by aligning credential scope, rotation, and offboarding with the lifecycle of the API and the workload that calls it.

Key takeaways

• API security has become a lifecycle governance issue because inventories, identities, and runtime controls all have to work together.
• The evidence shows that weak API access control is already driving breaches in both enterprise and AI environments.
• Practitioners should connect API discovery, token governance, and runtime enforcement to identity and NHI control models.

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.
• Field-Level Authorization: An access control approach that checks permission at the individual field rather than only at the object or endpoint level. In GraphQL, this is critical because different fields can expose different sensitivity levels, and a user may be allowed to see one field but not another.
• API Inventory: An API inventory is the authoritative record of what interfaces exist, who owns them, what data they touch, and how they are authenticated. For identity governance, it is the baseline control that makes review, monitoring, offboarding, and risk prioritisation possible across distributed services.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.

What's in the full article

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

• NIST SP 800-228 lifecycle control examples for design, build, deployment, runtime, and retirement stages
• Operational guidance on when to use gateways, service meshes, sidecars, and egress controls
• Specific runtime enforcement patterns for authentication, schema validation, throttling, and logging
• Discussion of how API security maps to GDPR, ISO 27001, PCI DSS, and federal control environments

👉 LEVO’s full article expands the control model, runtime architecture, and compliance mapping for API security.

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 paths that modern API-driven environments depend on.