Your AI Vendor Holds a Key, Not Data

A director of operations signs up for an AI meeting assistant on a Tuesday afternoon. The consent screen asks to read her calendar, join meetings on her behalf, and reach the files she can reach. She clicks Allow, because the alternative is failing to evaluate the tool she was asked to evaluate. Nothing in that moment triggers a vendor review, a contract, or a conversation with IT.

Three floors away, procurement is in week three of a security questionnaire long enough to need its own project plan — for a different AI product that will read exactly one exported spreadsheet.

Both are real controls. Only one is pointed at the actual exposure. That mismatch is the shape of AI vendor risk in 2026, and it is not a story about careless vendors. Due diligence built for software that stores your data is being applied to software that acts with your identity.

The questionnaire audits the vendor's building, not your keys

A SOC 2 Type II report and an ISO 27001 certificate describe how a vendor runs its own control environment: change management, access reviews, encryption, incident response. Useful information, and a vendor who cannot produce it deserves scrutiny. Read the sentence carefully, though. Those are facts about the vendor. They are not facts about you.

The traditional question — where does our data live, who can see it, how is it encrypted — assumes a one-directional relationship. You send data out, the vendor holds it, and your exposure equals the size of the pile you sent.

AI tools inverted that. A modern AI application does not primarily want a copy of your data. It wants standing, delegated authority to reach into your environment and retrieve what it needs, whenever it needs it, under the identity of the person who approved it. The pile never leaves. Only the key does.

This is analysis rather than a measured finding, and it is easy to test inside your own organization. Pull the last three AI security reviews your company completed and look for two artifacts: the list of permission scopes the application requested, and the tenant audit log showing what it has done since. If neither is in the packet, the review examined someone else's infrastructure and called it your risk assessment.

Ask what the token can do on a bad day

Reframe the first question. Not "is this vendor secure," which nobody can answer honestly, but "assume this vendor is breached on a Thursday — what does the attacker inherit?"

That question has a precise answer, and it is written in the permission scopes granted to the application. In a Microsoft 365 environment, an app holding delegated permissions scoped to one user's mailbox and an app holding tenant-wide application permissions are different orders of risk: a contained incident versus reach across the entire corpus. Both look identical on a vendor's trust page. Neither appears on a pricing sheet.

Questions worth asking before signature:

• What exact permissions does the application request, and which of them are optional?
• Can it function with delegated, user-scoped access instead of tenant-wide access — and if not, what in the architecture requires the broader grant?
• Does it require admin consent, and who in our organization is permitted to give it?
• Can the grant be scoped to a security group rather than the entire directory?

A vendor that can operate under narrowed permissions, and helps you narrow them, is telling you something real about how the product was built. When the answer is "full access makes the experience better," that is also telling you something real.

Then follow the chain. Most AI products are not AI companies; they are applications sitting on foundation models licensed from someone else, sometimes several someone elses depending on the task. Ask which model providers process your content, under which commercial tier, what the retention window is at each hop, and whether prompts and outputs are used for training — and whether that answer is a contractual commitment or a setting someone can toggle. Ask what happens when the vendor changes models, because a swap can move your data to a new processor under new terms with no amendment to your agreement. A change-of-subprocessor notice clause is worth more in an AI contract than most of the encryption language above it.

Autonomy is a security property, not a pricing tier

The category shift of the last two years is that AI tools stopped summarizing and started doing. Sending the email. Updating the record. Routing the invoice. Moving the file. Vendors market this as capability. Treat it as a control question.

Three properties determine whether an acting agent is governable. Reversibility: can an action be undone, and does the product tell you which actions cannot be. Approval gates: can a human be required in the loop for a defined class of actions, configured by you rather than by vendor default. Attribution: when the agent acts, what does the log say.

Attribution is the sleeper. If an agent operates under a human's delegated identity, your audit trail may show a user performing actions the user never performed. During an investigation, that destroys the timeline you were going to use to reconstruct what happened. Any IT security program built around identity as the perimeter should require that agent actions are distinguishable from human actions in the log before the tool touches production.

Machine identities do not resign

Run the offboarding before you sign. When the contract ends, what happens to the service principal, the API keys, the refresh tokens, and the derived data — the embeddings and indexes built from your documents that are no longer your documents in any recognizable form? Deletion of source content and deletion of everything computed from it are separate commitments, and usually only one of them is written down.

Consented applications persist quietly in a directory long after the person who approved them has moved on, still holding whatever they were granted. Nothing prompts a review. The grant has no expiry and no exit interview. A quarterly walk of the consent register — every application holding a token, what that token reaches, who approved it, when it was last examined — is, in our judgment, among the highest-return hours available to a mid-sized company. It costs an afternoon. Much of what it surfaces will be tools somebody trialed once and forgot.

Where AI vendor risk should actually live

The executive decision here is not which AI vendor is safe. It is where this category of risk gets governed. Housed in procurement, you will get thorough answers about someone else's data center while consent grants accumulate in your tenant unreviewed. Housed in identity governance, the picture inverts: you hold a register of every application with a key, what that key opens, who granted it, and when anyone last looked.

Two changes make that real, and neither requires new spend. Restrict admin consent to a small named group, so granting tenant-wide access becomes a decision rather than a click. Require that any AI tool with write or send authority logs agent actions distinguishably from human ones. Ownership is the harder part. Self-service adoption selects for precisely the tools that skip review — that is arithmetic, not a criticism of anyone's diligence — and the first visible symptom often arrives as a user question to the help desk: why is this app asking for an administrator to approve it?

Pro Link Systems has served Los Angeles businesses since 1999, from Woodland Hills. If you want a second read on the AI applications already holding permissions in your environment, our managed IT services team will walk the consent register with you.