You are going to evaluate an AI governance product soon, if you have not already. The vendor will send a feature matrix with forty rows. Most of those rows are noise.
Only two things matter: expressiveness and usability. Expressiveness is the ceiling of what the product can enforce. Usability is what your team can actually get it to do. Every capability worth caring about is one of those two in disguise, and the best way to run an evaluation is to sort each feature into one of these two buckets and ignore anything that doesn’t fit in either.
Expressiveness: the ceiling of what the product can enforce
Expressiveness measures how sophisticated a control the system can state and enforce.
It does not take much to say agents may not delete records in Salesforce. That is a tool name and a verb, and a checkbox can handle it. It takes a great deal more to say after an agent reads one customer’s data in Salesforce, it may not email that data to a different customer. That control spans two actions, two systems, and a relationship between them. A product that evaluates one call at a time cannot express it, no matter how many checkboxes it has.
Expressiveness has always mattered in security. Agents have made it critical because they are a new type of actor that relentlessly pursue a goal. A well-meaning agent does not understand why a path is closed. It reads each closed door as a problem to solve on the way to the user’s stated goal, and it gets better at solving them with every model generation. The incidents that follow are not single bad actions. They are combinations of individually permitted actions, composed across systems, that add up to something nobody intended. Each step passes every check. The sequence is the incident. Governance that cannot see the sequence is governance that cannot see the problem.
So when you evaluate expressiveness, do not evaluate against what you need today. Evaluate against what you will need once agents are doing real work across your systems. Ask whether the product can express a control that depends on what happened earlier in the session. Ask whether it can express an outcome rather than a mechanism, so the control survives when a tool is renamed or a vendor is swapped. Ask whether it can inspect and modify what goes into and comes out of a tool call, not just allow or deny the call. Those are the questions that separate a control plane from a switchboard.
Usability: what your team can actually get it to do
Usability measures how effectively you can use something. That is different from what the product can do. If the product can do something impressive and you cannot get it set up to do it, the feature does not exist for you.
Start by being honest about time. We give our attention to what drives the business forward, and we give leftovers to what feels like overhead. Governance is overhead until the day it is the incident. You are busy. Your team is busy. Your colleagues in IT, security and compliance are busier than you are. So before you evaluate any product, write down the time budget: how many hours a week your organization will realistically spend on agent governance, this quarter and next year. Every usability judgment that follows is measured against that number.
Then break usability into three stages, because products that pass one often fail another.
Onboarding. This has two halves, and vendors love to quote the easier one. The first is how long an administrator needs to stand the system up. The second is how long each user needs to get connected and productive. A system that takes an admin an afternoon and each user a support ticket has a usability problem that scales with headcount. Patience is short. If the path from sign-up to a working policy is not measured in minutes, most of your users will find another path, and it will not be the sanctioned one.
Tuning. This is separate from onboarding and usually costs more. Nobody knows what they need until they have used the thing. The first policy is a guess. The second is informed by the first week’s usage. The tenth is informed by a near miss. There is always a loop, so the question is how much each turn of the loop costs. Can a non-specialist adjust a control, or does every change go through the one person who understands the rule syntax? Can you see what a policy would have done before you turn it on? A product that requires a specialist for every adjustment has quietly moved its cost from setup to forever.
Scale. This is the stage that gets skipped in evaluations and paid for later, and it is not about requests per second. It is about whether your organization can still manage the environment after one year, three years, five years. Governing ten agents is a hobby. Governing a hundred is a job. What happens at ten thousand, or a million? Remember the time budget. If you could not give governance more than a few hours a week when you had ten agents, you will not be able to give it more when you have ten thousand, and the mental load of understanding what a fleet that size is doing is significant. So ask the scale questions on day one. How do I know what a thousand agents are doing right now? How do I find the one that is off-task? How does the product tell me a policy has gone stale? If the answers are “a dashboard with a thousand rows,” you have found the ceiling.
The tradeoff, and why it no longer holds
For most of the history of security products, expressiveness and usability pulled against each other, and a buyer had to pick.
A checkbox is maximally usable. It is also a dead end. If the control behind the checkbox is almost what you need, your ability to adjust it is zero. At the other extreme, writing code is maximally expressive: you can get exactly the behavior you want. But writing, reading and maintaining that code is the least usable thing in the building, and it stays that way after the person who wrote it leaves. Products picked a point on the line based on who they were selling to. Skilled teams could push a product toward both ends at once, but it was always a compromise, and the compromise was structural. The US National Institute of Standards and Technology states it as a rule: there is “a trade-off between the expressive power of an access control model and the ease of safety enforcement.” This post argues this is no longer the case.
AI changed the shape of this. It is now possible to build a highly expressive policy engine and have people interact with it through AI. The engine keeps the depth. The AI supplies the usability. A non-technical person describes the control in plain language, the system writes the policy, and the same system explains what the policy did and why. That was not a realistic product two years ago. It is now, and it changes the right answer to the question this post started with. You do not have to choose. You should expect both, and a product that asks you to settle for one is a product designed before the tradeoff dissolved.
Running the evaluation
Put it together and the evaluation is short.
- Write down the time budget. Hours per week, this quarter and in a year. Everything below is measured against it.
- Test expressiveness against the future, not the present. Bring one control that relates two actions across two systems. If the product cannot express it, stop.
- Time the onboarding, both halves. Admin setup and per-user connection. Minutes is the bar.
- Run the tuning loop. Change a policy. Change it again. Note who had to be in the room.
- Ask the scale questions. A thousand agents, one dashboard, one person on a Friday afternoon. Can they tell what is going on?
A product that passes all five is rare. Two years ago it did not exist. Today it does, and it is what you should hold out for. Good policy unlocks AI adoption. Choosing it well is most of the work.
Run this evaluation on Dtwo. Start a free trial.
FAQ
What is the difference between expressiveness and usability in an AI governance product? Expressiveness is the range and sophistication of controls the product can enforce. Usability is what your team can actually get it to do with the time you have, from first setup through tuning to managing it at scale years later. A capability you cannot operate might as well not exist.
Why does expressiveness matter more for AI agents than it did for human users? Agents pursue goals and route around obstacles. The incidents they cause are combinations of individually permitted actions across systems, and a control that cannot see the combination cannot stop it. Per-action allow and deny rules are enough for humans and not enough for agents.
How should I evaluate usability before buying? Decide your time budget first. Then test three stages separately: initial onboarding for the admin and for each end user, the tuning loop as your requirements change, and management at scale, meaning what it takes to understand and run the environment when you have a hundred times more agents than you do today.
Do I still have to choose between an expressive product and a usable one? Not anymore. The tradeoff was real for decades, but an expressive policy engine can now be operated through AI, which supplies the usability. You should expect both and not settle for either alone.
References
- Hu, V. C., Ferraiolo, D. F., and Kuhn, D. R. Assessment of Access Control Systems. NISTIR 7316, 2006. Source of “a trade-off between the expressive power of an access control model and the ease of safety enforcement.”
- Cutler, J. W., et al. “Cedar: A New Language for Expressive, Fast, Safe, and Analyzable Authorization.” OOPSLA 2024.