TL;DR: AI agents connected through MCP are taking actions across internal systems with elevated privileges, while organisations still struggle to monitor granted versus used access, according to Oasis Security. The governance gap is not technical novelty but identity scope, ownership, and logging that were built for slower, human-paced access models.
At a glance
What this is: This is an analysis of how AI agents and MCP integrations create NHI governance risk by expanding access, reducing visibility, and increasing blast radius across internal systems.
Why it matters: It matters because identity teams now have to govern autonomous-style runtime access paths, third-party integrations, and privileged machine actions with controls built for much slower access lifecycles.
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.
Context
AI agent and MCP identity risk is really a governance problem about who or what gets to act inside production systems. The article argues that model-driven integrations are no longer passive analytics layers, because they can take actions, trigger workflows, and operate with permissions that are hard to inspect after issuance.
The NHI issue is not whether organisations can connect an agent to tools, but whether those identities are owned, scoped, logged, and reviewed in a way that matches their actual runtime behaviour. The article points to over-provisioned access, unmanaged OAuth paths, and weak monitoring as the practical failure modes.
That makes the article typical of today’s AI adoption pattern: fast integration first, identity governance later. The central lesson is that AI agent access behaves more like privileged machine identity than like a conventional application account, even when teams treat it as a convenience feature.
Key questions
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. That creates a control gap between intended scope and actual runtime behaviour. The result is weak accountability, limited containment, and audit trails that show activity without explaining why the activity was allowed.
Q: Why do AI agents create more governance risk than ordinary integrations?
A: AI agents can connect quickly, run continuously, and accumulate broad permissions across multiple services. That combination makes ownership blur and scope drift more likely, so the real risk is not the tool itself but the uncontrolled access path it creates across enterprise systems.
Q: What signs show that AI access sprawl is getting out of control?
A: Look for broad admin-consented permissions, agents targeting many services, unknown owners, dormant connections and disconnected approval records. Those signals indicate that access has moved faster than governance. If teams cannot tie each agent to a purpose and accountable owner, the environment is already operating beyond policy.
Q: Should organisations prioritise access review or secret hygiene first for AI agents?
A: Secret hygiene should come first when API keys or tokens are embedded in configs, because exposed credentials can become immediate entry points. Access review still matters, but it is a slower control if the initial problem is that the credential itself is leaking into repositories or shared tooling.
Technical breakdown
How MCP expands the identity surface for AI agents
MCP is an integration layer that lets AI agents connect to external tools and data sources in a structured way. In practice, that means an agent can move from reading information to executing actions across CRMs, cloud APIs, ticketing systems, and repositories. The identity risk comes from the fact that each connection may reuse an existing account, token, or OAuth grant, while the agent’s runtime behaviour changes dynamically. That creates a wider and less predictable authorization surface than a static service account with one known purpose.
Practical implication: treat each MCP connection as a distinct identity-bearing integration, not as a generic automation channel.
Why granted access and used access diverge in agent workflows
Traditional IAM often evaluates access at provisioning time, but AI agents consume privileges selectively at runtime. An agent may be granted broad read and write permissions, yet only use a subset of them during a given session or task. That makes granted-versus-used analysis essential, because over-scoping can remain invisible if teams only review the approved role rather than the actual actions taken. When agents operate in bulk or background mode, this gap becomes more serious because activity can be distributed, low-signal, and easy to miss in standard logs.
Practical implication: measure what the agent actually uses, not just what the business approved.
How cleartext secrets in MCP configs become an identity leak path
The article highlights a common failure pattern: API keys stored in local configuration files for AI desktop tools and MCP servers, then accidentally exposed through repositories or shared environments. That is a classic secret-leakage pathway, but the impact is amplified because the secret is often attached to an identity that can act across multiple systems. Once that credential is exposed, the problem is not just disclosure, but the persistence of trust until the key is rotated, revoked, or discovered through monitoring.
Practical implication: eliminate static secrets in AI integration configs and assume they will eventually surface outside the intended boundary.
Threat narrative
Attacker objective: The attacker objective is to obtain or abuse trusted AI-linked credentials and integrations in order to move through internal systems with minimal oversight.
- Entry occurs when developers or non-developers connect AI agents to internal systems through MCP, OAuth, or shared credentials.
- Credential exposure follows when API keys, tokens, or overly broad account grants are placed in configuration files or reused across tools.
- Escalation happens when the agent receives elevated privileges for convenience and begins acting across production, ITSM, cloud, or code systems.
- Impact is broad blast-radius expansion, with unmonitored actions, unmanaged backdoors, and exposed secrets increasing the chance of misuse or compromise.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
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 connected through MCP are behaving like privileged NHIs, not like ordinary applications. The governance mistake is to treat them as convenience integrations while the runtime reality is broader system access, dynamic action, and background execution. Once an agent can both read and act, the identity model has to follow the behaviour, not the UI label. Practitioners should classify these integrations as high-risk machine identities and govern them accordingly.
Granted access and used access are now different control problems. The article exposes a familiar IAM blind spot: approval-time scope says little about what the agent will actually do at runtime. That means ownership, logging, and entitlement review all need to be tied to observed behaviour rather than static policy. The practitioner conclusion is that review cadences built for human users are too slow to govern agentic execution.
Ephemeral credential trust debt: The article shows how quickly teams accumulate trust in API keys, OAuth grants, and configuration-stored secrets because they make AI integration easy. That trust becomes technical debt when the credential is hidden, reused, or hard to inventory across multiple tools. The implication is not merely more hygiene, but a stricter model for what is allowed to act on behalf of the organisation.
AI adoption is compressing the identity lifecycle. Developers and business users can now introduce access paths far faster than traditional IAM and IGA processes can classify, approve, and recertify them. That creates an ownership gap where the system is live before the governance record is complete. Practitioners should assume that onboarding speed now outpaces assurance unless identity lifecycle controls are redesigned for machine speed.
Visibility, not just permissioning, is the decisive control variable. The article repeatedly shows that broad access becomes most dangerous when it is under-logged and poorly observed. This is where NHI governance meets operational security: you cannot manage what you do not continuously see. The practitioner conclusion is that monitoring and accountability must be designed into agent connectivity from the start.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
- Read next: Ultimate Guide to NHIs — Key Challenges and Risks
What this signals
Ephemeral credential trust debt: AI integrations are forcing teams to trust keys, tokens, and OAuth grants far faster than governance processes can inventory them. The result is a growing mismatch between how access is introduced and how it is actually controlled, which is why lifecycle governance now matters at the point of issuance, not only at review.
MCP-style connectivity should push practitioners toward tighter ownership, stronger logging, and explicit separation between approved access and observed use. That shift is especially important in programmes that still treat application accounts as low-risk by default, because AI agents can convert those same accounts into high-impact action paths in a single task.
For practitioners
- Define ownership for every AI integration Assign a named business or technical owner to each agent, MCP server, or OAuth-connected tool so accountability survives deployment and staff turnover.
- Review granted versus used permissions Compare approved scopes to actual runtime actions for each agent or integration, then tighten any access that is never exercised in practice.
- Remove static secrets from AI configs Move API keys and tokens out of local configuration files, repositories, and shared builder workflows, because those locations routinely become accidental leak paths.
- Treat AI agents as high-risk NHIs Place agent identities under stricter logging, alerting, and recertification than ordinary application accounts, especially where they can modify production systems.
- Enforce secure self-service guardrails Give teams pre-approved pathways for AI tool onboarding so convenience does not translate into unmanaged access or hidden backdoors.
Key takeaways
- AI agents connected through MCP behave like high-risk machine identities because they can act, not just analyse.
- The article’s examples show that secrets leakage and over-scoped access can turn convenience into broad blast radius quickly.
- Identity teams should govern AI integrations with ownership, runtime visibility, and tighter credential discipline from the start.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on API keys and tokens leaking from AI integration configs. |
| NHI-05 — Overprivileged NHI | AI agents are described as receiving elevated privileges beyond the task they need. | |
| NHI-07 — Long-Lived Secrets | The article highlights static API keys and OAuth grants that persist longer than their useful scope. | |
| Recommendation — Scan AI configs and repositories for leaked secrets and revoke exposed credentials immediately. Reduce agent scopes to the minimum access required for each integration. Replace durable AI credentials with shorter-lived, tightly governed credentials where possible. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The core issue is agent identities acting with excessive privilege across connected systems. |
| Recommendation — Constrain agent privilege paths and log every privileged action for review. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle is directly implicated by exposed keys and tokens in AI tooling. |
| Recommendation — Apply authenticator lifecycle controls to rotate and revoke AI-linked credentials promptly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about entitlement scope versus actual AI agent use. |
| Recommendation — Continuously reconcile AI agent entitlements with observed access and action patterns. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes exposed credentials enabling movement across internal systems. |
| Recommendation — Map AI credential exposure to TA0006 and TA0008 in threat detection and hunting. | ||
Key terms
- MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
- 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.
- Ephemeral Credential Trust Debt: Ephemeral credential trust debt is the hidden risk that appears when short-lived tokens create a false sense of safety while permissions remain broad. The credential expires quickly, but the underlying blast radius stays large unless identity scope, revocation, and audit controls are also tightened.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org