Notifications
Clear all
Topic starter
02/08/2026 11:41 am
TL;DR: As AI agents and MCP servers multiply, APIs are becoming the primary attack surface and existing endpoint, network, and cloud controls do not provide enough inventory, runtime oversight, or behavioural context, according to Salt Security. The security model is shifting toward agentic AI security because machine-speed API use changes how access, monitoring, and governance need to work.
NHIMG editorial — based on content published by Salt: Agentic AI security and the fourth pillar of cybersecurity
By the numbers:
- APIs now account for over 80% of web traffic.
- Enterprises often have 10–20x more APIs than traditional applications.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: What breaks when AI agents are given broad standing access?
A: Broad standing access breaks governance because the agent can move from one task to another without a fresh authorization check.
Q: Why do MCP environments increase identity governance complexity for AI agents?
A: MCP turns model-tool interaction into a repeatable identity event, which means access, logging, and approvals must work at the capability level rather than at the application level.
Q: How do organisations know if agentic AI governance is actually working?
A: Look for three signals: access decisions tied to task context, complete audit records linking agents to datasets, and rapid revocation when scope changes.
Practitioner guidance
- Build a live inventory of agents, MCP servers, and APIs Track every AI agent, MCP server, and downstream API in one ownership model so security can see shadow deployments, exposed bridges, and unregistered endpoints before they become part of production workflows.
- Scope delegated access to task-level permissions Assign each agent only the specific API actions it needs, then remove broad reusable access paths that create confused deputy risk and unnecessary reach into sensitive systems.
- Enforce behavioural baselines for machine-to-machine traffic Measure normal call frequency, destination systems, and payload patterns for each agent so anomaly detection can flag logic abuse, prompt-driven misuse, or sudden expansion in data access.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- The article lays out the full four-part argument for treating agentic AI security as a separate cybersecurity pillar.
- It expands the comparison between endpoint, network, cloud, and API-driven control gaps in modern environments.
- It describes Salt's own discovery, governance, and behavioural monitoring approach for agentic traffic.
- It includes the operational framing for continuous discovery of MCP servers, shadow agents, and API relationships.
👉 Read Salt's analysis of agentic AI security as the fourth pillar →
Agentic AI security and API exposure: are your controls keeping up?
Explore further
02/08/2026 12:53 pm
Agentic AI security is becoming a control plane issue, not a point-solution category. The article is right to treat APIs as the connective tissue of the AI era, because the risk is concentrated in who or what can invoke them, under what scope, and with what downstream authority. That makes the issue inseparable from IAM, PAM, and NHI governance. Security teams should treat agentic API access as a lifecycle problem, not a perimeter problem.
A question worth separating out:
Q: Who should own AI agent security across IAM, API, and platform teams?
A: Ownership should be shared but explicit. IAM teams should define identity and access policy, API teams should enforce request controls, and platform teams should manage the runtime boundary and logging. If ownership is split informally, gaps appear exactly where agents cross from one service to another.
👉 Read our full editorial: Agentic AI security and API exposure are becoming a fourth pillar
