Approved Tools, Unapproved Agents

Approval works at the tool layer and it works well. A platform is assessed, terms are reviewed, a data processing agreement is signed, the tool enters the register, and named identities are entitled to it. Everything about that maps cleanly.

‍

Then somebody uses the approved platform to assemble an agent that acts on their behalf, with its own reach and its own credentials. The approval covered the application. Nothing covered what was built with it, and the unit the organization approves has stopped being the unit that carries risk.

‍

What Did the Approval Cover?

‍

The vendor and the container. Whether the company handles data lawfully, encrypts it, holds the right certifications and will sign the right agreement.

‍

None of that speaks to what an employee builds inside it the following week. The workflows, the connections to other systems, the write permissions, the credentials assigned to the automation and the actions it takes unattended are all created after the assessment concluded and none of them was assessed. A platform cleared to read documents can host an agent given a key that writes to a production system, and the clearance says nothing about the second thing.

‍

Which Is Not a Failure of the Approval

‍

The assessment answered the question it was asked correctly. Nobody assessing a vendor in March can assess an automation built in June, and treating this as a procurement oversight leads to longer vendor questionnaires that do not help. The mismatch is in the unit rather than in the rigor.

‍

Why Can't the Inventory Catch Up?

‍

Because it is structurally behind rather than slow, and running discovery more often does not close the distance.

‍

Discovery finds applications. It works by noticing a new vendor, a new domain, a new sign-in, a new expenditure line or a new registered application. An agent built inside a sanctioned platform produces none of those, because there is no new vendor, no new destination and no new procurement event. The traffic goes where it already went.

‍

So the Discovery Mechanism Is Looking for the Wrong Thing

‍

An inventory scan reads the builder platform as sanctioned and compliant, which it is, and reports one asset. Underneath it may sit dozens of automations with their own connections and credentials, none of which registers as an asset because none is an application. The mechanism is not failing, it is answering a question about applications in an environment where the risk-carrying object is something else, which deciding what counts as one asset has to settle before any inventory means anything.

‍

Is the Builder the Owner?

‍

Usually not, and this is where an approval mechanism for agents most often breaks.

‍

Somebody assembling an automation for their own workflow has solved a problem for themselves. They have not accepted accountability for a system, do not consider themselves to have created a governance object, and in most cases would be surprised to learn they had. An approval process assuming the builder will register what they built rests on an assumption that person does not share.

‍

Registration Cannot Be Voluntary

‍

A voluntary route captures the builders who already think in governance terms, which is a small and unrepresentative subset. Where the platform can report what exists, the register should be populated from the platform rather than from the people, and an approval gate only functions where somebody knows there is something to approve.

‍

What Would an Agent Approval Record?

‍

Five things, and none of them appears on a vendor questionnaire.

‍

• Builder and owner, separately: Who assembled it and who is accountable for it, since those are frequently different people and the second is often nobody.
• Enumerated reach: Every system, data store and interface the agent can touch, listed rather than described.
• Whose identity it acts under: The builder's own credentials, a shared account or its own, which determines whether its actions are attributable.

‍

The remaining two are irreversibility and a retirement trigger. Which of its available actions cannot be undone, decided per connection rather than per agent. Then what event ends it, since an automation built for a project outlives the project by default. Nothing on that list requires assessing the vendor again, which is the point.

‍

Where Is the Leverage?

‍

The platform's own administrative surface, and this is the unusual case in the shadow AI category where the population is directly enumerable.

‍

Most ungoverned AI use has to be discovered from traffic because nobody holds a list. Agents built inside a sanctioned platform are different, because the platform knows exactly what was built in it, who built it, what connections each holds and when it last ran. The information is available through an administrative interface rather than through inference, which makes this problem more tractable than the rest of the cluster and considerably less examined.

‍

Why Does Nobody Query It?

‍

Because the platform is on the approved list, so nothing prompts anyone to look inside it. The inventory records it as sanctioned, the vendor assessment is complete, and the file is closed. Agent sprawl is usually discussed as a volume problem when the harder half is that the volume is invisible. Running that query once usually produces a number that surprises the people who approved the platform, and an AI Interaction Data Fabric joins that list to the identities and connections behind each entry.

‍

Which of These Agents Matter?

‍

A minority, and treating them uniformly is the mistake in both directions. Most are harmless productivity automations doing something a person would otherwise do by hand.

‍

The population worth attention is defined by two properties. Write access to any system of record, since a read-only automation is bounded by what its builder could already see. Second, reach into regulated or confidential data, since that determines whether a failure becomes a notification question. An agent with neither is a scripting convenience, and an agent with both deserves the same treatment as any other system that can change production data.

‍

What About Agents Reading External Content?

‍

A third category worth separating. An automation processing inbound documents, emails or invoices is reading content an outsider controls, so instructions can arrive inside the material it was built to summarize. It is a smaller population than the write-access group and it carries a different exposure, and treating injection as a standing condition applies directly to it.

‍

Does the Agent Act as the Builder or as Itself?

‍

A question with two answers and very different consequences, and builder platforms differ on which they use.

‍

Where the automation runs under the builder's own credentials, its reach is bounded by that person's access and every action appears in logs as theirs. Attribution works and the blast radius is whatever the individual could already do, which is a genuinely safer arrangement than it sounds. The awkwardness arrives when they leave, because the automation stops or continues under a credential belonging to a former employee.

‍

Where the automation holds its own credential, it can be given reach the builder never had, including a key to a system they cannot access personally. Attribution then names the automation rather than a person, and the reach is whatever somebody granted it rather than whatever the builder was entitled to.

‍

Which Should You Prefer?

‍

Builder-bound for most cases, since it caps reach at something already assessed and keeps actions attributable. Own-identity where the automation genuinely needs access no individual should hold, provided it comes with a named owner and a recorded scope. The failure mode is own-identity by default, which is what several platforms do because it is operationally simpler, and distinct machine identity is only an improvement when somebody records what it holds.

‍

What Can Be Done This Week?

‍

Three steps, and the first takes an hour.

‍

Query the administrative surface of every approved AI platform that permits building, and count what exists. Sort the result by whether each automation has write access and whether it reaches sensitive data, which produces the population that needs owners. Then assign an owner distinct from the builder for that subset, since an automation with a named accountable person behaves differently from one without, and accountability for what an agent does resolves to a person or resolves to nobody.

‍

What Changes in the Approval Process?

‍

One question added at the platform stage. Whether the tool permits users to build automations that hold their own connections, and if so, who will hold the register of what gets built. Answering that before approval is a sentence. Answering it afterward is the exercise above, and an AI data fabric keeps the register current once somebody has established it.

‍

The Approved Object and the Risky Object Are Different

‍

Approval assesses a vendor and a container, correctly and completely, and says nothing about the automations somebody assembles inside it later. The inventory cannot close that distance by running more often, because discovery looks for new applications and an agent built in a sanctioned platform is not one. The builder is rarely the owner and usually does not know they created a governance object, so voluntary registration captures the wrong subset. What makes this more tractable than the rest of the category is that the platform holds the list, and almost nobody asks it for one. Kovrr's AI Security and Governance Platform records ownership and reach per agent rather than per application, which is the unit the risk sits in.

‍

To see which automations exist inside your approved AI platforms and what each one can reach, book a demo mapped to your own estate.