Trust · Customer-controlled access
Who can see what, and who decides?
Access is decided on the server, by organisation, role and location, and an AI assistant inherits the permissions of the person asking: it never has more.
No certification, audit or independent assessment is held. Each statement below shows how sure the project is of it.
What exists, and how sure we are
- Tested locallyEvery request is checked against the organisation, role and location the server resolved, never against what the request says.Recorded in the security assurance record.
- Tested locallyOne organisation cannot read another's records, and the refusal is the same as for a record that does not exist.Recorded in the security assurance record.
- Tested locallyPermission checks deny by default; hiding a button is not what keeps something safe.Recorded in the security assurance record.
- Tested locallyAn AI assistant is authorised from the signed-in person and their organisation, never from what a prompt says.Recorded in the security assurance record.
- Reviewed in codeA revoked, expired or deleted person's sessions stop working, and a password reset ends every session.Recorded in the security assurance record.
- Not in placeAn organisation cannot switch one AI feature off for itself today: the operator of the deployment sets it for the whole deployment.Recorded in the AI disclosure register.
See it in an example
Simulation. A scripted example on fictional data. The wording is scripted and no model is called; the figures are computed from what you decide, and a person’s approval covers exactly what you decided.
See what stops when someone's access is withdrawn
- What happened
- A regional manager at Kestrel Logistics (fictional) has left, and the head of IT wants to know what withdrawing her access stops, and what only narrows.
- The question
- If an identity or a permission is withdrawn, which views and answers stop, and which only lose some detail? Asked by: Head of IT at a customer (fictional).
See what stops when someone's access is withdrawnChoose what is withdrawn. Everything downstream is worked out from the access map: a hard link stops the next thing, a soft one only narrows it.Open
Choose what is withdrawn. Everything downstream is worked out from the access map: a hard link stops the next thing, a soft one only narrows it.
Fail one or more items and see what stops and what only degrades, worked out by following the dependencies.
Choose what is withdrawn. Hard dependencies stop with it; soft ones carry on, degraded.
- Comes from the company's identity provider.
- Decides what she may do.
- Kept on the server, so they can be ended.Depends on: Her sign-in identity (hard)
- Decides which records she may see.
- Limited to her scope.Depends on: Her sessions (hard), Her location scope: North depot (soft)
- Use only what she may see.Depends on: Her sessions (hard), Her location scope: North depot (soft)
- Need her role and a recent re-sign-in.Depends on: Her role: location manager (hard)
- Kept in the audit trail.Depends on: Approvals she may give (soft)
- is withdrawn
- 0
- Stops as a result
- 0
- Degraded
- 0
- Unaffected
- 8
0 withdrawn; 0 stop and 0 are narrowed. The first to withdraw, to stop the most: Her sign-in identity.
Stopped: none. Narrowed: none [S1].
What she did before she left stays in the audit trail: withdrawing access does not erase it and does not re-attribute it to anyone else [S2].
Relies on: S1 · Access map for the regional manager (fictional)S2 · Audit trail extract for her account (fictional)
The customer's head of IT decides. Approving records the access change to be made. It does not make the change in the customer's own identity provider and it does not delete any record.
Not ready. Fail at least one item first, to see what depends on it.
Not done here. It does not change anyone's access in a customer's own systems, and it does not rewrite the audit trail.
What a reviewer can have, and what not yet
- We can hand overThe access-control sections of the security assurance record, with the name of the automated test behind each statement.
- We cannot yetA run of those tests against a deployed environment, and any independent test of the separation between organisations.
The capabilities behind this
- Permissions, approvals and an audit trailWhen something goes wrong, nobody can say who could do what, who approved it and when.
- Govern the AI your organisation usesTeams adopt AI tools faster than anyone records them, who approved them or what they may touch.
The other nine
- Read-only database connectionsWhat a read-only connection proves before every use, what it cannot do, and what a customer's administrator should check first.
- Uploaded dataLimits, what is read and what is not, and the checks that are not done.
- AI provider disclosuresWhich features can send content outside the platform, what they may send, and what has not been established.
- Encryption and access controlsWhat protects sign-in, sessions and secrets, and the controls that only a live inspection can settle.
- Audit evidenceA tamper-evident decision record, what it proves, and what it cannot.
- Human approvalsWhat an assistant may draft or propose, what it refuses, and how a person's decision is recorded.
- Data retention and deletionWhat can be deleted now, what must wait, what is kept by design, and what is not finished.
- Customer-hosted and dedicated deploymentUpload, read-only connection, natural-language questions, a customer-hosted connector and a dedicated environment: what exists.
- Pilot security requirementsThe twenty-item gate, what it counts, and what is open.