Use case

Risk Review

Before a workflow change goes live, someone checks not just whether it works, but what new things it could touch — and the changes that could do real damage get an extra set of eyes.

The short version

Think of home renovations. Repainting a bedroom is your call; taking down a wall needs a permit and an inspector, because the worst case is very different. Risk review works the same way for AI workflows: small changes ship fast, but a change that gives the agent new powers gets a second look before it goes anywhere.

How it flows
A change is proposedIts risk level is checkedLow risk? Ships normallyHigher risk? Extra signoffEvery decision logged

The problem, in plain words

A teammate proposes a change to a workflow. It's a few lines, it passes the tests, the review takes two minutes. What nobody notices is that this small change quietly gives the agent something it never had before — access to a new database, or the ability to send messages outside the company. The diff looked harmless. The deployed behavior is a different animal. And because every change gets the same quick once-over, the scary ones get too little attention and the boring ones get too much. You find out which was which when something goes wrong at scale.

What we set up

Every workflow carries a risk classification — a written label saying what data it touches, what tools it can call, and what effects it can have outside your systems. When someone proposes a change, the change declares how it moves that label. A change that stays at the same level ships through normal review. A change that raises the level — new tool access, a new class of data, a new external destination — requires an extra, named reviewer to explicitly sign off. The label itself is versioned (every edit to it is recorded, with who and when), so nobody can quietly lower a workflow's risk level: a downgrade triggers a review of its own. Every elevation and every signoff lands in an audit log.

How it works, step by step

  1. A change is proposed

    Someone updates a workflow — a new prompt, a new tool, a new data source. Business as usual.

  2. The change declares its risk

    What data does it touch? Which tools can it call? What could it affect outside the company? The answers are compared against the workflow's current risk label.

  3. Same level? It ships the normal way

    Regular review, no extra ceremony. Low-risk work stays fast.

  4. Higher level? An extra reviewer signs off

    New tool access, new data class, new external destination — a designated person has to explicitly say yes, on the record.

  5. The label itself is protected

    The risk classification is versioned. Raising it is visible; quietly lowering it is impossible, because a downgrade triggers its own review.

  6. Everything is on the record

    Every elevation, every signoff, every label change goes into an audit log. When someone asks who approved this, the answer exists.

What changes for you

Before, every change got the same level of scrutiny, which in practice meant the dangerous ones were under-checked and the routine ones over-checked. After, your team ships fast on the low-risk changes and slows down only for the handful that expand what the agent can touch — and those get the attention of someone whose job it is to give it. Functional review keeps answering 'does this work'; risk review answers 'what is the worst thing this could do at scale, and is that acceptable'. What it won't do: it won't judge whether a change is a good idea. It only guarantees the right people look before something with a bigger blast radius goes out the door.