SHA-256 Bundle Hashes
When policies compile, the platform generates a unique SHA-256 checksum representing the complete set of rules. Runtimes cross-check this hash prior to rule enforcement to confirm that no in-transit tampering occurred.
Last updated: May 22, 2026. This document details the security architecture, data protection controls, and compliance standards active across the Spctre platform.
Spctre employs defensive security configurations to safeguard your policy bundles, evaluation metrics, and administrative audit trails:
All network communication with our hosted control plane, API endpoints, and decision gateways is strictly encrypted using TLS 1.3 (with TLS 1.2 as a minimum fallback). Perfect Forward Secrecy is enforced for all cipher configurations.
Production databases, transaction records, backups, and file storage volumes use the default encryption at rest provided by Google Cloud managed services. Spctre does not currently configure customer-managed encryption keys, Google Cloud KMS, or HSM-backed key management.
System databases are backed up with point-in-time recovery enabled. Spctre does not currently claim geographically isolated backup zones, independent backup encryption keys, or scheduled restore-verification exercises.
Policy injection is a major risk vector in autonomous systems. Spctre enforces rigid cryptographic controls to block unauthorized rule alterations:
When policies compile, the platform generates a unique SHA-256 checksum representing the complete set of rules. Runtimes cross-check this hash prior to rule enforcement to confirm that no in-transit tampering occurred.
Policy changes are captured as versioned, append-only revisions in Spctre’s control plane. Published policy bundles link to their branch, revision, artifact hash, reviewer approval records, and verification simulation outputs.
Spctre retains the exact bytes of every published bundle alongside a stable content hash, rather than re-serializing the policy on demand. Verification and evidence checks compare against what actually shipped to the runtime, and each decision record names the evaluator version that produced it — so a past decision remains reproducible after an upgrade.
Our rule engine does not support arbitrary runtime string injection. All rules must be built into structured, signed bundles, preventing remote-code-execution (RCE) vectors via compromised rule files.
Organization resources operate in isolated workspace partitions. Dynamic access filters are applied at the database abstraction layer, rendering data from other workspaces completely invisible to active connections.
Spctre Enterprise supports SAML 2.0 single sign-on (SSO) and SCIM provisioning (Okta, Microsoft Entra, Google Workspace), letting you inherit corporate password and MFA policies alongside centralized user deprovisioning.
Developer credentials and service accounts are restricted by role. A token assigned to capture runtime audit logs has no compile permissions and cannot read active policy bundle source code.