Govern

What you haven't allowed simply doesn't run.

Verillian checks every AI action on the device against the rules you wrote, agents included, and anything you haven't said yes to is refused before it runs.

app.verillian.local
Verillian console, add a control: the exact transfer commands the rule refuses, reviewed line by line
01
Deny by default

One rule sits above all the others.

An AI policy in a document has no way to reach the tools your people open. Verillian turns that policy into a decision made at the moment an AI tool or agent acts. Whatever you've said no to stays refused, even when another rule would allow it. Whatever you haven't said yes to gets the same answer. The industry calls that deny by default. What it means in practice is that the work you allowed goes through, and nothing else does.

02
The rules hold

Renamed, buried, or chained: still refused.

Picture the command that wipes a drive, banned in your policy. Now someone buries it in the middle of a fifty-line script, renames it to something forgettable, gives it administrator rights, and chains it behind three harmless steps. Verillian reads what the command actually does, arguments and all. Wrappers are peeled off, each link of a chain is judged on its own, and anything that can't be parsed is refused rather than guessed at. It's still the same action underneath, so it still doesn't run.

01

Seen for what it is

Disguises don't change the verdict. A rule binds the action itself, not its spelling, so renaming a tool or wrapping it in something innocent leaves exactly one outcome: refused.

02

No privilege escape

Admin rights don't outrank your policy. A denied action stays denied for the administrator who runs it, and stays denied at every harmless-looking step it hides behind.

03

Refused, not guessed

When a request is so mangled the system can't tell what's being asked, it doesn't take its best guess and hope. It says no, and the refusal lands in the record like any other verdict.

03
In the console

Per tool, per group, per action.

You write what each AI tool may do for each team, down to one action opened or closed by exception, from a console on infrastructure you own. An exception can carry its own expiry, so it closes itself. Every change carries a justification and lands in the same tamper-evident history as the traffic it governs, which is how you can show which version of policy decided any given action.

app.verillian.local
Verillian console, policy authoring: per-tool permissions across the fleet
04
Agents and MCP

An agent gets less than the person driving it.

Agents reach your business systems through tool calls, over a connector standard called MCP, and each call gets its own verdict. A coding agent working under a Salesforce administrator holds none of that administrator's power. If your policy bans a write, that call is refused on the device and Salesforce never receives it, on that action alone. The reads you allowed keep flowing. Narrower than the human, per integration, per action.

What leaves the device

Before any prompt goes to a provider, the values you flagged are already gone. The record keeps both versions: what the person typed and what actually left.

VERILLIAN/ redaction preview
demo data
1 / PICK A SAMPLE PROMPT
2 / WHAT LEAVES THE DEVICE
OUTBOUND PROMPT / ON THE DEVICE

Summarize this patient's history. SSN 123-45-6789, record MRN-4471902, seen for follow-up Tuesday.

2 sensitive spans detected on device
Detection is configured per institution and is best-effort, not a guarantee that every value is caught.