The easiest way to build an agent guardrail is to match strings.
Block `rm -rf`. Hold `git push`. Flag `curl`. Maybe add a few allowlists. This is not useless. It can catch obvious mistakes. But it is not enough for enterprise governance because raw strings do not describe consequence.
Two actions can look similar and mean very different things. Two actions can look different and produce the same effect.
What CAVA adds
CAVA analyzes the action as a structured object. It asks what the action intends to do, what target it touches, what privilege it needs, whether it crosses a boundary, whether it moves data, whether it can be reversed, and whether the evidence is good enough to trust later.
That is why `git push origin main` should not always be the same score. The score depends on repository sensitivity, branch role, CI behavior, actor identity, change context, policy profile, and closure evidence.
Why buyers can understand it
The product version should not read like a compiler trace. It should explain the decision in language a buyer can use:
- —This action touches a release boundary.
- —It requires write authority.
- —The change is only partially reversible.
- —The repository is production-adjacent.
- —Human approval is required before execution.
That explanation is the bridge between runtime engineering and security leadership.
The line OSuite draws
String matching can be a signal. It should not be the governance substrate.
CAVA gives OSuite a richer object to judge. PCAA then binds approval to that object. Decision Score v2.1 explains why the route was chosen. Together, the product moves from "we saw a command" to "we governed an action."
