AI agent and MCP identity risk outpaces enterprise IAM controls

At a glance

What this is: This analysis argues that AI agents and MCP-connected tools are expanding the NHI attack surface by combining broad permissions, weak ownership, and limited behavioural oversight.

Why it matters: IAM, PAM, and NHI teams need to treat AI-connected identities as high-risk actors because the same access patterns now affect human, service, and agent governance boundaries.

By the numbers:

• LLMs are used by over 90% of fortune 500 companies, according to Oasis Security.
• The MCP repository has already been forked over 4,000 times, according to Oasis Security.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to NHIMG research.

👉 Read Oasis Security's analysis of AI agent and MCP identity risk

Context

AI agent identity risk is no longer a theoretical edge case. Once LLMs and MCP-connected tools are allowed to reach into cloud APIs, ITSM systems, code repositories, and business applications, the security question shifts from model capability to identity governance, permissions, and auditability.

The core issue is that these integrations often behave like privileged non-human identities, but they are introduced through fast-moving development workflows and personal accounts. That combination creates unmanaged access paths, weak accountability, and visibility gaps that traditional IAM programmes were not designed to absorb.

Identity blast radius: when an AI agent is granted broad action rights across multiple systems, the security problem is no longer only credential protection. It becomes a question of how far one identity can move, modify, and trigger business processes before controls notice.

Key questions

Q: How should security teams govern AI agents that use MCP to access internal systems?

A: Security teams should govern MCP-connected AI agents as privileged non-human identities with owners, scoped permissions, and usage logging. The key is to manage the agent’s identity, not just the model. That means defining purpose, limiting tool access, and monitoring actual actions against the approved workflow.

Q: Why do AI agents complicate least-privilege design in IAM programmes?

A: AI agents complicate least privilege because their runtime actions can vary by context, data, and tool availability. Unlike a fixed service process, the agent may need multiple permissions across systems to complete one task. That makes entitlement design harder and increases the risk of over-scoping unless access is tied to a narrow business purpose.

Q: What breaks when AI agents are connected through personal accounts or shared credentials?

A: Shared or personal credentials break accountability, lifecycle control, and revocation. If an agent inherits a human account, security teams lose clean ownership and cannot reliably attest what the identity can do or when it should be disabled. That creates an unmanaged backdoor into systems that may persist after the original setup is forgotten.

Q: How do organisations know whether AI identity monitoring is actually working?

A: Monitoring is working when teams can see which agent initiated each action, which tool was used, what data was touched, and whether the sequence matches the approved purpose. If logs show activity but cannot connect it to an owner, workflow, and entitlement set, the programme still has a visibility gap.

Technical breakdown

How MCP expands the identity and access boundary

MCP connects an AI agent to tools and data sources through a standardised interface, which makes integration easier but also broadens the trust boundary. The identity is no longer just authenticating to one application. It may be authorised to call multiple APIs, read data, and trigger actions across systems. That changes the governance unit from a single app login to a distributed action surface. When permissions are inherited from a human account or copied from an existing service identity, the resulting access model often exceeds the task the agent actually needs.

Practical implication: Map every MCP-connected identity to a named owner, a defined business purpose, and a minimal action scope before it is allowed into production.

Why over-provisioned NHI permissions create hidden blast radius

Non-human identities often accumulate privilege because teams optimise for deployment speed rather than access precision. In AI-enabled workflows, that tendency is amplified by the need for read, write, and orchestration permissions across several systems. If an agent can inspect logs, open tickets, modify infrastructure, and update records, then compromise or misuse of that identity can propagate quickly. The technical risk is not only stolen credentials. It is a large permission envelope that lets one identity perform a chain of actions without meaningful challenge or review.

Practical implication: Compare granted permissions against actual usage and remove every privilege that is not exercised by the workflow.

Why logging and behavioural monitoring must move from human-centric to agent-centric

Traditional monitoring assumes a relatively stable human operator behind the account and a recognisable sequence of interactive actions. AI agents break that model by acting in bulk, in the background, and often without a visible human session. That means standard audit trails can show the action but not the intent, or they can miss the upstream decision that triggered it. Effective monitoring needs to capture which identity initiated the action, what tool was invoked, what data was touched, and whether the behaviour deviated from the approved workflow.

Practical implication: Instrument agent activity at the identity, tool, and data-access layers so abnormal behaviour is detectable before it becomes business impact.

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

AI agents are becoming privileged non-human identities before most organisations have built governance for them. The article shows that agents are being granted access to internal systems with elevated permissions and minimal oversight. That places them squarely in the NHI governance problem space, not in a separate AI-only category. The practical conclusion is that identity teams must classify these workloads as governed identities, not experimental tools.

Ownership is the control gap that decides whether AI access is governable at all. An agent without a clear business or technical owner becomes an orphaned identity the moment it is connected through OAuth, MCP, or a copied credential. The article’s own examples show how quickly unmanaged integrations can appear when developers and non-developers wire tools directly into production environments. Practitioners should treat ownership as a prerequisite to entitlement, not an afterthought.

Granted-access analysis is no longer enough when the real risk sits in used access. The source correctly distinguishes between what an identity was permitted to do and what it actually did. That distinction matters because over-scoped entitlements are common in fast-moving AI deployments, especially when agents can act across multiple systems. The implication is that governance evidence must include usage, not just policy.

Standing privilege in AI workflows creates a wider identity blast radius than most service-account programmes are prepared for. The named concept here is the blast-radius problem, but in AI-integrated environments it becomes more severe because one identity can open tickets, scale infrastructure, and update records in a single chain. This is not a tooling issue alone. It is a programme-level exposure that links NHI governance, workflow design, and incident containment. Practitioners should assume blast radius is the primary control variable.

Security teams need to stop asking whether AI belongs in the environment and start asking which identity model it is actually using. If the agent is acting with persistent credentials, broad permissions, and low monitoring, then it is already part of the identity estate. That framing is more useful than debating labels because it moves the discussion toward lifecycle governance, access scope, and evidence. The practitioner task is to govern the actor that exists, not the category the business prefers.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• Only 53% of MCP servers expose credentials through hard-coded values in configuration files, which means secret handling remains a common exposure path.
• For a broader NHI baseline, read Ultimate Guide to NHIs for governance, lifecycle, and control patterns that apply to machine identities as well as AI-connected systems.

What this signals

AI agent governance is now a lifecycle problem, not just a model security problem. Teams that already manage service accounts, credentials, and access reviews have the right control vocabulary, but they need to apply it to agents that can be created and connected far faster than traditional identities. The next programme gap will be in onboarding discipline, not just containment.

With 33% of organisations already reporting AI agents accessing inappropriate or sensitive data beyond their intended scope, the operational question becomes whether access review processes can actually keep pace with agent sprawl. The issue is not whether AI will be used, but whether access evidence, ownership records, and behavioural telemetry are ready when it is.

The useful forward move is to treat AI identities as part of the same governance stack that covers human access, service accounts, and privileged workflows. That means bringing agent provisioning, attestation, and monitoring into the same control plane rather than building a parallel exception process that nobody can retire cleanly.

For practitioners

• Inventory every AI-connected identity Create a complete register of AI agents, MCP servers, and third-party integrations with source, owner, data touchpoints, and production status. Treat unowned integrations as exceptions until a business or technical owner is assigned.
• Compare granted permissions to actual use Review each agent or integration for the permissions it was given versus the actions it actually performs. Remove write, modify, and escalation rights that are not necessary for the documented workflow.
• Separate personal accounts from machine access paths Block the practice of wiring AI services through personal OAuth accounts or developer credentials. Use dedicated, auditable identities with scoped access and explicit approval for sensitive systems.
• Instrument agent behaviour at the tool layer Log tool invocation, data access, and outbound actions for every AI identity so abnormal sequences can be detected. Correlate those events with the owning workflow and the approved purpose.
• Embed secure self-service guardrails Provide pre-approved workflows for teams that need AI access, but require policy checks, attestation, and least-privilege templates before credentials are issued.

Key takeaways

• AI agents connected through MCP behave like high-risk non-human identities when they are granted broad system access without ownership or scoping.
• Oasis Security’s analysis shows that fast adoption, weak monitoring, and over-permissioned identities are already creating the conditions for hidden blast radius.
• Practitioners should govern AI access as part of the identity lifecycle, with explicit ownership, entitlement review, and behavioural monitoring.

Key terms

• MCP Server: A Model Context Protocol server exposes tools and data sources that an AI agent can call through a standard interface. In practice, it becomes part of the identity boundary because the agent’s access, actions, and tool permissions are governed through it, not just through the model itself.
• AI Agent Identity: An AI agent identity is the set of credentials, permissions, and ownership records used to govern a software entity that can take actions across systems. For security teams, it must be treated as a non-human identity with lifecycle, logging, and access-scope controls, not as a simple application setting.
• Identity Blast Radius: Identity blast radius is the amount of damage one identity can cause before controls detect or stop it. In AI and NHI environments, the measure is shaped by tool permissions, data reach, and the number of systems an identity can modify in one workflow.
• Granted Versus Used Access: Granted versus used access compares what an identity is allowed to do with what it actually does. This distinction matters most for AI agents and service accounts because over-scoping is common, and unused privileges often represent the easiest path to avoidable exposure.

Deepen your knowledge

AI agent identity governance and MCP access scoping are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your teams are already connecting models to internal systems, this is the right place to build the control baseline.

This post draws on content published by Oasis Security: A real security challenge behind this artificial intelligence. Read the original.