Notifications
Clear all
Topic starter
02/08/2026 11:33 am
TL;DR: Security leaders should treat exposed APIs, MCP servers, and weakly governed internal services as the real AI attack surface, because AI agents create damage by taking actions, not only by generating text, according to Salt. The governance gap is no longer model safety alone but action-layer control over what agents can reach, call, and chain.
NHIMG editorial — based on content published by Salt: AI security risk is shifting from model safety to the action layer
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: What breaks when AI agents can reach exposed internal APIs?
A: The break point is governance, not just security tooling.
Q: Why do AI agents complicate traditional IAM and PAM controls?
A: AI agents complicate IAM and PAM because they can make decisions, chain tools, and act faster than human review cycles can respond.
Q: What do security teams get wrong about AI access risk?
A: Many teams focus on the model while ignoring the identity path that reaches it.
Practitioner guidance
- Inventory every AI-reachable API Build a complete list of APIs, internal services, and MCP servers that any agent, copilot, or automation workflow can reach.
- Scope agent permissions to named tasks Require each agent to operate with task-scoped access, not broad service permissions.
- Remove unauthenticated or weakly governed interfaces Prioritise exposed endpoints that accept requests without strong authentication, rate limiting, or policy enforcement.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- A vendor walkthrough of exposed API discovery for AI-connected services and internet-reachable endpoints.
- A deeper explanation of the McKinsey and McDonald’s incident patterns as application-layer failures, not model-layer failures.
- Operational guidance on where Salt Surface fits in exposure mapping for AI-related workflows.
- The article's own framing of how organisations should assess action-layer blast radius in live environments.
👉 Read Salt's analysis of AI agents, exposed APIs, and the action-layer attack surface →
Exposed APIs and AI agents: is your action layer secure?
Explore further
02/08/2026 12:47 pm
AI security has shifted from prompt safety to action governance. The central mistake in many enterprise programmes is treating the model as the primary risk object. In practice, the material control point is the connected action layer, where AI systems call tools, invoke APIs, and inherit privileges. That moves the problem into IAM, PAM, and NHI governance territory because the real question is who or what is authorised to act. Practitioners should now measure AI risk by reachable actions, not only by model output quality.
A question worth separating out:
Q: How should teams govern AI agents that use MCP?
A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.
👉 Read our full editorial: AI security risk is shifting from models to exposed action layers
