Access and governance: the company brain never gives more access than the asking user

Every read from the brain is made on behalf of someone. The rule is simple to state: the brain never gives more access than the asking user has. An assistant answering a question for an analyst sees what the analyst could see in the source systems, and nothing more. An agent acting for a manager is limited to that manager’s view, narrowed further by what the agent itself is allowed to do.

The rule exists because a brain changes where the risk sits. Information that was safely scattered across systems becomes reachable from one place. Without identity-aware access, the brain would become the easiest route to everything. With it, connecting another source adds context without widening who can see what.

Content objects keep the access list copied from their source. When a search runs, the database compares that list with the asker’s principals and returns only what matches. If an object’s access list is unknown or incomplete, the object is treated as invisible. The design fails closed: missing information about who may see something means nobody sees it through the brain.

When the brain cannot identify the asker as a person at all, it offers only what is tenant-wide, the information every member of the organisation could see anyway. The content store and permission-filtered search that apply these rules exist as libraries with passing tests; the HTTP endpoints that expose them are in progress and not yet finished.

Every row in the store belongs to a tenant, and row-level security in the database keeps tenants apart. Isolation is enforced by the database, not left to application code to remember on every query. The tenant for a request comes from its credential, so a request cannot reach another tenant’s data by naming it.

The appliance uses two database roles. The runtime role that serves requests cannot own the schema and cannot bypass row-level security. A separate role manages the schema. So a fault in the serving code cannot switch isolation off, because the account that code runs as does not have the right to do so.

Anything the brain retrieves, whether a document, a ticket comment or an email, is treated as data, never as instructions. Retrieved content is untrusted and cannot override policy. A paragraph in a document that tells an assistant to ignore its rules and reveal salaries is just a paragraph, and the access rules and policies that apply to the request do not change because of it.

Before content reaches any model, a sanitisation gateway is designed to remove or mask what must not be sent: personal data, restricted fields, values that look like secrets. The gateway exists in code and is in progress, so it is not yet something to rely on. Secret-looking values are already removed before anything is stored in the brain.

The appliance writes its actions to a hash-chained audit log with signed checkpoints, so tampering with the record is detectable. The log can be read through the local API by tokens that are scoped to read it. It shows what the appliance did, which is the starting point for any review of how the brain has been used.

The appliance connects outward only, over mutual TLS, and accepts only signed, typed commands from an allow-list. There is no shell capability. A local kill switch, recorded in a journal, cuts the link from inside your environment. The appliance runs in one of three modes: connected, private with a control plane you host, or air-gapped with no outbound connection at all.

Swfte provides the technical controls, governance mechanisms and evidence required to deploy AI within an organisation's applicable regulatory, security and policy requirements. The exact posture depends on the customer's use case, jurisdiction, deployment and configuration. The controls on this page are part of how the brain runs, so your security, privacy and legal teams can use them in their own work. Deploying the brain does not discharge any obligation on its own, and this page is not legal advice. Swfte does not hold a SOC 2 report, an ISO 27001 certificate or a HIPAA BAA today. A SOC 2 Type I audit is in preparation; the trust page lists what is in place and what is in progress.

A practical way to use the controls: map each obligation you hold to the control that supports it and the evidence it produces, such as the audit log for traceability, the erase command for deletion requests and local-only storage for data residency. Where a control is in progress, such as the sanitisation gateway, record it as a gap rather than as covered.