Notifications
Clear all
Topic starter
02/08/2026 11:48 am
TL;DR: AI agents operate across a three-layer agentic stack of LLM, MCP server, and APIs, and Salt argues that security risk propagates through all three layers even when the model itself appears safe. The governance gap is that conventional perimeter and model-only controls do not cover autonomous API execution or tool access decisions.
NHIMG editorial — based on content published by Salt: The Agentic Stack and where AI agent security risk actually lives
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 chat-based AI systems create new identity risk for organisations?
A: Chat-based AI systems compress intent, delegation, and execution into one interaction, which makes privilege boundaries easier to cross without noticing.
Q: What breaks when MCP servers are over-permissioned?
A: When MCP servers are over-permissioned, the agent inherits broader access than its task needs, and a compromise in that layer can reach every connected system.
Practitioner guidance
- Map every agent to its MCP servers and APIs Build an inventory that records which agents use which MCP servers, which APIs those servers call, and what data or workflow each call can affect.
- Treat MCP servers as privileged integration identities Assign each MCP server a narrowly scoped credential set, review its permissions like a service account, and rotate or revoke access when the connected workflow changes.
- Move monitoring to authenticated east-west API traffic Focus detection on API calls made inside the environment, not just perimeter traffic or chat prompts.
What's in the full article
Salt's full article covers the architectural detail this post intentionally leaves at the governance level:
- A layer-by-layer explanation of how the agentic stack routes intent from LLM to MCP server to API call.
- Examples of how east-west API traffic bypasses perimeter controls in real enterprise environments.
- Operational guidance on mapping sequence of intent across connected services and workflows.
- The vendor's view of why current security tools miss the highest-risk part of agentic execution.
👉 Read Salt's analysis of the agentic stack and AI agent security →
The agentic stack: are your controls keeping up with AI agents?
Explore further
02/08/2026 12:58 pm
Agentic governance debt is now an architecture problem, not a policy problem. The article shows that model safety alone cannot govern an agent that acts through external tools and APIs. Once control is distributed across the LLM, MCP server, and action layer, security teams need a layered governance model that tracks identity, privilege, and execution together. The practitioner conclusion is simple: if you cannot map the chain of intent, you cannot govern the agent.
A question worth separating out:
Q: What should teams do when agents can trigger internal API actions without review?
A: Teams should add runtime authorisation, transaction logging, and anomaly detection around the exact actions the agent can take. The main accountability question is whether the workflow can be approved, traced, and rolled back. If those controls are missing, autonomous execution can create business impact before a human sees it.
👉 Read our full editorial: The agentic stack exposes where AI agent risk actually lives
