A Complete Audit Trail That Names No One

An AI assistant reads four hundred documents across a tenant. Every read is logged. The application is named, the file is named, the timestamp is exact, and the access is attributed to an account that belongs to nobody.

‍

The audit trail is complete and it cannot answer the question an auditor asks. Nobody asks whether an access was recorded. They ask who reached the data and whether that person was authorized, and a shared service account answers neither.

‍

How Does the Grant Get This Broad?

‍

Usually through the vendor's own setup link, which is worth understanding because the architecture was chosen for the customer rather than by them.

‍

An onboarding link pointing at the administrative consent endpoint produces tenant-wide consent as the default path rather than as an escalation. An administrator clicking it approves the application for every principal in the organization at once. The permission prompt disappears from every user's path, which is presented as a convenience and is also the removal of the only safeguard an individual user had.

‍

Which Makes the Grant Permanent

‍

Tenant-wide consent survives whatever prompted it. The pilot ends, the team that requested the tool moves on, and the grant remains because nothing about a concluded project revokes an administrative approval. Grants outliving their purpose is the general pattern, and administrative consent is the version with the widest reach.

‍

Why Doesn't the Log Identify Anyone?

‍

Because the assistant runs unattended and therefore signs in as itself. To operate without a person present it uses a service account, and that account becomes the principal on every read.

‍

Service accounts collapse distinct actors into one technical identity. An external party using a leaked credential, an agent operating in a loop, and a legitimate employee request all appear as the same principal doing the same kind of thing. A monitoring system cannot separate them because there is nothing in the record to separate them by.

‍

What Does the Account Itself Tell You?

‍

Its usage pattern, which is informative and not attribution. An account signing in from several devices across multiple networks within a month is being used by more than one person or process, and it carries no manager attribute and no single human behind it. It establishes there is no owner rather than identifying one.

‍

Which Frameworks Treat This as a Finding?

‍

Most of them, and the finding is close to automatic once the arrangement is visible.

‍

Requirements to tie data access to an identifiable individual appear across common security certifications, health information rules and financial regulation. An access recorded against a shared account satisfies the logging requirement and fails the attribution one, which is a distinction assessors are practiced at drawing. The control looks present in a questionnaire and fails on inspection of a sample.

‍

Why Does It Survive Questionnaires?

‍

Because the question is usually whether access is logged. A program answering yes is answering accurately, and the follow-up question about whether logs identify the individual is the one that finds the problem. Anticipating that follow-up and recording the position deliberately is better than discovering it during fieldwork, which producing evidence on somebody else's timeline makes concrete.

‍

What Does Revocation Look Like?

‍

All or nothing, which is the operational consequence people discover during an incident rather than before one.

‍

A tenant-wide grant has no per-user dimension, so there is no way to remove one person's exposure while leaving the rest in place. Where a vendor is compromised or an agent behaves unexpectedly, the available action is withdrawing consent for the whole organization, which stops the tool for everyone including the people depending on it.

‍

Which Changes the Decision at Approval Time

‍

Granting tenant-wide consent is simultaneously accepting that the only containment available is a complete withdrawal. The trade is reasonable for some tools and a poor one for others, and it is a decision most organizations make without stating, because the consent screen does not describe it that way.

‍

What Is the Correct Architecture?

‍

Three changes, all established practice in identity engineering and all requiring the vendor to support them.

‍

• Scoped user consent: Delegated per user rather than granted tenant-wide, so the application's reach is bounded by each individual's own access.
• Per-agent identity: A distinct identity per workload rather than one shared account, so revocation and attribution both work at the level of a single actor.
• Token exchange rather than static credentials: Short-lived tokens issued on behalf of a named user rather than long-lived bearer tokens held by an account.

‍

The third is standardized and the standard has been available for years, so a vendor not implementing it has made a product decision rather than encountered a technical limit. Distinct machine identity is the precondition for the other two.

‍

What If the Vendor Doesn't Support Any of That?

‍

Then the practical choice is between tenant-wide consent and not using the tool, which is the part the remediation guidance tends to omit.

‍

Most AI application vendors today offer administrative consent and a service account, because that is the simplest integration to build and it works. Telling a security team to require delegated consent and token exchange is correct and does not help if the product on the procurement list cannot do it. The honest position is to make the trade explicit rather than to pretend a third option exists.

‍

What Makes the Trade Acceptable?

‍

Compensating for what the architecture removes. Scope the grant to the narrowest permission set the tool functions with, even where the consent is tenant-wide. Record what the account read, since a content audit establishes the scope of an exposure even when it cannot name a person. Set a review date rather than treating the grant as permanent. Then ask the vendor directly whether delegated consent is on the roadmap, since the answer belongs in the assessment.

‍

What Can the Content Audit Tell You?

‍

The scope of an exposure, which is the one question a shared account can still answer. Attribution fails and scoping does not.

‍

Where the platform records which files an application read, that record establishes how many documents were touched and which carried sensitive classifications. An exposure covering a handful of labeled files is a different notification question from one covering several hundred, and the distinction survives the absence of a named human. The account cannot tell you who, and the content record can tell you how much.

‍

Why Does That Matter More Than It Sounds?

‍

Because notification decisions turn on scope rather than on attribution. A regulator asking whether an incident is reportable wants to know what data was involved and how much of it. Being unable to name the individual is an audit finding, and being unable to scope the exposure is a materially worse position because it forces the conservative assumption, and the disclosure view of a loss figure depends on scope being establishable.

‍

Which Argues for Turning It On Before You Need It

‍

Content-level audit is frequently a licensing tier or a configuration rather than a default, so the records exist only from the point somebody enabled them. Enabling it after an incident produces nothing retrospective, which makes it one of the cheaper things to arrange in advance and one of the more expensive things to discover missing. A trail that stores only current state has the same property.

‍

How Do You Find These Grants Now?

‍

They are recorded, which makes this one of the more tractable problems in the category. The difficulty is that nobody looks.

‍

Enterprise application listings in an identity provider show which applications hold administrative consent, what permissions each was granted and when. Reviewing that list against the AI applications in use produces the population directly, and the exercise usually surfaces grants nobody remembers approving. Correlating each grant with whether it has been exercised recently narrows it further, since an unused permanent grant is the cheapest thing to remove, and an AI Interaction Data Fabric joins the grant record to the activity that shows whether anything is using it.

‍

What Should the Register Record?

‍

Four fields the usual template lacks. Whether consent is tenant-wide or delegated. Which account the application acts as. Whether any human is named against that account. Then what the containment option is, since knowing in advance that the only response is full withdrawal changes how the tool is deployed. An AI data fabric supplies the third and fourth from observed behavior rather than from the consent record.

‍

Logged Is Not Attributed

‍

A tenant-wide grant exercised through a shared service account produces a complete record that names no person, which satisfies a logging requirement and fails an attribution one. The grant arrives through a vendor's own setup link rather than as a deliberate architectural choice, removes the permission prompt that was the individual user's only safeguard, outlives the project that prompted it, and can be withdrawn only for everyone at once. Delegated consent, per-agent identity and token exchange are the right answer and require a vendor that supports them. Kovrr's AI Security and Governance Platform records which applications hold standing grants and whether any human is named behind them.

‍

To see which AI applications in your environment hold tenant-wide consent and act as accounts nobody owns, book a demo mapped to your own estate.