Sengol
What exists today. Not a roadmap.
Everything on this page is shipped and enforced, not planned. Sengol runs inside your perimeter, holds your keys where you tell it to, and produces evidence a third party can check without a Sengol server.
No phone-home
Sengol does not call home. Licences are checked offline against a public key, evaluators run against a judge endpoint you configure, and a self-hosted install works identically air-gapped or connected. There is nothing in the product whose function depends on reaching a Sengol server at runtime.
Verify without trusting us
Every record is HMAC-signed; audit records are also hash-chained per agent, and Ed25519-countersigned when a countersigning key is configured. An auditor checks a bundle with sengol-verify — a separate open-source tool with no dependency on Sengol, no network call, and no licence to hold. If Sengol disappeared tomorrow, evidence already exported could still be checked offline for chain continuity. The HMAC needs your key, so it is checked against the store, not offline. Proving who signed needs a countersigned bundle checked against a public key you obtained out of band, which sengol audit verify --offline --trusted-key accepts and sengol-verify does not yet; a timestamp anchor shows only when it existed.
Who can do what, provable after the fact.
-
Entra ID / OIDC single sign-on
Sign in through your identity provider with app-role mapping, re-derived on every login.
-
SCIM provisioning
User and group lifecycle synced automatically from your IdP — provisioned and deprovisioned without a ticket.
-
Local users with TOTP MFA
No IdP required. Local accounts support time-based one-time-password multi-factor authentication.
-
Audited break-glass
An emergency access path exists for when SSO is down — and each use is recorded individually, in the token-issuance log rather than as signed evidence.
-
Ten built-in role templates
Identity-provider groups usually map to four of them — admin, approver, auditor (read-only) and viewer — a fixed, well-understood set rather than a role you have to design yourself.
-
Signed decisions
Judge promotions, separation-of-duties decisions and erasure tombstones are signed records. Other administrative changes, such as role and configuration edits, are not signed; where they are recorded at all, it is as a log line.
Your keys, your VPC, a hardened supply chain.
-
Signing keys in AWS KMS
Evidence signing can use a key held in AWS KMS instead of an environment variable. The shipped Docker Compose, Helm and Terraform paths default to a local key held in the process environment; selecting KMS is a configuration step.
-
Non-root containers
Every shipped container runs as a non-root user by default — no privilege to drop that you have to remember to configure.
-
SBOM and signed images
A software bill of materials ships with every release, and container images are signed so you can verify provenance before you deploy.
-
Runs in your VPC
Docker Compose, Helm or Terraform, on AWS, Azure, GCP, OpenShift or on-prem. Nothing about the architecture requires a connection out.
-
Air-gap capable
Runs fully disconnected when that's the requirement. Licence checks are offline; nothing else needs a network path to Sengol.
-
No telemetry
Sengol does not collect usage telemetry from your deployment and send it anywhere. What you run stays yours to observe.
Erasure that doesn't break the chain.
-
Tombstone erasure
A data-subject erasure or right-to-be-forgotten request replaces the underlying content with a tombstone while preserving the hash chain — erasure doesn't leave the evidence trail unverifiable. Erasure is two-person by default: one principal proposes and a different principal approves. The appliance compares the two sign-in identities; it cannot tell whether one human holds both. Retention floors are not enforced, so nothing today delays an erasure by the age of the record.