Trust Center
What AttestLayer is, what it is not, how data is handled, and how reviewers can verify issued output.
What AttestLayer is
- A record-only evidence issuance service
- Deterministic PASS/FAIL evaluation under a defined ruleset, schema version, adapter profile, and validation version
- Signed, forwardable verification kits with offline verification support
- No system access, no installs, no agent footprint
What AttestLayer is not
- Not an audit firm and does not issue audit opinions
- Not a compliance certification body
- Not a legal advisor
- Not controls testing or penetration testing
Security posture
- Ed25519 signing — every PASS kit includes a cryptographic receipt signed with Ed25519 keys
- SHA-256 manifests — artifact integrity is bound to a hash manifest at submission time
- Offline verification — proof kits include a self-contained verifier; no live session required
- Record-only model — no system access, no installs, no agent footprint
- Published security model — security documentation and verification procedures are published and reviewable
Data handling
- Data residency — all processing and storage in GCP northamerica-northeast1 (Montréal, Canada)
- Encryption at rest — AES-256 via Google-managed encryption keys
- Encryption in transit — TLS 1.2+ for all connections
- No customer names in registry — registry receipts contain only hashes and timestamps
- Artifact retention — Uploads: up to 24 hours (automatic deletion). Hosted deliverable links: 30 days for Activation (links expire; automatic deletion); Monthly Coverage subscribers retain access during active subscription. Payment/invoice records: 7 years (standard accounting/tax retention). Downloaded copies are kept by you, outside our control.
How signatures are verified
AttestLayer uses two distinct Ed25519 key pairs. Both are published at the registry so any third party can verify independently:
Issuer keySigns receipts inside PASS verification kits. Published at issuer.jwks.json.
Registry keySigns checkpoints in the append-only transparency log. Published at registry.jwks.json.
Both key sets are published at the registry and never deleted on rotation — revoked keys remain for historical verification. The two key pairs are completely separate: the issuer key never signs checkpoints and the registry key never signs receipts.
Current registry trust model
RegistryLive and publicly readable
CheckpointsSelf-issued by AttestLayer
Receipt signingSeparate issuer key
External witnessingNot active
External anchoringNot active
Third-party cosignaturesNot active
Do not market external witnessing, external anchoring, or third-party cosignatures as active until they are active in production and visible in public verification material.
What reviewers can verify independently
- Receipt signature — verify the Ed25519 signature against issuer.jwks.json
- Manifest integrity — recalculate SHA-256 hashes and compare to the manifest root
- Checkpoint inclusion — confirm the receipt hash appears in a signed registry checkpoint (signed with registry.jwks.json)
- Key history — audit the full key rotation history at both JWKS endpoints
- Offline verification — use the bundled browser verifier included in the kit, without a live session
Verification infrastructure
Public key registrySigning keys are published at registry.attestlayer.com
Key rotationKeys rotate on a defined schedule with full history preserved
Verify portalverify.attestlayer.com provides client-side proof verification
EvaluationSame input always produces the same PASS/FAIL result
Policies
Security
Security model and controls
Privacy
Privacy policy
Terms
Terms of Service
Subprocessors
Third-party subprocessors
Refund
Refund policy