Notifications
Clear all
Topic starter
02/08/2026 12:11 pm
TL;DR: APIs, AI agents, and MCP servers converged in 2025 to create a broader attack surface, with visibility gaps, shadow APIs, and agent misuse driving new security priorities according to Salt Security. The governance problem is no longer model risk alone: security teams now have to control actions, access, and context across the API layer.
NHIMG editorial — based on content published by Salt: 12 Months of Innovation: 2025 in Review and the Road to 2026
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 APIs create a larger identity risk surface in AI-enabled environments?
A: APIs become the execution boundary for software agents, workflow automation, and backend services, so any overbroad token can reach multiple systems.
Q: What breaks when shadow APIs are not inventoried and owned?
A: When shadow APIs are not inventoried and owned, security teams lose the ability to prove who exposed them, which identities can reach them, and whether logs exist for investigation.
Practitioner guidance
- Map API action paths to business ownership Build an inventory that links each high-risk API and MCP connection to a named service owner, a business purpose, and a review cadence.
- Scope delegated permissions for AI agents Limit each AI agent and automation path to the smallest viable set of tool permissions, data scopes, and execution contexts.
- Add runtime telemetry to API governance Monitor who or what is invoking critical APIs, from where, and with which actions.
What's in the full article
Salt's full post covers the operational detail this post intentionally leaves for the source:
- Month-by-month product and research milestones across 2025, useful for tracking how the vendor positioned API and AI risk through the year.
- Specific product capabilities such as Salt Illuminate, Salt Surface, GitHub Connect, and MCP Finder, which are not unpacked here.
- Examples of how the vendor describes runtime protection for AI agent actions across APIs and MCP servers.
- The closing 2026 outlook that links visibility, context, and stopping attacks to the next phase of API security practice.
👉 Read Salt's year-end analysis of API action-layer risk and AI agents →
API action layer risk and AI agents: are your controls keeping up?
Explore further
02/08/2026 1:15 pm
API action-layer governance is now part of identity security, not separate from it. When AI agents, applications, and MCP-connected services share the same execution paths, the practical control point is no longer just authentication. It is runtime authorisation, delegated scope, and action-level policy. That makes API security a direct extension of IAM and PAM for machine-driven access, especially where NHI governance is already under strain.
A question worth separating out:
Q: What should organisations do when API security and AI governance overlap?
A: Unify discovery, access control, and runtime monitoring under a single operating model. The goal is to know which identities, human or non-human, can invoke which actions, under what conditions, and whether those actions still match the approved business purpose.
👉 Read our full editorial: API action layer security is becoming the new AI attack surface
