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 of submitted artifacts 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 a controls testing or penetration testing service

Trust boundaries in one view

AttestLayer issues structured, reviewer-verifiable proof packages
AttestLayer does not certify customer controls
AttestLayer does not replace the customer’s own records
AttestLayer does not require system installs
AttestLayer does not require system access

Optional walkthrough

Trust model walkthrough

How AttestLayer uses signed receipts, manifests, verification materials, and record-only boundaries without requiring installs or system access.

Open video file

Transcript

Title: Trust model walkthrough

Duration: 55s

What the viewer will learn: How record-only proof material, signed receipts, manifests, and verification boundaries fit together.

0:00 — AttestLayer handles submitted records without installing software or accessing customer systems.
0:11 — Evidence is evaluated against the active ruleset for PASS or exact FAIL blockers.
0:22 — A PASS creates a structured kit with manifest, receipt, binder, and verification materials.
0:33 — Reviewers can check integrity and issuance through Verify or bundled tools.
0:44 — The output supports packet verification; downstream diligence remains separate.

Legal/trust boundary: AttestLayer verifies packet integrity and issuance; customer and reviewer decisions remain separate.

What this helps with

Forwardable internal review
Customer-facing handoff
Counterparty review
Procurement preparation
Exact blocker visibility on FAIL

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 (Montreal, Quebec, 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 key (issuer.jwks.json) — signs receipts inside every PASS verification kit. This is the key verifiers check when validating a kit. Current kid is published in the JWKS.
Registry key (registry.jwks.json) — signs checkpoints in the append-only transparency log. This is the key auditors check when verifying log integrity. Current kid is published in the JWKS.

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

The registry is currently self-witnessed by AttestLayer. Checkpoints are signed by the registry key and published at registry.attestlayer.com. Receipts inside verification kits are signed by a separate issuer key. External witness cosignatures are structurally supported but not yet active. Do not infer third-party witnessing, external notarization, or external anchoring unless this page explicitly says they are active. When independent witnesses are onboarded, this section will be updated.

External witnessing, external anchoring, and third-party cosignatures must not be marketed 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

What reviewers cannot infer

A PASS kit proves that submitted artifacts satisfied the applicable AttestLayer validation rules for that kit.

It does not prove that the customer’s controls are effective, that the customer is compliant with a regulation or framework, that the customer passed an audit, or that a buyer must approve the vendor.

Verification infrastructure

Public key registry — signing keys are published at registry.attestlayer.com
Key rotation — keys rotate on a defined schedule with full history preserved
Verify portal — verify.attestlayer.com provides client-side proof verification
Deterministic evaluation — repeatable under the same ruleset, schema version, adapter profile, and validation version.

Policies

Security

Security model and controls

Privacy

Terms

Cookies

Cookie and browser-storage notice

DPA

Controller-processor terms

Subprocessors

Third-party subprocessors

Refund / Billing

Refund policy

Console controls and buyer workspace

The AttestLayer Console provides browser-first workspace access for uploads, PASS/FAIL outcomes, credits, deliverables, reviewer handoff, and optional technical access. Console use remains subject to the Console Product Addendum, Product Terms, Data Retention Policy, Security Overview, and applicable plan terms.

No installs or system access required for browser-first workflows.
Workspace access is issued through approved onboarding or access workflow.
PASS consumes 1 credit; FAIL burns 0 credits.
Reviewer verification can occur outside the customer workspace where public or offline verification materials are provided.
API access, role controls, activity export, SSO, MFA, or enterprise controls depend on plan and active configuration.