Notifications
Clear all
Topic starter
02/08/2026 11:59 am
TL;DR: Enterprises that leave API security inside engineering workflows often miss shadow endpoints, direct-to-origin paths, and behavioural attacks that look legitimate in logs, according to Salt. The governance problem is not tooling volume but visibility, because WAFs and SIEMs rarely expose business-logic abuse or agent-like enumeration patterns.
NHIMG editorial — based on content published by Salt: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- 45% of organisations., tation is cited as the top cause of NHI-related attacks by 45% of organisations.
Questions worth separating out
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.
Q: Why do WAF and SIEM controls miss business logic abuse?
A: Because they are built to detect malformed requests, known signatures, and correlated events, not to understand whether a valid request reflects legitimate intent.
Q: What do security teams get wrong about shadow API endpoints?
A: They assume the gateway is the source of truth, when in fact it only sees routed traffic.
Practitioner guidance
- Build a continuous API discovery layer Correlate gateway telemetry with direct-to-origin traffic, service meshes, and application logs so the inventory includes shadow endpoints and legacy versions, not just routed calls.
- Add behavioural detection for object abuse Detect low-and-slow enumeration, ID sequencing, and repeated object access that stays inside normal request formats but violates expected user intent.
- Treat API consumers as governed identities Assign ownership, access scope, and lifecycle rules to service accounts, tokens, and agent-driven workloads so API access is reviewed like any other privileged pathway.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- How the customer built a real-time API inventory that included endpoints the gateway missed
- How the SOC used behavioural context to distinguish legitimate usage from low-and-slow abuse
- How the CrowdStrike Falcon integration changed analyst workflow and response coordination
- How the same control model can be extended to agentic AI and MCP-connected traffic
👉 Read Salt's analysis of API security blind spots and agentic AI exposure →
API security blind spots: what SOC and engineering teams miss?
Explore further
02/08/2026 1:06 pm
API inventory drift is a governance failure, not just an engineering inconvenience. If the SOC cannot maintain a live map of the API estate, it cannot enforce ownership, review access paths, or prove coverage. Shadow endpoints and direct-to-origin routes become invisible privilege surfaces. That is where identity governance starts to break down, because the organisation no longer knows what non-human identities are reaching which services. The practitioner conclusion is simple: governance needs continuous discovery, not periodic reconciliation.
A question worth separating out:
Q: Who is accountable when an API exposes administrative functions to the wrong user?
A: Application owners, platform teams, and security teams all share accountability because the failure sits in business logic, deployment patterns, and control validation. Frameworks such as the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls expect access decisions to be enforced consistently, not assumed from request validity.
👉 Read our full editorial: API security silos are creating blind spots for SOC teams
