Roles as templates
Controller, AP clerk, department head, auditor, portal user — as starting templates you adjust rather than build from nothing, with the differences from the template visible.
Platform · trust
A permission model is easy to demonstrate and hard to get right, and the difference shows up in two places: whether it is enforced below the application, and whether it applies to software as well as to people. Most systems fail one of those and nobody notices until a review.
What it does
Controller, AP clerk, department head, auditor, portal user — as starting templates you adjust rather than build from nothing, with the differences from the template visible.
Tenant, entity, department, location, and project. A controller of two subsidiaries in a group of nine sees exactly two, enforced rather than filtered.
Read, draft, post, approve, release, administer — not create-read-update-delete, because the difference between drafting a bill and releasing payment against it is four authorities rather than two verbs.
Approve to $10,000 in one entity and $50,000 in another is a normal grant rather than a workaround, and it is what real approval matrices look like.
An invoice has a total, a cost, and a margin. A portal user sees the first and cannot request the others at any layer including exports.
Access with an end date for auditors, contractors, and cover during leave. Permanent access granted for a temporary reason is how sprawl begins.
The common architecture checks permissions in the application layer: an endpoint asks whether this user may do this, and proceeds if so. It works until somebody writes an endpoint that forgets to ask, which is the single most common cause of data exposure in multi-tenant systems and a class of bug code review catches inconsistently.
Ours is enforced in the data access layer. Every query carries an actor and a scope, and a query without them is rejected rather than executed. A developer cannot write an unscoped read and have it succeed, because it fails below the code they are writing. Row-level security in Postgres sits underneath as defence in depth.
Most systems have a role model for users and something vaguer for automation and API access. That split is precisely how automated activity ends up outside the control framework — and with agents in the picture it becomes the difference between a defensible audit trail and one that describes something that did not happen.
An agent is an actor with its own identity and permission set. An API key is an actor. A portal user is an actor. All four are subject to the same conflict matrix, so a grant that would let one entity create vendors and release payments is rejected at creation regardless of whether it is a person or a key.
Object-level permissions answer whether you can see an invoice. They do not answer whether you can see its cost and margin, which sit on the same record. For customer portals, external auditors, and junior staff that distinction is the entire requirement.
A system that can only grant or deny whole objects forces a choice between over-exposure and maintaining a separate reporting copy — and the second is how most companies end up with a second uncontrolled database.
Limits
SSO via SAML or OIDC and SCIM provisioning on Enterprise. Your identity provider remains authoritative for who exists; we govern what they may do.
If nobody can say who approves what above $25,000, no permission model supplies the answer. That decision comes before configuration and is usually the slow part.
A small number of our engineers can reach production under time-bound, dual-approved, logged access reported to you. Pretending otherwise would be dishonest.
Questions
We will map it into the model and flag the conflicts before anything is implemented.