How to bring unsanctioned AI agents under governance

Find them through access, not through a survey. Unsanctioned agents show up as tokens, app grants and service accounts that reach your systems. Contain anything that can write, offer a short amnesty, then decide for each agent whether to register, rebuild or retire it. A named owner makes each decision, and the register records it.

What is the process, and who owns it?

An unsanctioned agent is any AI system acting on company data or systems that was never approved. Typical examples are a sales team's email assistant with access to every mailbox, an analyst's script that calls a model provider with customer records, or a no-code workflow that updates the CRM. Most were built in good faith to save time.

The process has two owners. The chief information security officer owns discovery and containment, because the risk is access. The chief operating officer, or whoever owns agent governance, owns the decision on each agent's future, because the question is whether the work should be done this way. The difference between broad AI governance and AI agent governance matters here: a chatbot policy does not cover software that acts.

What are the steps?

1. Person, CISO, with the COO: sets the amnesty terms. A fixed window in which staff can declare agents without penalty, and what happens to undeclared agents after it.
2. Agent, depth 1: scans for access. It reads third-party app grants, API tokens, service accounts and traffic to model providers, and lists each one with its owner, scopes and last use.
3. Agent, depth 1: matches spend. It reads expense claims and card statements for subscriptions to AI tools, and links them to the access found.
4. Agent, depth 2: drafts a note to each apparent owner asking what the agent does, what data it uses and what it changes. A person sends the notes.
5. Person, security lead: contains write access. Any unsanctioned agent that can change a system of record, send external messages or move money has those permissions removed now. Read access can wait for triage.
6. Person, process owner: triages each agent into one of three outcomes: register as is with limits, rebuild on the approved platform, or retire.
7. Agent, depth 3: enters each agent on the inventory with its owner and status.
8. Person, process owner: approves re-scoping and certification for agents being kept or rebuilt.
9. Person, security lead: revokes and confirms deletion for retired agents, including data held by the tool's vendor.

Which decisions does a named person keep?

Containment. Removing write access can stop a team's work. The security lead decides, and tells the team's manager why.

Triage. Only the owner of the business process can say whether the work should continue. Security can say whether it is safe; the owner says whether it is wanted.

Accepting residual risk. Some agents will be kept on a third-party tool for a time. Someone with authority signs that they accept the risk until the rebuild.

Consequences after the amnesty. Undeclared agents found later are a conduct matter, and HR and the manager decide what follows.

What record does the method produce?

• Discovery list: each grant, token or account found, its scopes and last use.
• Owner responses: what each agent does, in the owner's words.
• Containment log: what was removed, when and by whom.
• Triage decisions: the outcome per agent and the reason, signed.
• Inventory entries: each kept agent with owner, role scope and depth.
• Retirement records: revocation confirmations and the vendor's deletion confirmation.

Which controls stop it happening again?

Grants need approval. Users cannot connect new third-party apps to company data without an approval step. This is the control that matters most.

Approved routes are quicker than workarounds. If getting an agent approved takes six months, people will build their own. A fast path for low-depth, read-only agents removes most of the motive.

Spend is checked. Expense rules route AI subscriptions to review.

Vendor terms are read. A tool's terms or assurance report do not make it governed; vendor assurances are not your governance. Nor do its built-in content filters, because guardrails are not governance.

What should you measure?

• Unsanctioned agents found per scan, which should fall over time.
• Days from discovery to containment for agents with write access.
• Agents declared in the amnesty compared with those found by scanning. A low declaration count points to fear or poor communication.
• Time to approve a new low-risk agent through the proper route.

For a wider view, see how do you measure AI agent governance?

Where does it usually go wrong?

It starts as a crackdown. Staff hide their agents, and discovery finds only the careless ones. Lead with the amnesty.

Everything is switched off at once. Work stops, managers object and the programme loses support. Contain write access first, then triage.

Retired tools keep the data. Revoking the token does not delete what the vendor already holds. Ask for deletion and keep the confirmation.

Kept agents are never re-scoped. An agent registered "as is" keeps the broad access it had. Registration should come with limits and a date for certification.

Where Pryme fits

Agents rebuilt in Pryme get their own identity, a role scope and a depth earned on your cases, and every action is filed. That gives the triage team a destination for the work worth keeping. How the limits combine is set out in agent governance is a bound, not a model.