Agentic access is exposing MCP and AI control-plane gaps

At a glance

What this is: This roundup tracks the most important June 2025 agentic access stories and shows how MCP, LLM, and AI agent integrations are turning access control into a live attack surface.

Why it matters: It matters because IAM, NHI, and PAM programmes now have to govern runtime access decisions for agents and tools, not just static credentials and human users.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
• 7,000 misconfigured MCP servers are live on the public web, with many wide open to remote code execution.

👉 Read Pomerium's roundup of June 2025 agentic access risks

Context

Agentic access is the point where AI systems move from generating output to taking actions through tools, APIs, and connected services. This roundup focuses on the security and governance gap that opens when MCP servers, model clients, and agent workflows begin operating inside real enterprise systems.

The identity issue is not whether AI can reason well enough. It is whether access boundaries, auditability, and approval gates still hold when software can select tools, move data, and trigger workflows at runtime. For IAM, NHI, and PAM teams, that changes the control surface from login-time trust to session-time enforcement.

Key questions

Q: How should security teams govern AI agents that can call tools and APIs?

A: Treat each agent as a governed identity with explicit scope, logging, and approval boundaries. The key is not whether the model is smart enough, but whether it can reach the right tools without bypassing policy. If the agent can read, write, or trigger actions, access must be enforced at runtime and tied to an accountable owner.

Q: Why do MCP servers increase the risk of agentic access abuse?

A: MCP servers connect agents to real systems, so a weakly controlled server becomes a privilege bridge rather than a simple integration layer. If authentication, authorisation, and context filtering are loose, a prompt injection or malicious client can turn normal tool access into data exposure or unsafe execution.

Q: What do security teams get wrong about prompt injection in agentic systems?

A: They often treat prompt injection as a text problem instead of an execution problem. The real risk appears when poisoned instructions influence tool calls, retrieval, or workflow actions. Defences need to separate untrusted content from action-bearing prompts and require policy checks before execution.

Q: Who is accountable when an AI agent exposes data or performs unauthorised actions?

A: Accountability should sit with the team that owns the agent, the connected system, and the policy that allowed the access path. If no one can explain who approved the scope, what data was reachable, and how the action was logged, the governance model is incomplete.

Technical breakdown

MCP servers turn model access into a tool-access problem

Model Context Protocol connects AI clients to external tools and data sources through standardised interfaces. That convenience becomes risk when servers are misconfigured, overexposed, or trusted without strong policy enforcement. In practice, the attack surface is not only the model itself but every tool the model can reach through MCP, including file stores, SaaS data, and workflow systems. Once a server is public and permissive, prompt injection or malicious client behaviour can turn routine access into command execution or data exfiltration. Practical implication: treat every MCP server as an identity-controlled integration point, not as a harmless connector.

Practical implication: enforce authentication, authorisation, and scoped access on every MCP server before exposing it to agents.

Prompt injection is now a control-plane attack, not just a content trick

Prompt injection matters because agents increasingly use model output as a trigger for tool calls, retrieval, or downstream workflow steps. When a malicious prompt changes the agent’s interpretation of instructions, the attacker is not merely manipulating text. They are steering execution. In environments like GitHub or Asana, that can mean cross-repository access, data leakage, or unapproved actions inside trusted systems. The security problem is that the instruction boundary and the action boundary are now coupled. Practical implication: isolate untrusted content from action-bearing prompts and require policy checks before any tool invocation.

Practical implication: separate untrusted content from action-bearing prompts and gate tool calls through policy enforcement.

Zero-click exfiltration shows how agents fail without explicit trust boundaries

Zero-click attacks against agentic systems demonstrate that access can be abused without a user clicking, approving, or even noticing. In retrieval-augmented and Copilot-style flows, the agent may fetch sensitive context automatically and surface it in a way that leaks data to the wrong place. This is especially dangerous because traditional user-centric controls assume a conscious action at the edge. Agentic systems remove that assumption. Practical implication: classify agent access as a governed workload identity with explicit data boundaries, not as an extension of the end user.

Practical implication: classify agent access as a governed workload identity with explicit data boundaries and audited retrieval paths.

Threat narrative

Attacker objective: The attacker aims to turn agentic access into controlled data theft, privilege abuse, or arbitrary actions inside trusted enterprise systems.

1. Entry occurs through public MCP exposure, prompt injection, or unsafe client-server trust that lets the attacker influence an agent’s available tools and context.
2. Escalation happens when the agent follows poisoned instructions or mis-scoped permissions to access repositories, SaaS data, prompts, or credentials it should not have touched.
3. Impact is data leakage, workflow hijack, cross-tenant exposure, or remote code execution through the tools the agent was allowed to use.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 access is becoming an identity governance problem before it becomes an AI problem. The June stories are not mainly about model quality. They show that the control failure sits at the junction of identity, tools, and runtime decision-making, where access is granted to software that can act. That makes governance, not novelty, the central issue. Practitioners should treat agentic workflows as governed identities with explicit scope and audit requirements.

Identity as the control plane is the right framing for MCP, because the model is only one hop in the chain. Once an agent can reach repositories, SaaS platforms, or internal APIs, the security question becomes who or what is authorised to use those tools, under what policy, and with what evidence. That is classic NHI territory, but with a higher-speed decision loop. Practitioners should move policy enforcement to the moment of access, not after the fact.

Runtime policy is now the differentiator between assisted automation and unsafe autonomy. The article’s examples show that static permissions and one-time approvals do not survive tool chaining, prompt injection, or zero-click execution paths. A control that works at provisioning time can fail inside a single agent session. Practitioners should assume the blast radius is determined by live execution conditions, not by the nominal role assigned at onboarding.

Cross-org and cross-tenant exposure is the named concept this month’s agentic incidents keep revealing. Asana, GitHub, and Copilot-style cases all point to the same failure mode: access boundaries are assumed rather than enforced across models, tools, and tenants. That assumption breaks as soon as an agent can traverse systems automatically. The implication is that tenant isolation and entitlement scoping must be verified continuously, not inferred from architecture diagrams.

Agentic governance now depends on NHI discipline, even when the actor is not a traditional workload. AI agents inherit the same failure patterns as service accounts, but they move faster and can combine permissions in ways human operators do not. That means secrets handling, scoped access, and audit trails remain foundational, but they need to be enforced against runtime behaviour. Practitioners should align agent governance with OWASP-NHI and zero-trust controls, not treat it as a separate silo.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• 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, according to SailPoint.
• For a broader operating model, see OWASP Agentic Applications Top 10, which helps teams map agentic risk patterns to concrete controls.

What this signals

Cross-tenant and cross-system exposure is becoming the default failure mode for agentic programmes. The question is no longer whether AI agents can access tools. It is whether the access graph is explicit enough to survive adversarial input, delegated execution, and policy drift. With 33% of organisations already reporting agents accessing inappropriate or sensitive data beyond intended scope, the governance model needs to assume abuse paths from the start.

Runtime enforcement now matters more than entitlement design on paper. If an agent can decide when to act, the programme needs controls that observe and constrain the action itself. That is the practical meaning of identity-aware access in the agentic era, and it should shape how IAM, NHI, and PAM teams design approvals, logging, and exception handling.

Policy owners should expect more agent sprawl before they get better visibility. The operating signal is not adoption alone but whether each agent can be traced to a business owner, a data boundary, and a review process. Teams that cannot answer those three questions are already behind the governance curve.

For practitioners

• Inventory every agent-to-tool path Map each MCP server, model client, and downstream API that an agent can reach. Record the identity used, the data exposed, and the approval points that exist before the tool call is executed.
• Move policy checks to runtime Require authorisation at the moment of access for every high-risk tool call. Static provisioning reviews are not sufficient when agents can chain actions within a single session.
• Separate untrusted content from action prompts Isolate retrieved text, user input, and external content from any prompt that can trigger a tool call. Add policy gates so the agent cannot convert untrusted content directly into execution.
• Classify agents as governed identities Assign ownership, logging, and review expectations to each agent the same way you would for a workload identity. Track what data it can access, what it can change, and how you will prove that scope.

Key takeaways

• Agentic access turns identity governance into a runtime control problem because tool use, not model output, is where the risk materialises.
• The evidence is now broad enough to be operational, with misconfigured MCP servers, zero-click exfiltration, and cross-tenant leakage all appearing in the same month.
• Teams should govern agents like workloads with explicit scope, audited retrieval, and policy enforcement at the point of access.

Key terms

• Model Context Protocol: A standard protocol that lets AI clients connect to tools and data sources. In agentic environments, it creates a governed access path, not just an integration layer, because the model can use external systems to take actions that affect enterprise data and workflows.
• Agentic Access: The pattern where an AI system can select tools, retrieve data, and trigger actions at runtime. Unlike simple automation, agentic access changes security because the actor can decide what to do in context, which makes authorization, monitoring, and containment essential.
• Cross-Tenant Exposure: A failure where one user or organisation can reach data belonging to another tenant. In agentic systems, this often appears when boundaries are assumed in the application layer but not enforced tightly enough in the tool, identity, or retrieval layer.
• Runtime Policy Enforcement: The practice of checking access, context, and risk at the moment an action is about to happen. For agentic systems, this matters because static approvals and provisioning decisions do not reliably control what an autonomous or semi-autonomous workflow will do next.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by Pomerium: Top 10 Articles in Agentic Access - MCP, Models, and Clients (June 2025). Read the original.