Notifications
Clear all
Topic starter
06/09/2026 5:18 pm
TL;DR: API security failures are now affecting most enterprises, with NIST SP 800-228 framing APIs as lifecycle assets that need discovery, authentication, schema validation, telemetry, and runtime enforcement, according to LEVO. The practical shift is from static guidance to continuous governance, because shadow APIs, broken access control, and weak authentication now create board-level risk.
NHIMG editorial — based on content published by LEVO: NIST API security guidance and runtime governance
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.
- 84 % of security professionals suffered an API incident despite having dedicated resources, showing that visibility alone does not equal control.
Questions worth separating out
Q: How should security teams implement API security in the software delivery lifecycle?
A: They should place controls where the risk is introduced.
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.
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.
Practitioner guidance
- 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.
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
👉 Read LEVO’s analysis of NIST SP 800-228 and API security governance →
NIST API security: are your controls keeping up at runtime?
Explore further
06/09/2026 5:19 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: NIST API security shifts from guidance to runtime governance
