Agentic AI has made the internal API security model obsolete

At a glance

What this is: This is an analysis of how agentic AI and MCP-style connections undermine the internal API security model and create trusted-entity risk.

Why it matters: It matters because IAM, NHI, and security teams now have to govern machine-speed, delegated access inside the network, not just authenticate entry at the perimeter.

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%).
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Salt's analysis of the internal API trust model in the agentic era

Context

Agentic AI changes the access model because the system itself can decide when to act, which data to query, and which tools to call. In that environment, the old assumption that internal APIs are safe once they are behind a gateway breaks down, and the primary identity-security question becomes how to govern trusted machine actors inside the network.

Salt frames this around the porous perimeter created by MCP-style connections and AI-to-API interactions. For IAM and NHI teams, the practical issue is not just whether access was authenticated, but whether delegated access, data handling, and policy enforcement still hold when the actor is an AI agent operating at machine speed.

Key questions

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. The key control is to limit which APIs, data sources, and write actions the agent can chain together in one session. That keeps machine-paced behaviour inside a reviewable boundary instead of relying on human-style session assumptions.

Q: Why do internal API gateways fail to stop agentic AI misuse?

A: Because gateways mainly inspect traffic at the edge, while agentic misuse happens after a trusted identity has already been accepted. The dangerous step is not the connection itself, but the way the agent uses that access inside the environment. Identity-aware runtime controls are needed where the action occurs.

Q: What do security teams get wrong about DLP and AI assistants?

A: They assume DLP will catch unsafe sharing even when the assistant is acting inside a trusted workflow. In practice, the failure is often contextual: the wrong record is summarised, the wrong recipient is served, or policy labels are ignored without a classic exfiltration event. Behaviour monitoring is the missing layer.

Q: How can organisations reduce confused deputy risk in agentic AI?

A: By shrinking the authority granted to the agent and making every tool and data connection explicit. Confused deputy risk grows when a trusted system can act beyond user intent, so the answer is narrower permissions, better lifecycle review, and runtime checks that validate purpose, not just authentication.

Technical breakdown

Why the internal API model fails for agentic AI

The internal API model assumed that traffic behind the perimeter was inherently lower risk and easier to trust. Agentic AI breaks that model because the actor can generate requests, choose tools, and move between data sources inside the environment without traversing the same edge controls as a human user. That creates a blind spot between authentication and actual data use. Traditional gateways see an approved connection, but they do not understand whether the agent is using that access in a way that matches the intended business task.

Practical implication: Treat internal API access as a governed identity path, not a trusted network shortcut.

Why the confused deputy problem gets worse with MCP

A confused deputy appears when a legitimate, trusted entity is manipulated into using its own authority in ways the owner did not intend. MCP expands that risk because it standardises how agents connect to tools and data sources, which makes it easier to scale misuse if the surrounding governance is weak. The issue is not only malicious compromise. It is also over-broad authority, weak scoping, and a failure to constrain what a trusted agent can do once connected.

Practical implication: Scope every agent and MCP connection to the minimum tool and data set required for the task.

Why DLP and WAF controls miss the real failure mode

DLP and WAF tools are designed to inspect content or block known attack patterns at network boundaries. They struggle with agentic misuse because the problem is often contextual, not signature-based. An AI assistant can be fully authorised, yet still surface the wrong record, ignore a sensitivity label, or summarise data for the wrong recipient. That is a policy and intent failure, not a classic perimeter event. The defence challenge moves from packet inspection to behavioural governance.

Practical implication: Add continuous behavioural monitoring for AI-to-API interactions instead of relying on perimeter inspection alone.

Threat narrative

Attacker objective: The objective is to abuse trusted internal AI access so sensitive data is exposed or shared without an obvious security event.

1. Entry occurs through a legitimate AI assistant or MCP connection that is already trusted inside the environment. Escalation happens when the trusted tool is able to query or process more data than the user should receive, or when policy checks fail to constrain the request. Impact follows when confidential data is summarised, exposed, or exfiltrated without triggering a perimeter alarm because the activity looked legitimate from the inside.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic AI has collapsed the internal safe zone assumption: internal trust was built for systems that were predictable, bounded, and externally triggered. That assumption fails when an AI agent can select data, invoke tools, and process context inside the network at runtime. The implication is that identity governance can no longer rely on perimeter placement as a proxy for trust.

Confused deputy risk is now an identity governance problem, not just an application bug: a trusted AI actor can be tricked or mis-scoped into acting outside the user’s intent while remaining technically authenticated. That shifts the control question from login success to authority containment. Practitioners must treat delegated AI access as a governance surface with its own lifecycle and review model.

Every API is now an edge API: once agents interact directly with internal data sources, the old north-south versus east-west distinction becomes less useful for identity control design. The security boundary moves to the agent, the tool permission, and the decision context. Organisations that still anchor governance only at the gateway will miss the real enforcement point.

Intent-based governance is the named concept that matters here: policy enforcement must account for what the agent is trying to do, not only what account it used or which endpoint it reached. That is a structural shift from access control to behaviour control. For IAM, NHI, and PAM teams, the practitioner conclusion is that identity policy must extend into runtime action review.

Continuous discovery is the prerequisite for any defensible agentic model: unknown MCP servers, shadow agents, and unmanaged data bridges create governance debt before the first policy is written. Without a complete inventory, even the best-designed controls will miss part of the execution graph. The field should treat discovery as an identity control, not just an asset management task.

From our research:

• 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 report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For the wider agentic-AI control picture, see OWASP Agentic Applications Top 10 for the runtime abuse patterns that perimeter tools miss.

What this signals

Intent-based governance: the practical control shift is from asking whether a machine identity was authenticated to asking whether its runtime action still matches the approved purpose. That is why AI agent governance belongs beside NHI lifecycle and PAM controls, not only in application security conversations.

With 96% of technology professionals already identifying AI agents as a growing threat, the programme risk is no longer awareness. The next step is to decide which internal connections are allowed to behave like edges, then apply policy, review, and monitoring to those paths.

For teams building toward agentic governance, the immediate watchpoint is discovery. If you cannot inventory the agent, the tool chain, and the data bridge, you cannot assert control over who or what is acting inside the network.

For practitioners

• Map every AI-to-API trust path Inventory each AI assistant, MCP server, and direct data bridge that can reach internal systems. Classify the identity, the tools it can call, and the data it can surface so you know where delegated access actually exists.
• Scope agent permissions to task-level need Remove broad internal access patterns and limit each agent to the minimum APIs and datasets required for a defined business purpose. Review whether the same entitlement would be acceptable for a service account with similar reach.
• Add behavioural controls to AI conversations Monitor for abnormal request volume, unexpected data types, and context switching that indicates an agent is summarising or exposing more than intended. Use runtime policy enforcement rather than edge-only inspection.
• Treat DLP as insufficient on its own Assume sensitive content can be misrouted by a trusted internal tool without a block event. Pair content controls with identity-aware governance that tracks who or what triggered the action and whether the outcome matched intent.
• Require continuous discovery of shadow agents Build a process to identify unmanaged AI integrations before they become privileged paths to data. If a team can stand up an internal agent without security visibility, the governance model is already behind.

Key takeaways

• Agentic AI breaks the old assumption that internal systems are inherently trusted, which pushes identity governance into runtime behaviour rather than perimeter validation.
• Trusted internal agents can misapply policy without looking like an intrusion, so DLP and gateway controls alone will miss the most relevant failures.
• The practical response is continuous discovery, tight tool scoping, and identity-aware monitoring of AI-to-API actions inside the environment.

Key terms

• Agentic action layer: The agentic action layer is the runtime zone where AI agents choose tools, query data, and execute tasks. It is not the model itself. In governance terms, this is where identity, privilege, and policy enforcement must meet actual machine behaviour.
• Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
• East-west traffic: East-west traffic is communication that moves between systems inside an environment rather than entering or leaving it. In microsegmentation programmes, it is the traffic most likely to expose hidden trust assumptions and is therefore the main target for workload-level policy.
• Intent-based behavioural protection: Intent-based behavioural protection is runtime monitoring that looks at what an identity appears to be trying to accomplish, not only which endpoint it touched. It matters for AI agents because legitimate access can still produce unsafe outcomes when context or purpose drifts.

What's in the full article

Salt's full post covers the operational detail this analysis intentionally leaves for the source:

• The article's working model for the Agentic Action Layer and why the vendor believes the perimeter no longer contains AI-to-API risk.
• The vendor's breakdown of continuous discovery, adaptive governance, and intent-based behavioural protection as a control stack.
• The Microsoft Copilot incident context and the specific internal trust assumptions Salt argues were invalidated.
• The product framing for how Salt positions API security assessments and agent discovery in practice.

👉 The full Salt post covers the Microsoft Copilot context, MCP risk framing, and its three-pillar defence model.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.