Know what runs.
Know where data goes.
Clear execution boundaries for Actions. Traceable evidence for verifier audits. Your organization decides which devices and workloads it trusts.
- Explicit device approval
Organization-approved hosts and trusted workflow jobs.
- Account checks on every request
Expiring sessions, host-only cookies and same-origin writes.
- Revision-bound audit evidence
Recorded check outcomes and the methodology applied.
What the audit keeps.
The public mark is a summary. The durable, versioned record is the basis for it.
Everything the audit decided, and whyEvery Tbench Certified result links to a retained audit record. Each check stores its verdict, duration, detail and recorded remedy so reviewers can trace the decision.
per-check verdict, detail and remedy retained
A revision, fixed at submissionEvery result records the methodology revision applied to that audit. Re-auditing under a newer revision creates a separate evidence record.
methodology version recorded per certificate
Every outcome stays traceableRefused audits remain in the register under their original identifiers, alongside the recorded outcome.
refusals retained and verifiable
What protects it.
These are the controls the platform implements today, with the evidence behind each claim available in the disclosure.
Private database networkingPostgres is reachable by the API over the internal compose network. Port 5432 is not published on the host.
db: 5432/tcp, no host mapping
Data at rest is encrypted by the volume underneathThe recommended deployment places the database on an encrypted EBS volume. Encryption is configured at volume creation and belongs to the underlying block storage.
EBS encryption, enabled at instance creation
The containers are locked downThe API container runs with a read-only root filesystem, no privilege escalation, and all Linux capabilities dropped except the ones it needs. A compromised process has less to work with.
read-only rootfs, cap_drop: ALL
Backup and restore proceduresDumps are taken in Postgres custom format, which is restorable and verifiable. The restore procedure is documented and has been run end to end against the live stack — including a scrub-restore into a throwaway database that cannot touch production.
pg_dump -Fc, restore drilled
Deployment scope.
Review these requirements alongside your organization’s infrastructure and execution policy.
- 01
Encryption at rest depends on the deployment's block-storage configuration.
- 02
Runtime credentials use restricted deployment configuration and an explicit rotation process. Keep model keys and GitHub App private keys off contributor devices.
- 03
The recommended deployment exposes 443 and uses 80 for certificate issuance. Intrusion detection and fail2ban are outside the current configuration.
- 04
Selected authentication, registration, lookup and expensive operations have API rate limits. Tenant permissions remain a separate control.
- 05
The current deployment is single-instance, without automatic failover.
- 06
Contributor devices provide local rehearsal evidence. Independent certification requires trusted required-stage results.
The session.
Sign-in issues a signed, expiring token. The API checks the account on every request, so account deactivation and role changes apply to the next request.
The web server holds the credential in an HTTP-only, host-only session cookie; browser JavaScript does not receive it. State-changing requests require an exact same-origin request. Sign-out and password changes revoke account sessions. A readable session hint is only a loading optimisation, never an authentication grant.