The AI identities your firm has never audited

Your firm knows how to offboard a person. Badge returned, accounts disabled, access revoked, and someone signs off that it happened. Now answer the same question about the AI assistant connected to your inbox, the agent reading your document store, and the automation with a key to your calendar. Who approved that access, what exactly can it reach, and what happens to it when the vendor changes hands? Most firms cannot answer, because these identities were never treated as identities at all.

An AI agent is an employee with credentials and no HR file

When a firm connects an AI tool to a system, it issues access. Sometimes that is an API key, sometimes an OAuth grant, sometimes a service account with a password nobody has rotated. The tool then reads, writes, and acts on that access, often continuously, and frequently with broader permission than any single human in the firm holds.

Security teams call these non-human identities. The term is unglamorous and exactly right. They authenticate, they hold privilege, and they take actions attributable to your firm. What they lack is everything the firm built around human access: an approval step, a review cycle, a named owner, and an offboarding process.

Why this gets past firms that are otherwise careful

AI access is usually granted in the flow of doing something useful. Someone connects a scheduling assistant. A partner authorizes a research tool against the document library. A marketing contractor links an automation to the CRM. Each decision is small, reasonable, and made by someone acting in good faith.

The problem is that none of those decisions passed through the process that governs human access, because the tool did not look like a person. There was no onboarding form. There was no manager approval. And critically, there is no departure date, so the access persists long after the project, the contractor, or the tool's usefulness has ended.

Start with discovery, because the list is longer than you think

The first step is not policy. It is an inventory, and it should cover every place AI touches firm systems, including the ones nobody announced. Look in four places:

• Integrations and connected apps in your email, calendar, document store, and CRM. Each one is an identity.
• Browser extensions staff have installed, which often read every page including client matters.
• Automations and workflows built by staff or contractors, running on credentials that belong to whoever set them up.
• Vendor AI features switched on inside software you already pay for, which may process your data under terms nobody reread.

Then narrow what each identity can reach

The default for most AI integrations is broad access, because broad access makes setup easy and demos impressive. The correct posture is the same one you apply to people: least privilege. An intake agent needs new inquiries, not the full matter archive. A scheduling assistant needs calendar availability, not the contents of appointments.

This is where the work pays off beyond security. Narrowing access usually improves the AI's output, because a system pointed at a defined, relevant set of documents gives better answers than one grazing across everything the firm has ever stored. Precision and safety pull in the same direction here, which is rare.

Log what the agent did, not just that it connected

An access list tells you what was possible. A log tells you what happened. For any AI touching confidential material, you want a record of what it read and what it produced, retained long enough to answer a question that arrives months later.

This matters most in the situation you hope never arrives. A client asks whether their information was processed by an AI system, or a regulator asks how a particular output was produced. Firms with logs answer in an afternoon. Firms without them begin an investigation with no starting point.

The offboarding question nobody asks

Every AI identity needs an end condition defined when it is created. What revokes this access, and who is responsible for pulling it? Reasonable triggers: the project concludes, the staff member who owns it leaves, the vendor is acquired, the contract lapses, or the annual review finds it unused.

Without an end condition, access accumulates. The realistic failure is not a dramatic breach. It is a credential from an abandoned tool, still valid three years later, still able to read client files, owned by nobody, and invisible in every report leadership sees.

How Aday Interactive, Inc. runs the inventory

Our AI Governance Audit starts here, because you cannot govern what you have not found. We map where AI is already in use across the firm, what each identity can reach, who owns it, and what revokes it. The output is a list with names attached and an access posture for each entry.

Firms are consistently surprised by the count. The surprise is the point, and it is better delivered by your own review than by a client asking a question you cannot answer.