The company brain
How access rights work on a system everyone shares
Last updated
Short answer
Every person is mapped to a role, and every role has explicit access per connected tool, split between reading and writing. The system checks that mapping on every request, so two people can ask the same question and correctly receive different answers. Anything touching money, staff data or an external system passes a person before it takes effect. This is the condition on which a shared system is approvable at all, not a feature.
The mechanism
What the mapping actually contains
A table, checked on every request, with four columns that matter.
Person to role
Each individual identity in the chat tool your team already uses maps to a role. Not to a permission list of their own, which nobody maintains, but to a role that can be reasoned about and reviewed.
Role to tool
Each role has explicit access to each connected system. A role that has no business reaching your finance records simply is not connected to them, rather than being trusted not to ask.
Read against write
Split, always. Being allowed to see the state of an order is a different decision from being allowed to change it, and collapsing the two is how a well-meaning request becomes an incident.
What happens on refusal
A refused request is passed to whoever can approve it rather than silently dropped. The person gets an answer, which is what stops them from routing around the system entirely.
In practice
The same question, two different people
The clearest way to show what the layer does is one question asked twice.
Asked by someone in sales
What is our approved price for 500 units, and what discount can I offer?
Answered from the current price list and the discount policy, with both sources cited so the answer can be checked against the documents rather than believed.
Asked by someone in the warehouse
What is our approved price for 500 units, and what discount can I offer?
Refused, and routed to whoever can approve it. Commercial terms sit outside that role, and the request is escalated rather than quietly answered or quietly ignored.
Note what the second case is not. It is not a generic apology, and it is not silence. Both of those teach people that the system is unreliable, and a system people have learned to work around has negative value, because the material inside it is now stale as well as unused.
Human oversight
The review gate, and what sits behind it
Reading is one decision. Acting is another, and it is gated separately.
- Anything that moves moneyIssuing a credit, approving an invoice, committing to a discount. A person approves the output before it takes effect.
- Anything containing personal data about staffReviewed before it leaves, regardless of who asked and how routine the request looks.
- Anything that writes to an external systemCreating the record, sending the message, updating the customer file. Reading from those systems is unrestricted within the role; writing to them is not.
- Anything a customer will read verbatimDrafting is the useful part. Sending is a decision, and it stays one.
The honest limit
What this approach cannot promise
It matters to state this plainly, because the alternative is discovering it during an audit.
The enforcement is a check performed on every request against an explicit table. That is a real control and it is auditable: you can read the table, review who holds which role, and see what was refused. What it is not is a formal guarantee of the kind a certified access-control system in a bank carries. The underlying behaviour is probabilistic, and anybody telling you otherwise about any system of this shape is selling.
The practical consequence is a design rule rather than a caveat: material whose exposure would be unrecoverable does not get connected in the first place. The strongest access control available is that the system genuinely cannot reach the thing.
That is also the question worth putting to anyone else proposing to build this inside your company.
Ask what their system is not connected to, and why. An answer of "everything, it is all secure" is the wrong answer.
Frequently asked questions
Who decides which role a person has?
You do, and it should mirror the access decisions you have already made elsewhere rather than inventing a parallel scheme. Where the mapping disagrees with the access someone already has in your existing systems, that disagreement is usually worth investigating on its own merits.
Can we see what people asked and what was refused?
Yes, and reviewing it is part of running the system rather than an add-on. What people ask reveals which jobs are worth teaching next, and a pattern of refusals usually means a role is drawn in the wrong place rather than that somebody is misbehaving.
Does this satisfy our data protection obligations?
Per-person access rights, a review gate on consequential output and a record of what was asked are the operational parts of an answer, alongside hosting and a processing agreement. They are necessary rather than sufficient: the assessment is specific to what you connect and what you do with it, and anyone declaring you compliant before seeing that is guessing.
What stops someone asking a colleague with more access to ask on their behalf?
Nothing technical, and nothing ever has. That is the same exposure you carry today with shared documents and forwarded email, and it is a management question rather than a software one. What changes is that the routine version of that request now has a legitimate path: escalation to whoever can approve it.
Can a person see which sources an answer used?
Yes. Every answer cites the material it came from, and only material that person is entitled to see is used to produce it. An answer that cannot be traced back to a document cannot be checked, which means it cannot be trusted with anything consequential.
AINORA, MB builds and operates AI systems for companies from Vilnius, Lithuania. It designs company brains: shared internal systems that hold an organisation's own knowledge, connect to the tools it already runs, and carry out the jobs its people repeat, with access rights enforced per person and hosting in the EU.
The approval question comes first, not last
If a shared internal system has stalled in your company, it has usually stalled here rather than on capability. The useful first conversation is about what would have to be true for your security function to say yes.