Trust · Encryption and access controls
How are accounts, sessions and secrets protected, and what must be checked on the live system?
The record separates what is built and tested from what depends on how a real environment is set up. Encryption at rest and transport settings sit in the second group.
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 locallyPasswords are stored as Argon2id hashes.Recorded in the security assurance record.
- Tested locallySensitive decisions need a fresh sign-in, checked against the session on the server.Recorded in the security assurance record.
- Tested locallyEvery route sends browser protection headers against framing and content sniffing, and production sends two-year HSTS.Recorded in the security assurance record.
- Reviewed in codeIdentity secrets and recoverable worker-page tokens are encrypted with AES-256-GCM, bound to their record.Recorded in the security assurance record.
- Tested locallyProduction refuses to start without its required secrets, and never prints a secret value.Recorded in the security assurance record.
- Needs checking on a live systemEncryption at rest for object storage and the database is a setting of the provider, not of the application, and has to be inspected on the real environment.Recorded in the security assurance record.
- Needs checking on a live systemWhere production secrets are stored, how they are rotated and who can read them depends on the secret manager's configuration.Recorded in the security assurance record.
- Not establishedTransport security and storage settings have not been inspected on a deployed environment, so nothing is claimed about them.Recorded in the pilot evidence pack.
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.
Review the controls like a customer's security reviewer
- What happened
- The security team at Harbourline Insurance (fictional) holds the platform's control list and is deciding which entries it needs evidence for before a pilot.
- The question
- Which statements need evidence from the live system before the reviewer accepts them? Asked by: Security reviewer at a customer (fictional).
Review the controls like a customer's security reviewerEach flagged control rests on something the code cannot prove. Mark it to ask for evidence, or mark it accepted on the record's own terms.Open
Each flagged control rests on something the code cannot prove. Mark it to ask for evidence, or mark it accepted on the record's own terms.
Review each flagged record: confirm it or dismiss it. The totals and the answer below follow your decisions.
Control Level in the record What it depends on Controls affected Finding Decision Password hashing Tested locally The code 1 Matched None needed Session cookies, prefixed and secure Tested locally The code 1 Matched None needed Browser protection headers Tested locally The code 1 Matched None needed Transport security on the real address Needs checking on a live system The real address's configuration 1 Depends on how the real address is set up Encryption at rest, storage and database Needs checking on a live system The provider's settings 1 A provider setting, not proved by the application's code Secret storage, rotation and access Needs checking on a live system The secret manager 1 Depends on how secrets are stored and who can read them Private storage with scoped credentials Needs checking on a live system The cloud account 1 Depends on the cloud account's configuration Database account without evidence-table privileges Tested locally; set-up needs checking How the real database is provisioned 1 The set-up on the real database has to be inspected - Flagged
- 5 of 8 · 5
- Ask for evidence
- 0 · 0
- Accept as recorded
- 0 · 0
- Undecided
- 5 · 5
5 of 8 controls rest on something only the live system can show; you asked for evidence on 0.
The record separates what is tested locally from what depends on production configuration [S1]. Accepting a deployment-dependent control without evidence is the reviewer's decision, and the record says what would settle each one [S2].
0 accepted as recorded, 5 still undecided.
Relies on: S1 · Control list with the level the record gives each (fictional extract)S2 · What would settle each deployment-dependent control
The customer's security reviewer decides. Approving sends the evidence requests to the vendor. It does not accept any control as met.
Not ready. 5 flagged controls are still undecided. Confirm or dismiss each one first.
Not done here. It does not certify anything: each control is described at the level the record supports, and none of it is an audit result.
What a reviewer can have, and what not yet
- We can hand overThe security assurance record, with its status for every control and the test behind each one.
- We cannot yetInspections of the live system's transport, storage and secret settings, and any independent penetration test.
The capabilities behind this
- Assurance and evidenceWhen an auditor or an inspector arrives, evidence has to be found in a hurry, and gaps appear for the first time.
- A Trust and Security area for customersSecurity and procurement teams ask the same questions again and again, and the answers are scattered.
The other nine
- Customer-controlled accessAccess by organisation, role and location, decided on the server, and what stops when it is withdrawn.
- 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.
- 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.