Finance is owner-only, by design.

Most software uses roles. Viewer, editor, admin. The higher the role, the more you see. It is simple and it is usually fine.

It is the wrong model for accounting. The person who runs your servers does not need your bank feed. The person who manages the team does not need payroll. And a company that is honest about this will find that the people with the broadest roles are exactly the people who should not automatically see the books.

So Brigham.ai treats finance as a protected domain, and a protected domain follows different rules.

Grant by person, never by role

Access to a protected domain comes from one place: an explicit grant to a named person. It is never derived from a role. A workspace admin gets nothing. A super admin gets nothing.

The grant starts with the owner alone. Only the owner can give it to someone else, and every change to a grant is audited and notified to the owner. There is no quiet way to add yourself.

The grant is also intersected with the module access already set in erp.io. If the suite has already denied someone a finance module, Brigham.ai does not widen that.

The label travels

The easy mistake is to protect the source and forget the copies. A summary of a bank statement is still a bank statement.

So when a conversation or run touches finance data, it becomes finance-labelled, along with its messages, run events, tool executions and audit rows. Anything derived from it inherits the label: summaries, memory candidates, briefings and delegated subtasks.

Retrieval filters on the label in the database query before ranking, so finance content never reaches the context of someone who has no grant. It is not filtered after the fact. It is never fetched.

Labels are added automatically and removed by the owner

Labels only ever go one way on their own. Code adds them. Code never removes them. If a label should come off, because a document was marked finance by mistake, it takes the owner to remove it.

This is deliberately lopsided. A false positive costs a little convenience. A false negative leaks the books.

Automations run as their owner

A morning briefing is built as the person who owns it. A briefing owned by a teammate cannot contain finance data, because that teammate cannot see it. The owner’s briefing can.

The same logic applies to delegation. When Brigham.ai hands a subtask to a specialist agent, the grant does not travel with it to an agent acting for someone else. Delegation never widens permission.

Admins see counts, not rows

Administrators need to run the system. They look at run lists, usage and audit search. Those views hide finance-labelled rows from anyone without the grant and show only a count.

An admin can know that finance activity happened. They cannot read what it was.

Tests that prove it

A boundary you have not tested is a hope. The test suite checks that a super admin without the grant is denied and audited when they call a finance tool. It checks that finance-labelled memory never appears in that person’s retrieval. It checks that the owner’s finance conversation is invisible to a workspace admin by every route. And it checks that a summary derived from a finance run inherits the label.

The mechanism is proven with a test-only fixture, so it is solid before anything sensitive is connected.

Beyond finance

Finance is the first protected domain, not the only possible one. The same mechanism protects any domain a business decides should stay with named people. For a larger company, that might be legal, HR or board material.