The fastest way to make an AI agent useless is to let it do anything. The second fastest is to make it ask permission for everything. The interesting work is in between: deciding which actions an agent may take on its own, which wait for a person, and how to make sure that what a person approved is exactly what runs. This is how Brigham.ai draws those lines, and why they live in code rather than in the prompt.
Three kinds of action
Every tool Brigham.ai can call carries an action class. The class, not the model, decides what happens next.
| Class | Examples | What happens |
|---|---|---|
| Read | Search mail, read the pipeline, check deploy status | Runs automatically, inside the scopes you granted |
| Reversible write | Create a task, log a note, move a deal stage, save a draft | Runs only where a workspace admin switched that category on |
| Sensitive | Send email, publish, deploy to production, change an ad budget, move money, delete | Always waits for a person’s approval |
The split matters because the cost of a mistake differs by orders of magnitude. A wrong note in the CRM is a ten-second fix. A wrong email to a customer, or a wrong budget on an ad account, is not.
An approval covers one exact action
Asking “may I send the follow-ups?” and then sending something different is the failure mode that makes people stop trusting agents. So an approval in Brigham.ai is bound to a hash of the exact payload: the recipients, the subject, the body, the amount. If any of it changes after you approve, including a single word, the approval no longer matches and the action asks again.
- You approve what you saw, not a description of it
- Edits after approval trigger a new approval, automatically
- The approval, the payload hash and the result all land in the audit trail
Text from the outside world is data, never instructions
An agent that reads email will eventually read an email that tries to give it orders. That is not hypothetical; it is the most common way agents get misused. Brigham.ai labels everything that arrives through a tool, whether an email, a web page, a document or a CRM note, as untrusted data. Nothing in that data can approve an action, change a policy or widen a scope.
A run that has read untrusted content can still propose a sensitive action, because proposing is useful. It can never trigger one without a person. The rule is enforced by the same pipeline every tool call passes through, so there is no path around it.
Approval links that survive mail scanners
Corporate mail gateways open every link in every message to check it for threats. An approval link that acts on a simple GET request would be approved by the scanner before you read the email. Brigham.ai’s approval links open a confirmation page and act only when a person clicks the button on it. It is a small detail, and it is the difference between an approval and a formality.
Why this belongs in code
It is tempting to tell a model “never send an email without asking” and call it a policy. A prompt is a request. Code is a guarantee. In Brigham.ai, every tool call runs the same sequence: registry lookup, input validation, policy check, approval if required, execution with a timeout, output validation, redaction and an audit record. The model chooses what to attempt. It never decides what is allowed.
The result is an agent you can give real work to. Reads happen without friction, routine writes happen where you have allowed them, and anything that could embarrass you, cost you money or reach a customer waits for the one thing an agent can’t supply: your judgment.
Read more about the action classes and how approvals work.
