Governance
How a governed request works
The canonical path for work under Brightwire Agent Governance — authenticate, meter, check budget and policy, route the model, allow tools, then audit.
Every capability page in Governance assumes the same idea: policy and cost checks sit in the path, not only in a slide deck.
User / agent→Authenticate→Meter→Budget OK?→Policy OK?→Route model→Tools if allowed→Audit + cost→Result or human gate
| Step | Purpose |
|---|---|
| Authenticate | Enterprise identity and environment membership |
| Meter | Count tokens and requests on the governed path |
| Budget | Soft or hard stop — or require elevation — before spend runs away |
| Policy / allowlist | Model, tool, data, and export rules for this environment |
| Route model | Simple work to smaller/faster models; high-stakes work to frontier — under policy |
| Tools | Only approved skills and tools for that caller |
| Audit + cost | Reconstructable trail: actor, path, decision, spend attributes |
| Outcome or human gate | Return a result, or require accept / reject / escalate on Advise- and Act-class work |
The same path can apply to a cloud seat, a coding agent, a department Runtime, or another managed path — when that path is in scope. We do not claim this path runs inside every closed vendor UI on day one.
Related: Why Governance · Cost · Policy & human gates · Audit