AI Service Accounts: The Identity Gap Nobody Closes

Here is a pattern I have watched repeat itself across enterprise environments for the last three years: a team adopts a new AI tool, IT provisions access, and nobody asks who — or what — is actually authenticating after day one.

The answer is usually a service account nobody owns, an OAuth token with no expiration date, and permissions scoped to “whatever the vendor asked for” during setup. That is an AI access control gap, and it is sitting in your environment right now.

After 25 years in enterprise IAM and security, I have seen this class of problem before. Shadow IT created it in the 2010s. SaaS sprawl amplified it after that. AI tool adoption is doing it again — faster, at greater scale, and with access to far more sensitive data than a forgotten Dropbox folder.

TL;DR

AI tools authenticate as non-human identities — service accounts, OAuth apps, API keys — that your standard IAM processes were never designed to govern. These identities accumulate excessive permissions, go unreviewed, and create persistent access that survives employee offboarding and vendor contract terminations. This post covers the specific gap, why it’s worse than previous generations of shadow IT, and what to audit this week.

Why AI Tool Adoption Creates an Identity Problem

When a human employee needs access to a system, most mature organizations have a process: request, approve, provision, review, revoke. It is imperfect, but the scaffolding exists.

When an AI tool needs access to a system, that process frequently does not apply. The tool authenticates via OAuth or an API key. The vendor’s setup wizard walks an admin through a “grant access” flow in about ninety seconds. The permissions granted are whatever the vendor’s application manifest requested — often read/write access to email, calendar, documents, code repositories, or ticketing systems.

What does not happen: a formal access request. A least-privilege review. An owner assignment in your identity governance system. A scheduled access recertification. A defined revocation procedure when the contract ends.

That OAuth token is now a non-human identity with standing access to sensitive systems, and it exists entirely outside your IAM lifecycle controls.

The Three Access Control Gaps AI Tools Consistently Create

I am not talking about theoretical risk. These are the specific gaps I see in practice.

1. OAuth tokens with no expiration and no owner

Most AI productivity tools — writing assistants, meeting summarizers, code review tools, workflow automation platforms — request OAuth access during initial setup. That token is tied to the authorizing user’s account, but it persists indefinitely. When that employee leaves, your offboarding process terminates their account. It does not necessarily revoke every OAuth grant they created. The token may continue functioning against shared resources, distribution lists, or document libraries the former employee had access to.

I have seen this exact scenario: a sales engineer departs, their account is disabled, but an AI deal intelligence tool they authorized nine months earlier continues pulling CRM data because the OAuth scope covered a shared service account, not their personal credentials.

2. AI agents running as over-privileged service accounts

Teams building internal AI workflows — using tools like n8n, Zapier, or custom agents — typically create a single service account to run the automation. That account gets whatever permissions are needed to complete the first use case. Then the second use case gets added. Then the third. The account accumulates permissions over time with no sunset, no review, and no scope reduction.

This is the AI-era equivalent of a shared admin account with a password in a sticky note. Except now it is an account that can read your entire knowledge base, write to your ticketing system, send email on behalf of the organization, and query your HR system — and it is running twenty-four hours a day.

3. Vendor-side access that survives contract termination

When you stop paying for an AI tool, your internal IT team disables the integration on your side. What they frequently do not do: confirm that the vendor has deleted your data, rotated or revoked the API keys you issued to them, and removed their OAuth application from your identity provider’s authorized apps list.

The vendor’s side of that integration may remain authenticated for months. This is not theoretical — it is a documented problem with SaaS vendors generally, and AI vendors are not exempt.

What Makes This Worse Than Previous Shadow IT

Shadow IT in the 2010s was mostly about data storage and collaboration — files sitting in personal Dropbox accounts, conversations happening in consumer messaging apps. Bad enough.

AI tool access is structurally different in two ways.

First, the access is active and ongoing. A forgotten Dropbox folder is passive. An AI tool with standing OAuth access is actively reading your email, ingesting meeting transcripts, analyzing code commits, or querying your CRM every time it runs. The exposure compounds with every execution.

Second, AI tools are frequently granted access to aggregated, high-value data sources. An AI meeting intelligence tool does not just see one meeting. It sees every meeting. An AI code review tool does not just see one repository. It sees your entire codebase. The blast radius of a compromised or over-retained access grant is substantially larger than a stale file share.

The Audit You Should Run This Week

This is the checklist I would apply to any environment I was reviewing:

OAuth application inventory

• Pull the full list of authorized OAuth applications from your identity provider (Okta, Azure AD, Google Workspace — all of them have this report)
• Filter for any application with AI, assistant, copilot, intelligence, or agent in the name
• For each: identify the authorizing account, the scopes granted, the last activity date, and whether the authorizing employee is still with the organization

Service account review

• Query your directory for service accounts created in the last 18 months
• For each: identify the owning team, the current permission scope, and whether there is a documented least-privilege justification
• Flag any service account that has accumulated permissions across more than two systems

API key audit

• Check your secrets management system (or, if you do not have one, your CI/CD configuration files, environment variable stores, and code repositories)
• Identify API keys issued to AI vendors or AI automation platforms
• Confirm each key has a defined expiration date and a documented owner

Vendor offboarding verification

• For any AI tool contract terminated in the last 24 months: confirm the vendor has removed OAuth authorization, deleted retained data per contract terms, and that no active API keys issued to that vendor remain valid

What Governance Looks Like When It Is Working

The fix is not “stop adopting AI tools.” The fix is applying the same identity governance discipline to non-human identities that you apply (or should apply) to human ones.

That means: every AI tool integration gets a formal access request that documents the scopes required and the business justification. Every service account running an AI workflow has a named human owner accountable for it. OAuth grants are reviewed on a quarterly access recertification cycle. API keys expire — ninety days maximum in a security-conscious environment. Vendor offboarding is a checklist that explicitly includes identity and access cleanup.

None of this is novel IAM theory. It is established practice applied to a category of identity your existing process did not anticipate.

Key Takeaways

• AI tools authenticate as non-human identities — service accounts, OAuth apps, API keys — that your IAM lifecycle processes typically do not govern
• The three most common AI access control gaps: OAuth tokens with no expiration or owner, over-privileged service accounts accumulating permissions, and vendor-side access surviving contract termination
• AI tool access is more dangerous than prior shadow IT because it is active, ongoing, and typically scoped to high-value aggregated data sources
• The audit starts with your OAuth application inventory in your identity provider — pull it this week
• The governance fix is standard IAM discipline applied to non-human identities: ownership, least privilege, recertification, and documented offboarding

If your organization has a mature IAM program for human identities and no equivalent program for AI service accounts, you have a gap. The tools are already in your environment. The access is already granted. The question is whether you know what it covers.