Before letting an AI act,
decide what it may do.

What I was trying to solve

When a team gives an AI access to its systems, someone has to decide whether it can be trusted with real work. I built PRIVI to compare what a team says its agent may do with what its code and operating evidence can establish. The work produced a published draft rubric with 41 checks, covering questions such as whose account the agent uses, what it can change, and who approves the change.

Why the missing descriptions mattered

Imagine a customer service tool called “handle refund.” Can it look up a purchase, prepare a recommendation, or actually return money? That difference determines which credentials it needs and where a person should approve an action. This is an illustrative example, not an incident found by the study.

In an August 2026 sample, only 103 of 4,445 observed tools stated whether they changed anything. The useful question was what a team should do with that gap: make the allowed actions explicit before trying to check them. Adding a description helps a reviewer understand the tool. It does not enforce a permission.

The study read code from 199 public repositories; it did not run their tools. Missing descriptions did not establish that the tools were unsafe or that anyone had acted without permission.

Three things I would apply to a real system

1. Define the action before granting access.

   For the refund example, specify whether the agent may only draft a refund, which account it acts through, and which amounts require approval. Make those limits part of the system's access controls, so they do not depend on the model remembering an instruction.

2. Test the boundary in a controlled environment.

   Try an allowed refund, one above the limit, and one with approval missing. Inspect whether money could actually move. Reading source code can suggest what should happen; checking the running system answers a different question.

3. Leave a record someone else can check.

   Keep the request, approval, attempted action and result together. If a check cannot be completed, say what is unknown and what evidence is needed. An unanswered question should not quietly become a passing score.

Why I retired the product

I originally wanted to use past failures to predict future ones. The research did not demonstrate that ability: no prediction was scored against an outcome, and no comparison established that failure history improved the review. I stopped treating that idea as a product claim.

I also built ahead of buyer conversations. Publishing a thorough rubric did not establish who would adopt it, who would pay, or which decision it would change. The next time, those conversations come before more engineering.

What survives PRIVI

I am keeping the distinction between what code can show and what needs a live check, along with the designs for checking permissions and approvals. I am also keeping the habit of publishing what the evidence could not establish.

For my next work on customer-facing AI, this becomes two separate questions: was the agent allowed to act, and was its answer correct against the organization's approved facts? PRIVI informs how I would test the first. It does not prove the second. That accuracy work is still in development.