To choose AI agent governance tooling, ask eight questions: how it finds agents, how it scopes their access, how it handles approvals, what it logs, how it fails, where it runs, how it fits your pipeline, and how you leave. Test each one on your own systems during a trial, not on a slide.
The eight questions
| # | Question | What a good answer looks like |
|---|---|---|
| 1 | How does it discover agents and tool servers? | Finds ones you did not tell it about |
| 2 | Can access be scoped per agent? | Tool, data and credential scope per identity |
| 3 | How do approvals work? | Rules by action type, with the approver shown the real input |
| 4 | What is logged? | Tool name, arguments, identity, outcome, time |
| 5 | What happens when the control itself fails? | A documented fail-open or fail-closed choice you can set |
| 6 | Where does data go? | Clear statement of what leaves your environment |
| 7 | Where does it plug in? | Developer machine, CI, pull requests, runtime |
| 8 | Can you export your rules and logs? | Standard formats, no rewrite on exit |
Why these eight
Most disappointments come from the same few gaps. A tool that only covers agents you registered will not help with the ones teams adopted on their own. A tool that logs "agent ran a task" but not the tool arguments will not help in an incident. OWASP's guidance on excessive agency points the other way: limit extensions, limit permissions, run actions as the individual user, and require approval for high-impact actions. Each of those needs a matching feature to enforce it.
How to test each question in a week
Give the trial a short script instead of a free-form demo.
- Plant a known agent and a known tool server the tool was not told about. Does it appear?
- Give two agents different scopes. Try an action outside each scope.
- Trigger a high-impact action. Read the approval prompt as an approver would.
- Pull the log for that action and check it names the identity and the arguments.
- Block the control's network access. Observe whether agents stop or carry on.
- Ask for the list of data fields sent to the vendor, in writing.
- Wire it to one repository and one developer machine.
- Export the rules. Open the file.
Keep the results in a table with a pass, partial or fail for each. A partial is useful information, so write down what was missing.
Weighing the answers
Do not add up scores blindly. Decide before the trial which two or three questions are deal breakers for you. For a regulated team, questions 4 and 6 are often those. For a small fast team, 7 and 8 matter most. The weighted scorecard method shows how to set that up without bias.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow the setup and note how long it takes to get a first useful result, which is a fair thing to time in any trial.
Safeguard covers asset discovery, agent identity, policies and gates, and an MCP Guardrail, and you can try the scanning side first with the free scan.
Quick check
Should we run a trial with real production data?
Use real systems but the least sensitive ones that still behave realistically, such as a staging project. Agree in writing what data the tool may see.
How many tools should we trial at once?
Two or three is manageable. More than that and the team stops testing carefully.
Sources
Last reviewed: 19 October 2026.
