Your AI Agents Are Authenticated. They Are Not Governed.

The Automation Trust Gap is not an authentication problem. It is an identity control plane problem. Here is what the gap looks like inside a real Entra ID tenant.

By Albert Jee | IAM Consultant and Former Microsoft FastTrack Architect

The first question I ask when I walk into an NHI governance engagement is not about authentication. It is about ownership.

I was brought into a mid-market financial services firm last year. Their Microsoft Entra ID tenant was reasonably mature. Conditional Access policies were in place. MFA was enforced across workforce users. Privileged Identity Management governed their Global Administrator accounts. On paper, they had done the work.

Then I asked them to pull every service principal in the tenant and show me the owner for each one.

They came back with 1,200 service principals. Fewer than 40 percent had an accountable owner assigned. The rest were connected to projects that had closed, vendors that had been replaced, automation pipelines that nobody maintained, and three integrations tied to a SaaS platform the organization had fully decommissioned eight months earlier. One service principal had been calling the Microsoft Graph API daily for over two years. Nobody knew what it was doing. Nobody knew who had created it. Nobody had a revocation path for it.

That is The Automation Trust Gap.

It is not a gap in authentication. Every one of those service principals was authenticating successfully. The gap is in governance. The organization believed it governed machine access because it governed human access. Those are two different problems, and most enterprises have only solved one of them.

“It is not a gap in authentication. Every one of those service principals was authenticating successfully. The gap is in governance.”

Why Non-Human Identity Is Structurally Different

The governance model built for human access rests on assumptions so embedded in enterprise IAM thinking that most architects never question them. Someone is hired. A manager approves their access. They receive roles tied to a job function. An access review certifies their permissions on a schedule. When they leave, HR triggers offboarding, their account is disabled, and their access is removed. The lifecycle is imperfect in most organizations, but the model exists and it has organizational teeth.

Non-human identities operate outside that model entirely.

A service principal does not have a manager. An API key does not respond to an access review. A workload identity does not appear in an HR offboarding workflow. An OAuth application does not get disabled when the developer who created it leaves the company. An AI agent does not attend security awareness training or respond to an MFA push notification.

More importantly, non-human identities authenticate silently, operate continuously, and persist indefinitely unless someone actively removes them. A human user who has not logged in for six months is easy to identify and easy to justify disabling. A service principal that calls Graph API once a day, every day, for two years looks like normal automation activity right up until the moment it is not.

This is the structural problem. Human identity risk is tied to employment, behavior, device posture, and authentication strength. Non-human identity risk is tied to secrets management, delegated permissions, token lifetime, workload trust, API access scope, ownership gaps, and authorization drift over time. These are different risk surfaces, and they require different governance disciplines.

The Automation Trust Gap is what opens when an organization governs only one of them.

Why the Gap Is Accelerating Now

Three forces are converging to make this problem significantly worse.

The first is cloud automation. Every workload, function, container, service bus, and cloud-native component needs some form of identity to operate. Modern cloud architecture is better than the old perimeter model precisely because services authenticate to other services rather than relying on implicit network trust. But that architectural improvement creates more identities. Every integration point is an identity. Every automation step is an authorization decision. Every pipeline is part of the identity fabric.

The second is SaaS adoption. A mid-market enterprise today may have hundreds of SaaS applications connected to its tenant. Those connections are built on a sprawling web of OAuth grants, API tokens, webhooks, app registrations, service principals, and integration accounts. These are not theoretical identities. They hold real permissions, they call real APIs, and they persist in the tenant long after the SaaS contract ends or the use case changes.

The third force is AI agents.

An enterprise AI agent is not a static bot. Whether it surfaces as a custom application backed by an app registration, a SaaS extension running on delegated OAuth permissions, or a Copilot extensibility connector, a real production agent reads email, queries CRM data, updates tickets, calls APIs, invokes workflows, retrieves files, and interacts with downstream services. To do any of that, it needs access. That access must be represented as identity. And in most deployments today, that identity is created to enable a capability, not to satisfy a governance requirement.

The business asks: can the agent complete the workflow? The architecture team must answer: what identity does the agent use, what permissions does it hold, who owns it, how long does its access last, how is it monitored, and what is the revocation path if it is compromised?

In most deployments I have seen, the first question gets a meeting. The second question gets a ticket.

“In most deployments I have seen, the first question gets a meeting. The second question gets a ticket.”

Entro Labs measured this pressure quantitatively. Their H1 2025 NHI and Secrets Risk Report, which analyzed more than 27 million non-human identities across enterprise environments, found that non-human identities now outnumber human identities 144 to 1 across enterprise environments, up from 92 to 1 in H1 2024. The ratio nearly doubled in twelve months. AI agents did not cause that growth alone, but they are accelerating it, and they are adding a new identity class that was built for capability before it was built for governance.

What the Gap Looks Like Inside a Real Tenant

The 144 to 1 ratio is an industry aggregate. Inside a single mid-market Entra ID tenant, that aggregate becomes a specific number with a specific owner assigned to it, or more often, no owner at all.

A recent audit of a mid-market Entra ID environment produced these numbers. Total service principals inventoried: 1,284. Identities flagged as likely agent or automation identities based on naming, tagging, or automation indicators: 219. Service principals with no accountable owner assigned: 473. Objects rated high or critical risk based on credential age, permission grants, and ownership gaps: 86. Classification drew on service principal display names, owner assignment, app role assignments, OAuth permission grants, credential age, sign-in activity, and automation-specific naming patterns.

Those numbers are not unusual. They are representative of what governance debt looks like when human identity programs mature faster than machine identity programs.

The highest-risk finding in that audit was a service principal named Copilot-Agent-Workflow-Bridge. It had no owner. It held 14 permission grants, including Directory.ReadWrite.All and RoleManagement.ReadWrite.Directory. Its oldest client secret was 421 days old. Its name suggested an AI agent or workflow identity. Nobody on the security team knew who had created it or what it was authorized to do.

That object authenticated successfully every time it needed to. Authentication was never the problem.

The problem was that the organization had no way to answer the question that matters: if this identity were compromised tomorrow, what could an attacker do with it, and how quickly could we shut it down?

The answer, in that tenant, was: quite a lot, and not quickly at all.

The report format behind these numbers is a consulting deliverable I produce during NHI governance engagements. It inventories every service principal in the tenant, flags likely agent and automation identities, surfaces ownership gaps, scores credential risk by age and type, and outputs a prioritized remediation table. If you want to see what this looks like against your own environment, that is the conversation to have. Reach out via LinkedIn DM.

The Five Controls That Close the Gap

NIST SP 800–207 is direct on the foundational principle: Zero Trust assumes no implicit trust based solely on network location or asset ownership, and authentication and authorization are discrete functions performed before session establishment. That principle applies directly to machine identities. They are subjects in the access path even when no human is present. Extending it to non-human identities requires five controls.

1. Ephemeral and task-scoped access. Stop treating machine access as permanent by default. An AI agent should receive only the access required for a specific task, tool, resource, and time window. If the task is to summarize a document, the agent does not need broad mailbox access. If the task is to update a ticket, the agent does not need unrestricted access to the entire ITSM platform. Access should expire when the task is complete. That means short-lived tokens, just-in-time authorization, scoped permissions, and constrained delegation. Standing access is an exception, not the default.
2. Cryptographic binding and mutual TLS. A static client secret is a weak foundation for high-value automation. Once copied, it replays until rotated. Once embedded in a script, it is difficult to discover and remove. AI agents and workloads need key-bound credentials, certificates, workload attestation, managed identities, or signed tokens. The goal is to make the credential inseparable from the authorized workload. With managed identities and workload identity federation, the target is to eliminate long-lived shared secrets, constrain where tokens are minted, and reduce the replay value of stolen credentials. Issued access tokens still require short lifetimes, monitoring, and revocation discipline to complete the control.
3. Policy-based access segmentation. For AI agents, segmentation must be identity-aware and policy-driven, not just network-based. The agent should be constrained by what it is allowed to access, what action it is allowed to perform, which API it can call, which data classification it can touch, and which downstream delegation path is permitted. If an agent is compromised, the attacker should hit policy walls immediately. The goal is to make lateral movement an architectural impossibility by design, not a detection race after the fact.
4. Continuous monitoring and anomaly detection. NHI monitoring requires different telemetry than human identity monitoring. The signals that matter are API usage patterns, token issuance events, credential age, secret exposure, unusual resource access, privilege drift, abnormal call volume, new consent grants, and cross-environment activity. An agent designed to summarize support tickets should not enumerate privileged groups. A workload identity used by a deployment pipeline should not start reading financial records. Predictable behavior is a defensive asset. When the pattern changes, the control plane should know immediately.
5. Rapid revocation and kill switches. This is the capability you discover you lack during hour two of an active breach. Revoking a compromised NHI is not simply disabling an account. It requires revoking tokens, rotating secrets, disabling app registrations, removing delegated grants, invalidating certificates, breaking trust relationships, removing role assignments, and terminating active sessions or workflows. For AI agents operating through delegation chains, the visible agent identity may be only one layer of the blast radius. A mature architecture needs kill switches at the identity layer, the token layer, the application layer, and the resource layer. The control objective is straightforward: identify the identity, revoke its tokens, remove its permissions, rotate or invalidate credentials, and prove through logs that the access path is closed. If the organization cannot do that quickly and completely, it does not govern the agent. It observes it.

Governance Is the Missing Layer

The five controls are necessary. They are not sufficient. Authentication proves the workload can sign in. Authorization defines what the workload can damage. Governance determines whether anyone is accountable for that risk.

“Authentication proves the workload can sign in. Authorization defines what the workload can damage. Governance determines whether anyone is accountable for that risk.”

Every non-human identity needs an accountable owner, a documented purpose, a risk tier, a lifecycle state, an access boundary, a review cadence, and a revocation procedure. That list is not bureaucratic overhead. It is the minimum governance surface required to operate an identity with any degree of enterprise trust.

Most NHIs are created by projects, not governed by programs. In Entra ID, the NHI control surface spans application registrations, enterprise applications and service principals, app role assignments, OAuth delegated grants, credentials, owner assignments, sign-in logs, and directory roles. That surface is rarely owned by a single team.

A developer stood up an integration. A SaaS vendor configured an OAuth grant. A DevOps team created a service principal for a pipeline. An AI agent was deployed by a business team to automate a workflow. Each of those identities entered the tenant for a legitimate reason. None of them came with an owner, a lifecycle plan, or a decommissioning process.

AI agents make the governance gap visible in a way that service accounts never quite did, because agents operate across more systems, hold broader permissions, and produce consequences at a speed and scale that makes after-the-fact detection expensive.

An enterprise AI agent should not be approved through a business productivity lens alone. It should go through identity architecture review. The questions are straightforward: who owns this agent, what identity does it use, what systems does it access, what data classifications does it process, what permissions are standing versus just-in-time, what logs prove what it did, what happens when the owner leaves, how is access reviewed, and how is the agent disabled when the use case ends.

These questions do not block AI adoption. They secure it.

The Organizations That Get This Right

The Automation Trust Gap does not close by adding controls to a governance program that still treats human identities as the primary unit of risk.

It closes when identity governance extends to every identity class capable of accessing enterprise resources: human, privileged, guest, workload, service, application, bot, automation, and AI agent. That is not a future architectural goal. It is the current requirement for any organization operating AI agents at scale.

The enterprises closing this gap are not waiting for an audit finding. A service principal with 421 days of credential age, 14 standing permission grants, and no owner is not a theoretical risk. It is a present one.

The organizations that extend Zero Trust to non-human identities now will not merely secure their AI agents. They will have built the identity control plane that the next generation of enterprise security runs on.

About the Author

Albert Jee is an independent IAM consultant and former Microsoft FastTrack Architect with fifteen years of experience designing enterprise identity and access management solutions across financial services, healthcare, and mid-market organizations. He specializes in Zero Trust architecture, Microsoft Entra ID, non-human identity governance, and AI agent identity risk.

If your organization has deployed AI agents or automation at scale and you need to know what those identities are doing, what they have access to, and whether you have a revocation path, that is the engagement. Connect on LinkedIn or reach out directly via LinkedIn DM.