Brigham.ai

Trust · Policy is code

The model never decides what it may do

Every action Brigham.ai takes passes through one pipeline. Authorization is checked by code that the model can’t rewrite, persuade or bypass.

A prompt can be argued with. A function can’t.

Instructions in a system prompt are only as strong as the model’s resistance to a clever message. Brigham.ai doesn’t depend on that resistance.

The one pipeline

1

Look up

The tool must exist in the registry and be enabled for this workspace and this agent. Unknown or disabled tools fail here.

2

Validate input

Arguments are checked against a strict schema. Extra fields are rejected. Malformed input never reaches the tool.

3

Check policy

Code checks the actor, their role, the action class and the scope. The model’s opinion plays no part.

4

Approve if needed

Sensitive actions stop and wait for a person. The approval is bound to the exact payload.

5

Execute

The tool runs with a timeout.

6

Validate output

The result is checked against its schema before anything uses it.

7

Redact

Secrets and sensitive fields are removed before anything is written down.

8

Audit

The call, who made it, the decision and the outcome are recorded.

Policy in the prompt versus policy in code

Prompt-based rulesBrigham.ai
Where the rule livesIn text the model readsIn code the model can’t modify
If the model is fooledThe rule is goneThe pipeline still refuses
Who decidesThe model, case by caseThe policy check, every time
EvidenceHope and spot checksAn audit row for every call

Roles and tool definitions

Role ladder
Viewer, Operator, Workspace admin, Super admin. The same ladder as the rest of erp.io, read from your sign-in and capped by the access you were given.
Tool schemas
Strict. Every object rejects unknown fields. Schemas are generated from the validation types, not written by hand.
Refusals
A refused call is audited like any other.
Model ids
Kept in one file and checked, so a stray model can’t be quietly swapped in.

Questions, answered.

Can the model skip a step?

No. The model emits a request to call a tool. The pipeline is the only code path that runs one.

What if a tool returns something unexpected?

Output is validated against its schema. Output that doesn’t match is rejected before anything else sees it.

Can I see the record?

Yes. Each call writes an audit event. See the audit trail page.

See the pipeline run

Request access and watch a tool call move through each step in the audit trail.