Notifications
Clear all
Topic starter
02/08/2026 12:14 pm
TL;DR: AI agents are increasingly making decisions and triggering workflows through APIs and MCP, creating a security gap where visibility, governance, and detection lag behind usage, according to Salt. The core issue is assumption collapse: access reviews and static privilege models were built for stable identities, not runtime actors that can change behaviour mid-session.
NHIMG editorial — based on content published by Salt: AI agents, MCP, and the expanding API attack surface
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 AI agents complicate least-privilege access models?
A: Because agents often use shared or long-lived NHIs, move quickly, and cross platform boundaries that human-centric review processes do not cover well.
Q: What breaks when AI agent access is inherited directly from the user who triggered the workflow?
A: Direct inheritance collapses two different subjects into one security decision.
Practitioner guidance
- Inventory every agent-facing API path Map which AI agents, MCP servers, and downstream services are connected, then classify each path by data sensitivity, action capability, and ownership.
- Separate read access from action authority Do not let an agent that needs context also inherit write or transaction privileges by default.
- Log runtime context, not just API calls Capture the agent identity, prompt or task context, tool invoked, target system, and outcome.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- The article spells out Salt's view of how AI agents, LLMs, and MCP connect to production APIs in practice.
- It outlines the visibility, governance, context, and detection capabilities the vendor says are required for secure deployment.
- It describes the security problem from the vendor's API-centric perspective, including how it interprets agent misuse and downstream exposure.
- It provides the vendor's own framing for why AI agent traffic will expand and how that changes the attack surface.
👉 Read Salt's analysis of AI agent API risk and MCP exposure →
AI agent identity risk and MCP access: are controls keeping up?
Explore further
02/08/2026 1:17 pm
AI agent identity is becoming an API governance problem before it becomes a model governance problem. Salt’s framing points to a structural shift: the attack surface now sits in the execution path between agent reasoning and downstream action. That means the governance question is no longer limited to whether the model is safe. It is whether the agent identity can be trusted to call tools, invoke APIs, and move data without expanding its own privilege boundary. Practitioners should treat agent identity as a first-class control surface, not an AI side issue.
A few things that frame the scale:
- 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%), according to AI Agents: The New Attack Surface.
- A separate finding from the same research shows that only 44% of organisations have implemented policies to govern AI agents, despite 92% saying that governance is critical to enterprise security.
A question worth separating out:
Q: Who is accountable when an AI agent takes an unsafe action?
A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.
👉 Read our full editorial: AI agent identity risk is outpacing API governance controls
