Notifications
Clear all
Topic starter
02/08/2026 12:12 pm
TL;DR: As organisations deploy LLMs, autonomous agents and MCP servers, API pathways have become the practical attack surface for AI systems, and Salt Security argues that NIST AI RMF-aligned governance depends on securing those interfaces. The governance gap is no longer theoretical: visibility, posture control and runtime enforcement now determine whether AI risk can be measured and managed.
NHIMG editorial — based on content published by Salt: API posture governance for AI systems and the NIST AI RMF
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.
Questions worth separating out
Q: How should security teams govern AI agents that call APIs instead of using a UI?
A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login.
Q: Why do autonomous agents create more risk than traditional application accounts?
A: Autonomous agents create more risk because they can change scope while they are running.
Q: What breaks when API posture governance is missing in AI environments?
A: Visibility breaks first, then enforcement.
Practitioner guidance
- Inventory every AI-connected API Create and maintain a complete list of APIs used for training, inference, model orchestration and agent-tool communication.
- Enforce posture checks on delegated access paths Apply policy checks to authentication, authorization, token scope and data access for every AI-facing interface.
- Monitor for shadow APIs and anomalous agent behaviour Use discovery and runtime telemetry to detect unapproved API endpoints, unusual data requests and tool-use patterns that indicate policy drift.
What's in the full article
Salt's full analysis covers the operational detail this post intentionally leaves for the source:
- A deeper breakdown of API posture governance across discovery, policy enforcement and runtime protection for AI-connected services.
- Specific examples of how insecure APIs enable model extraction, prompt injection and sensitive data exposure in production environments.
- The article's mapping of API security capabilities to NIST AI RMF functions, including how each control supports GOVERN, MAP, MEASURE and MANAGE.
- Salt's recommended approach to securing the AI action layer across models, agents and MCP-connected servers.
👉 Read Salt's analysis of API posture governance for AI risk management →
API attack surface and AI risk governance: are controls keeping up?
Explore further
02/08/2026 1:15 pm
API governance is now a first-order AI security control, not an implementation detail. When LLMs, agents and MCP servers depend on APIs for data and action, the interface becomes the real control boundary. That means organisations cannot treat API security as separate from AI governance. The practical conclusion is that AI risk programmes must include inventory, posture enforcement and runtime monitoring for every connected API.
A question worth separating out:
Q: Who is accountable when an AI platform exposes data and behavioural controls through backend flaws?
A: Accountability sits with the teams that own application security, IAM, and the AI control plane together. If unauthenticated APIs, weak object controls, or writable prompts exist, the failure is governance as much as engineering. Organisations should assign explicit ownership for endpoint inventory, runtime policy, and privileged configuration protection.
👉 Read our full editorial: API attack surface is becoming the AI attack surface
