Notifications
Clear all
Topic starter
02/08/2026 12:24 pm
TL;DR: API defence must combine continuous discovery, posture governance, and runtime threat protection because static, signature-led controls miss novel attack patterns, shadow APIs, and exposed sensitive data, according to Salt. The real issue is not just detection but whether organisations can govern the full API lifecycle before reconnaissance becomes data loss.
NHIMG editorial — based on content published by Salt: how API security compares across discovery, posture governance, and runtime protection
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Baseline normal API behaviour Profile request frequency, object access patterns, response sizes, and user or token context so reconnaissance stands out before exfiltration begins.
- 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.
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.
👉 Read Salt's analysis of API discovery, posture governance, and runtime threat protection →
API security governance gaps: are discovery and runtime enough?
Explore further
02/08/2026 1:23 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: API security fails when discovery, posture, and runtime are split
