IGA Solutions Retrofitted for Service Account Sprawl
Identity governance and administration platforms were built on assumptions so deeply embedded in their architecture that they rarely surface in vendor documentation. They're simply the shape of the problem IGA was designed to solve, and for decades, that shape fit.
The foundational assumption is that identities belong to people who join, move, and leave. HR events drive provisioning and deprovisioning. An employee is hired, an account is created; a role changes, entitlements are updated; an employee departs, access is revoked. The entire lifecycle management apparatus depends on this chain. Service accounts have no equivalent. They're created by developers or automation pipelines, not HR, and they carry no offboarding trigger. They persist long after the workload they served is retired, holding permissions that no one has reviewed since the sprint in which they were written. I have seen service accounts in production environments carrying entitlements from projects that were formally cancelled two years prior. Nobody was ignoring them deliberately. They were simply invisible to the system designed to catch exactly that problem.
Two further assumptions follow from that foundation. First, IGA treats access as intentional and attributed. A human requests access, a manager approves it, and the request record creates an accountability trail. Agents and service accounts act on behalf of systems, not named humans. There's often no approver who understood the full entitlement at creation, let alone one capable of reviewing it years later. Second, periodic recertification is assumed to be meaningful. A manager reviewing a quarterly access report can, in principle, make an informed judgment about whether a direct report still needs the listed entitlements. Ask that same manager to certify a service account they didn't create, running a process they don't own, and they approve it. Every time. The review produces a compliance artifact, not actual assurance. Certification theater is a recognized problem in human access governance; for service accounts, it's essentially the only outcome available under a traditional IGA workflow.
A fourth assumption: privilege is bounded by role. RBAC maps onto job function and stays stable enough to review quarterly. AI agents need concurrent access to dozens of tools, with permissions that are task-specific and session-scoped. Static role definitions can't model that without producing unmanageable role proliferation, and every organization that has tried to maintain manual business roles at enterprise scale collides with the same compounding problem eventually.
The blast radius asymmetry is what makes all of this consequential. A compromised human account carries one person's access. A compromised service account or agent carries persistent, broad, automated access across dozens of systems simultaneously, executing operations at machine speed, without any of the friction a human attacker faces. Permissions accumulate indefinitely on service accounts because there's no last-login signal HR cares about, no periodic password reset prompting review, no offboarding event to close the loop. The blast radius grows with them, quietly.
How Shadow AI Turns the Retrofit Problem Into a Governance Blind Spot
Shadow IT was a governance problem of volume and visibility. Employees were using SaaS applications the enterprise hadn't sanctioned. Shadow AI is categorically different. It's not just ungoverned software; it's ungoverned software that itself acts as an access intermediary into governed systems.
When an employee connects an external AI assistant to corporate email or cloud storage through an OAuth grant, that AI application becomes a functional service account analogue. It has read and sometimes write access to enterprise data. It operates autonomously on behalf of the employee. It can persist that access indefinitely. IGA has no record of it, because OAuth grants made through browser-based SaaS sit entirely outside the provisioning workflows IGA monitors.
Standard IGA controls don't catch this. Network and firewall logs miss most of it, because AI usage is browser-based and embedded in SaaS the enterprise already permits. IGA access reviews don't surface OAuth applications as identities; they surface users and roles. The OAuth grant that gave an external AI access to a SharePoint tenant is invisible to the access review campaign running against that tenant.
The compliance consequence is concrete. Customer PII and proprietary source code routinely surface in prompts sent to external AI services. The AI vendor in that picture is a third-party data processor whose data retention and training behavior is opaque to the enterprise's governance program. By the time an incident is identified, the IGA program has no mechanism for determining what happened, when, or what data was involved, because the audit trail doesn't begin until a governance layer exists that recognizes the AI application as an identity. Traditional IGA does not.
Shadow AI doesn't merely expand the non-human identity surface. It actively conceals it from the tools enterprises are already relying on to govern access. That distinction matters, because concealment is harder to remediate than expansion.
Where the Audit Trail Breaks When AI Agents Act Across Systems
IGA audit trails assume discrete, attributed actions. A human user performed an operation, at a specific time, on a specific resource, under a specific role. That assumption holds when the actors are humans. It breaks when the actors are agents.
An agent executing a single logical task invokes multiple tools in sequence: read a document, query a database, transform the result, post it to a collaboration platform. Each tool call is a separate system event, potentially crossing multiple audit logs in multiple systems. The agent is often acting under a shared service account, so each log entry records the credential used, not the user who initiated the session or the intent behind it. In real incident investigations, I've watched engineers spend days reconstructing what an agent actually did from logs that were technically complete and operationally useless. The events were all there. Nothing in them explained what actually happened.
MCP-connected agents compound the problem. An agent connected to multiple MCP servers can invoke tools across dozens of services in a single session. Without a layer that captures the full invocation chain, the audit record is a series of disconnected entries rather than a coherent account of what occurred.
Prompt injection makes this more acute. An agent can be redirected mid-session by malicious content embedded in a document it processes. The action that follows is recorded under the agent's identity, but it wasn't initiated by any authorized user and wasn't within scope of the original task. The audit log is technically accurate and substantively misleading. That's a difficult position to defend under examination.
SOC 2, HIPAA, and equivalent frameworks require evidence that access was appropriate and reviewed. A recertification stamp on a service account that subsequently executed thousands of unrecorded tool calls doesn't satisfy that standard. The distinction that matters is between an access record and an invocation record. IGA produces the former. Compliance for agentic systems requires the latter, and that's not a configuration gap. It's an architectural one.
What the MCP Protocol Surface Means for Credential and Permission Sprawl
The Model Context Protocol addresses a genuine integration problem. Before MCP, connecting an AI agent to enterprise tools required custom integrations for every agent-tool combination, an N×M problem that scaled poorly. MCP reduces that to a single protocol: any compliant agent can connect to any compliant tool server. The efficiency gain is real.
The governance side effect is equally real. Without a governed layer in front of it, MCP shifts credential management from application developers to individual agents and their configuration files. Each agent carries its own API keys, OAuth tokens, and service account credentials for every server it connects to. Those credentials end up scattered across environment variables and config files, outside any managed secret store. Security researchers documented a significant number of unique secrets exposed in MCP configuration files in 2025 alone, with database connection strings and third-party API keys among the most common types. This isn't a novel problem. It's the same secret sprawl problem the industry spent years solving for human developers, now reproducing itself one layer up.
The permission model mismatch compounds this. MCP tools expose capabilities at the function level; IGA manages access at the application or role level. A service account granted access to an MCP server implicitly has access to every tool that server exposes, regardless of what the agent actually needs. The least-privilege principle IGA enforces for human users isn't being applied to agents. The gap between what an agent is permitted to do and what it needs to do is the attack surface.
Supply chain risk enters through MCP server dependencies. MCP servers are software packages, and vulnerabilities in widely used packages expose every agent and service account connecting through them. A patched vulnerability in a commonly used MCP remote package emerged in 2025, confirming that the attack surface extends to protocol infrastructure itself, not just the agents sitting on top of it.
MCP also introduces a category of risk IGA was never designed to address: financial exposure through unrestricted tool invocations. MCP enforces no budget or rate limits. An agent can trigger paid API operations at arbitrary scale with no control ceiling. Financial governance is now an operational requirement for agentic systems, and it has no home in traditional access governance architecture.
Why Leading IGA Vendors Are Extending Rather Than Rebuilding, and What That Leaves Uncovered
The IGA market's response to the non-human identity problem has been extension, not reconstruction. Platforms like SailPoint Identity Security Cloud and Saviynt have added AI-driven analytics, risk-based access review, and automated role mining. These are genuine improvements. They reduce the operational overhead of access certification, accelerate audit cycles, and surface anomalous access patterns that manual review would miss. The investment these vendors have made in that direction deserves acknowledgment.
But they operate on the same underlying data model. Identities are still primarily human. Lifecycle events still drive workflow. Service accounts are still treated as edge cases rather than first-class objects. AI-recommended role patterns help manage RBAC complexity for human users; they don't address the dynamic, session-level permissions that AI agents require. Automating a recertification workflow that was never designed for service accounts produces faster rubber-stamping, not substantively better governance. The problem was never speed.
Gartner's 2025 IGA Market Guide explicitly calls out re-mapping governance requirements for different actor types as a step IAM teams must now take. That observation reflects a structural reality: unified governance across human users, service accounts, API keys, and AI-mediated access paths requires separate governance models for each actor type. A single extended model with additional fields appended isn't the same thing, even when it's marketed as one.
The fragmentation this creates is expensive and persistent. Organizations end up governing human access through IGA, managing API keys through a secrets manager, handling cloud workload identity through a separate cloud-native tool, and leaving MCP-connected agents largely ungoverned. No single dashboard surfaces the complete picture. IGA vendors are optimizing the layer they own, and doing it well. The agentic identity layer sits above or alongside that layer and currently has no equivalent governance infrastructure at comparable maturity. That gap isn't a criticism of IGA vendors. It's a description of where the market actually stands.
What Governance Infrastructure Purpose-Built for Non-Human Identity Actually Needs to Do
The functional requirements for governing non-human identities are specific, and they define what IGA retrofits can't reach.
Real-time identity propagation is the starting point. Every agent action must execute under a specific, attributed identity, not a shared service account. The audit log must capture who authorized the session, not just which credential was used. This requires a governance layer that intercepts agent-to-system connections before they execute. A reporting layer that reviews them afterward isn't a substitute.
Tool-level permission enforcement must reach down to the individual MCP tool or API operation. Access policy that stops at the server or application boundary leaves the actual attack surface unaddressed. An agent granted access to an MCP server should be granted access to the specific tools it requires for the specific task at hand, nothing beyond that, and those permissions shouldn't carry forward into the next session. Session-scoped credentials eliminate the persistence that makes service account compromise so costly. Centralized credential management means API keys and OAuth tokens live in a governed store, rotating without breaking running agents, which requires the governance layer to handle token refresh transparently.
Threat detection must operate at the protocol layer. Prompt injection defense can't depend on the agent to detect and resist manipulation; it must sit in the access layer, between the agent and the tools it calls. PII and secrets leakage detection must operate on the content of tool calls, not just the metadata of who made them. Shadow MCP usage, agents connecting to ungoverned servers, requires active detection rather than periodic review.
Observability must be treated as a governance input, not a reporting afterthought. Invocation-level audit logs that reconstruct the full action chain across a session are the foundation of meaningful compliance evidence for agentic systems. Cost and usage telemetry per agent, per tool, and per team is a governance requirement, not an operational convenience.
What this describes is an AI control plane: a governed layer that sits in front of MCP servers and AI agents the way an API gateway sits in front of internal services. SpeakeasyAPI is built around this architecture, federating with existing identity providers such as Okta and Entra ID while adding the agent-specific controls, invocation-level audit trails, and real-time policy enforcement that IGA platforms don't generate. It's one of a small number of platforms approaching the non-human identity problem from this direction rather than extending existing access review workflows. The category is early. The requirement is not.
How to Assess Whether an IGA Retrofit Is Sufficient or Whether a Separate Governed Layer Is Necessary
The conditions under which an existing IGA investment is sufficient are real, but narrow.
A retrofit holds when non-human identities are a small, static, well-documented set of service accounts with clear ownership and no agentic behavior; when AI tool use is limited to a few sanctioned applications with no MCP or API-level integration into internal systems; when compliance requirements are satisfied by access grant evidence rather than invocation-level evidence. Those conditions exist. Organizations in that position shouldn't engineer a solution to a problem they don't yet have.
A separate governed layer becomes necessary under a different set of conditions. When agents are actively connecting to internal APIs, databases, or SaaS systems through MCP and invocation logs either don't exist or aren't attributed to specific users. When teams are spinning up agents independently without central review. When recertification campaigns for service accounts produce approvals from owners who can't describe what the account does, which, in my experience, is the majority of such campaigns once an organization reaches meaningful AI deployment scale. When credentials for agent tool access live in configuration files, environment variables, or on developer laptops rather than in a managed store. In organizations with active AI development programs, these conditions aren't edge cases. They're the norm.
The diagnostic question worth asking directly: does your current governance program produce an invocation record, or only an access record? If the answer is only the latter, the non-human identity surface is ungoverned regardless of what the IGA dashboard reflects. The dashboard shows access grants. It doesn't show what those grants were used to do, by whom, in what sequence, or at what cost.
Governed AI adoption at enterprise scale doesn't require replacing IGA. IGA does its job. The requirement is acknowledging, honestly, that it was architected for a different identity surface, and then building the layer that covers what it structurally can't reach. Knowing precisely where that seam falls is the only basis for a governance program that's accurate about what it actually covers.
