Threat Model

Updated Oct 20, 2026

This page states the threats Asqav is designed to resist, the boundaries where trust changes hands, and the risks that remain after the controls. It covers the receipt and evidence layer, not the customer's agent runtime. The change controls and security posture pages carry the mechanics this model relies on.

Assets

Asset	Why it matters	Where it lives
Signed receipts and their hash chains	They are the evidence an auditor tests	Cloud database; exported audit packs
Signing keys	A key that signs a false action forges evidence	Server-side custody, encrypted at rest; BYOK or self-hosted signer on Enterprise
Tenant data and metadata	Cross-tenant exposure breaks confidentiality	Tenant record tables behind row-level security (identity-resolution tables exempt)
Holder salt and keyed tags	They prove a digest was keyed by the service, not the caller	Server-side, encrypted at rest, never emitted
Anchors and transparency leaves	External anchors and an externally witnessed tree head bound when a receipt existed without trusting Asqav alone; the default timestamp token and the transparency service are Asqav-operated	RFC 3161 and OpenTimestamps; digest-only leaf

Trust boundaries

Caller to cloud. The SDK sends a SHA-256 digest and a whitelisted metadata bag by default. Raw context crosses only when full-payload mode is enabled on both the deployment and the organization.
Cloud to signer. Signing happens server-side; the SDK never holds a private key. Enterprise can move the key into customer KMS or a self-hosted signer.
Cloud to third parties. Timestamp and anchoring calls carry digests, not payloads, and pass through the egress gate. ASQAV_AIRGAPPED removes outbound calls.
Public verifier to record. The public verify surface reads stored records and writes nothing; the transparency leaf commits to a receipt digest, not tenant data.

Attack surface

The surfaces that accept input or hold evidence are the public verify API, the authenticated API and dashboard, the SDKs and CLI, the server-side signer, the database and holder salt, the outbound timestamp and anchoring calls, and the CI and release path. Each surface below is paired with the adversary it faces and the control that constrains it.

Adversaries

Threat	Mitigation	Residual risk
Forged or altered receipt	ML-DSA-65 signatures over canonical payloads (FIPS 204); the verifier evaluates the signature and reports fail rather than pass when it does not hold	A forged receipt that never verifies can still be presented; rely on the verifier's verdict
Tampered or spliced history	Per-agent hash chains commit each receipt to its predecessor; a fork or a broken link fails verification	The chain proves order within an agent, not that every action was recorded; a self-consistent replacement chain from a compromised signer verifies on its own, and external checkpoints and anchors only constrain that
Reuse of an old receipt	Receipts carry an expiry and a signing-time nonce bound into the signed bytes; stored-record reads are org-scoped and gated	A receipt reused inside its validity window is still valid evidence
Cross-tenant read	Tenant record tables carry row-level security, reads are org-scoped, and a CI census checks every record table; identity-resolution tables are exempt by design	A database role that bypasses RLS defeats the row policy; the org filter remains explicit
Key compromise	Suspension and revocation stop new signing; historical receipts still resolve to the key that signed them so old evidence does not break	A key used before revocation can have produced valid-looking receipts; revocation does not rewrite history
Operator or insider tampering	Receipt rows are retained for the org's retention window, the transparency leaf is digest-only, and the strongest anchors (Bitcoin, a configured external timestamp authority) are outside Asqav; merge-time change controls bind administrators	Asqav operates the signer and the database. A compromised operator could build a self-consistent alternative signed history that verifies on its own; anchors prove existence and constrain rollback, not completeness. The change-controls page covers merges, not production database or signer access
Database breach	Hash-only mode keeps raw context out; the holder salt is encrypted at rest and never emitted; keyed digests are server-computed	A breach that also steals the salt lets an attacker recompute keyed tags for stored digests
Transport and browser attacks	TLS to the API, CORS allowlists, CSRF tokens on cookie-authenticated writes, and rate limits on public and auth routes	An endpoint compromised before signing is outside this model
Anchoring unavailable or pending	Anchoring is recommended (SHOULD) and may be absent; a pending OpenTimestamps proof is reported, the upgrade bound is seven days, and the selected policy decides whether exceeding it fails verification	Absent anchoring is not proof of absence; a policy that requires it must enforce that requirement
Supply-chain compromise	Pinned dependencies and a lockfile freshness gate run in CI, with Bandit, pip-audit and Trivy; the merge gates are listed on the change-controls page	A compromised upstream release can still pass a scan that has no advisory yet

Residual risk

Out of scope

The honesty of the action fields a caller submits. Asqav signs what the caller asserts; it does not observe the agent's runtime.
An endpoint or SDK host compromised before a request reaches Asqav.
The customer's own key custody in BYOK or self-hosted deployments.
Legal acceptance by an auditor or regulator. A verifiable receipt supports a review; it does not guarantee an outcome.
Removal of a digest already anchored to Bitcoin or a public timestamp authority.

Reporting a weakness

Email info@asqav.com with the subject Security report: <short description>. The acknowledgement and mitigation windows are on the public security page.

References

RFC 3161: Time-Stamp Protocol, IETF
OpenTimestamps, OpenTimestamps
FIPS 204: Module-Lattice-Based Digital Signature Standard, NIST