New Report

The 7 Costly Mistakes Companies Make When Selecting an IAM Vendor — Read Free Research Brief

Your IGA Tool Cannot Govern What It Cannot See
NHI5 MIN ANALYSIS

Why the identity governance model built for human access reviews structurally fails when applied to AI agents, MCP servers, and the non-human identities provisioned at machine speed.

Lead Analyst
Fayaz Mulla Syed
Distribution Date
Wednesday, May 20, 2026
Share Intelligence

Astrix Security analyzed 5,205 open-source MCP server implementations and found that 53% rely on static credentials — API keys and Personal Access Tokens that are long-lived, rarely rotated, and stored in environment variables or configuration files that your IGA tool has never been pointed at. Your governance program has a certification campaign running. It has access reviews scheduled. It has a clean dashboard. What it does not have is visibility into the identity surface that your engineering teams are building right now, at a provisioning velocity your quarterly review cycle cannot match. This is the gap LENS™ surfaces in nearly every enterprise posture diagnostic — not a configuration problem, a structural one.

The IGA tools running in most enterprises today were designed around a specific assumption: that the actor requesting access is a human, that the access request is discrete, and that a human reviewer has enough operational context to certify whether that access is still needed. Those three assumptions are false for every AI agent, every MCP server credential, and every automated workflow token in your environment. None of those identities show up in your certification campaign. None have a named owner attached. None will trigger a lifecycle event when the project they served is deprecated. Your IGA tool is not failing — it is doing exactly what it was built to do. The problem is that what it was built to do no longer covers the perimeter it is supposed to govern.

The Governance Model Was Built for a Different Identity Surface

SailPoint IdentityNow's certification campaign architecture assumes a human reviewer has operational context on what an identity is actually doing in production. That assumption is structurally false for machine identity governance programs. A reviewer approving access for a service account sees an account name, a set of entitlements, and a last-used timestamp. What they do not see is whether that account is being used by a LangChain agent chain that calls four external APIs per task, or whether it is a credential embedded in a CI/CD pipeline that has not been accessed in 11 months and should have been deprovisioned when the project closed.

Microsoft Entra ID and Okta both solved the human authentication fragmentation problem — the era when each application managed its own credentials and identity was scattered across dozens of directories. What they cannot do is express what SACR analysts Kevin He, Lauren Place, and Shachar Ram identified as "runtime-bounded, intent-scoped delegation" — the access model that AI agents actually require. ("From Identity to Intent: The Rise of Intent-Aware Access Fabrics," SACR, Mar 2026.)

An agent does not need standing access to a database. It needs access to one table, for one task, for the duration of one session, and then that credential should not exist anymore. Issuing a standard OAuth token and expecting a certification campaign to catch over-permission 90 days later is not governance. It is latency. The same architectural gap that makes PAM tools blind to privileged access sprawl applies here at an order of magnitude greater scale.

The deeper failure is one of accountability architecture. IGA tools enforce governance by binding identities to owners and owners to access decisions. That binding only works if the identity was provisioned through the IGA tool in the first place. The OWASP NHI Top 10 (NHI1:2025 — Improper Offboarding) identifies the root failure: NHIs are deactivated inadequately or not at all when they are no longer needed, because the governance program that would trigger offboarding never knew the identity existed.

The Accountability Vacuum Behind the Green Dashboard

The structural failure is not negligence. It is that the identity provisioning motion and the governance motion operate on incompatible timescales, and no organizational design has resolved the ownership gap between them.

Engineering teams provision AI agent credentials at the speed of deployment pipelines — hours, sometimes minutes. The IGA governance cycle operates quarterly. Between those two clocks, every credential provisioned outside the IGA tool's visibility accumulates without an owner, without a rotation schedule, and without a lifecycle event that would trigger review. The OWASP NHI Top 10 names this directly: NHI7:2025 identifies long-lived secrets — API keys, tokens, and certificates with no expiration or expiration dates too far in the future — as a distinct, named risk category. Those are not edge cases. Per Astrix Security research, 79% of MCP server API keys are stored in environment variables, with no rotation enforcement and no centralized visibility.

The diagram below maps the IGA Governance Coverage Gap across two axes: identity provisioning velocity (from human-paced quarterly cycles on the left to machine-speed continuous provisioning on the right) and ownership accountability (from named human owner with lifecycle binding at the top to anonymous credential with no offboarding trigger at the bottom). The governance failure the diagram visualizes is the lower-right quadrant: AI agent credentials, MCP server tokens, and CI/CD pipeline secrets provisioned at machine speed with no ownership attribution — the space your IGA tool's certification campaign structurally cannot reach because it was designed for the upper-left.

Framework: IGA Governance Coverage Gap
Framework: IGA Governance Coverage Gap

What deflects accountability is the org design itself. Security owns the IGA tool. Engineering owns the deployment pipelines. Platform teams own the cloud IAM configurations. Nobody owns the intersection. When a credential lives in a GitHub Actions environment variable and authenticates to a cloud service via a role provisioned by an IaC template written by a contractor who left six months ago — it will never surface in a certification campaign, because it was never enrolled in the IGA system of record.

The Agent Layer Multiplies the Gap by an Order of Magnitude

The structural accountability vacuum documented above — an IGA tool that cannot see what it has not been pointed at — is now being compounded by a specific development: the proliferation of AI agents that provision their own downstream credentials as part of normal operation.

A LangChain agent chain executing a multi-step task inherits an OAuth token from the delegating user. It passes that token to sub-agents. Each sub-agent uses the token to call external APIs. The audit trail records that the delegating user executed the task. What it does not record is which sub-agents called which APIs, what permissions were actually exercised, or whether any of those downstream API calls created new credentials that are now sitting in a third-party system with no expiration. As He, Place, and Shachar Ram observed in their SACR analysis of runtime IGA: "Intent must be evaluated with each individual action at runtime, not only once when a policy is first defined." A periodic certification campaign evaluates access at a point in time. Agents operate continuously between those review cycles.

The scale of the unmanaged surface is concrete. Astrix Security's detection research identified a campaign in which malicious Chrome extensions disguised as AI productivity tools compromised over 900,000 users — capturing ChatGPT and DeepSeek conversations, session tokens, and proprietary engineering data, exfiltrating every 30 minutes. The 144:1 NHI-to-human identity ratio across enterprise environments makes this attack surface the default condition, not an edge case. Kobi Afuta, Head of Cyber Security at Guesty, described what Astrix surfaced: "Our team identified a suspicious NHI disguised as an official app." This is a named, documented attack campaign targeting exactly the identity surface your IGA certification campaign does not cover.

The governance impossibility is structural, not procedural. Astrix's analysis of 5,205 MCP server implementations found that only 8.5% implement OAuth — the authentication standard your IGA tool integrates with. The other 91.5% authenticate via static secrets or mechanisms your governance platform cannot reason about. You cannot certify access for an identity your IGA tool cannot read. Manual governance is structurally incapable of addressing this layer at autonomous agent provisioning velocity.

Three Disciplines That Make Accountability Permanent

The IGA tool is not the problem. The governance model that stops at the boundary of what it was designed to see is the problem. Three disciplines close the structural gap — not by replacing the IGA tool, but by extending accountability to the identity surface it cannot reach.

Continuous Discovery: You cannot govern what you have not inventoried — across cloud control planes, SaaS directories, CI/CD pipelines, MCP servers, and runtime metadata — in an environment where infrastructure is provisioned in hours, not quarters. Discovery must be continuous, not quarterly, and must extend to the identity surface that exists outside your IGA enrollment workflow.

Immutable Ownership Attribution: Every machine identity must be bound to a named human accountable party at the moment of provisioning — not retroactively assigned during a certification campaign six months later. Without this binding, lifecycle governance has no enforcement anchor and credential sprawl will always outpace remediation. OWASP NHI1:2025 (Improper Offboarding) is not a process failure. It is an ownership attribution failure.

Automated Least-Privilege Enforcement: Governance at the velocity of machine identity provisioning cannot be manual. Continuous controls must detect permission drift, enforce rotation policy, and revoke credentials on task completion — without requiring a ticket for each individual identity. Zero Standing Privilege is not a configuration choice. It is the only architecture that removes the target before the credential can be abused.

Actionable Knowledge Gap

Your IGA certification campaign was built to govern what it can see. LENS™ surfaces exactly what it cannot — the agent credentials, MCP server tokens, and pipeline secrets provisioned outside your IGA enrollment boundary that are accumulating in your environment right now.

Can you produce, right now, a complete inventory of every non-human identity in your environment — with named owner, last-used timestamp, and rotation status — including AI agent credentials, MCP server tokens, and CI/CD pipeline secrets that were never enrolled in your IGA system of record?

Assess Your NHI Governance Coverage and IGA Posture
Assess Your NHI Governance Coverage and IGA Posture

Take the Free IAM Posture Assessment — Find Out Where Your NHI Governance Actually Stands


Fayaz Mulla Syed is an IAM and Cybersecurity leader and practitioner who has spent 13+ years at the forefront of enterprise identity — architecting, delivering, and evolving IAM programs across Life Sciences, Healthcare, Automotive, and Telecom. He brings rare depth across the full identity stack: from privileged access and identity governance to zero trust architecture and cloud identity — having worked hands-on in some of the most complex, regulated environments in the industry. He is the founder of IAM Posture™ — a vendor-neutral scoring platform built to cut through vendor noise and give organizations a clear, architectural view of where their identity program actually stands.


IAM Posture™ assessments cover identity governance programs including IGA tool coverage gaps, NHI discovery completeness, and machine identity lifecycle accountability. IAM Posture™ receives no revenue from SailPoint, Microsoft, Okta, Astrix Security, or any vendor referenced in this post.

Discussion

No comments yet. Be the first to share your perspective.

Sign in to join the discussion.

Sign In

Zero-Trust Data Policy

We apply zero-trust to our platform data. We use essential cookies for security, cookieless telemetry for anonymous measurement, and functional cookies for preferences. You are in control.