Security
Asqav's security model is built around tamper-evident audit trails for AI agent actions. Every signed action uses NIST-standardised ML-DSA (FIPS 204), a lattice-based signature scheme finalised in 2024.
Data residency choices are part of the security posture. Bring-your-own KMS, the self-hosted signer, and air-gapped on-prem mode let you keep ML-DSA private keys and raw payloads inside your boundary. All three are available: BYOK on Enterprise, the self-hosted signer in self-hosted-signer, and air-gapped mode with offline license validation and zero outbound HTTP.
Why ML-DSA?
AI agent audit trails carry long retention obligations: the EU AI Act binds records to system lifetime plus a reasonable extension, DORA mandates at least five years for ICT logs, financial-services regimes routinely demand seven to ten. ML-DSA (Module-Lattice Digital Signature Algorithm) is a lattice-based scheme that NIST finalised in FIPS 204 after seven years of public evaluation, giving signatures the long-horizon assurance those retention windows require.
ML-DSA (FIPS 204)
ML-DSA (Module-Lattice Digital Signature Algorithm) is a NIST-standardised lattice signature scheme, published as FIPS 204 in August 2024.
Security Levels
| Algorithm | NIST Level | Classical Equivalent | Quantum Security |
|---|---|---|---|
ml-dsa-44 |
Level 2 | ~128-bit | ~64-bit |
ml-dsa-65 |
Level 3 | ~192-bit | ~96-bit |
ml-dsa-87 |
Level 5 | ~256-bit | ~128-bit |
Key and Signature Sizes
| Algorithm | Public Key | Secret Key | Signature |
|---|---|---|---|
ml-dsa-44 |
1,312 bytes | 2,560 bytes | 2,420 bytes |
ml-dsa-65 |
1,952 bytes | 4,032 bytes | 3,309 bytes |
ml-dsa-87 |
2,592 bytes | 4,896 bytes | 4,627 bytes |
Multi-Party Signing
Multi-party signing splits an ML-DSA-65 secret key into n Shamir shares so that any t shares can reconstruct the signing capability - but fewer than t reveals nothing. The output is a standard ML-DSA-65 signature, indistinguishable from a single-party signature.
See the Multi-Party Signing guide for setup and API usage.
Key Management
Agent private keys are stored securely based on your tier:
| Tier | Storage |
|---|---|
| Free | Encrypted at rest (AES-256-GCM) |
| Enterprise | Bring-your-own KMS (customer AWS KMS or GCP KMS, FIPS 140-3 Level 3) |
The Asqav SDK never handles private keys. All ML-DSA cryptography happens server-side.
Timestamping and Immutable Proofs
Daily Immutable Audit Proofs (All Tiers)
All tiers receive daily Bitcoin-anchored proofs of audit trail integrity via OpenTimestamps. This provides:
- Daily cryptographic proof that logs haven't been tampered with
- Hash chain integrity verified against Bitcoin blockchain
- Independent verification without trusting Asqav infrastructure
Per-Signature Immutable Proofs (all tiers)
Every tier including Free receives individual blockchain proof for each signature via OpenTimestamps, providing:
- Exact timestamp proof for each signature
- Tamper-evident evidence of when each action occurred
- Independent verification via Bitcoin blockchain
RFC 3161 Timestamps (Enterprise)
Enterprise fills the RFC 3161 timestamp slot two ways. By default the token is issued by Asqav's own time-stamping authority, signed with ML-DSA-65 (RFC 9882). When you configure an external authority with a pinned root, the slot is instead filled by an unaffiliated public TSA such as an EU-government QTSP. The Asqav-issued token is self-issued, not a third-party certified TSA, unless that external path is configured. Either token supports:
- A tamper-evident record of when each action occurred
- Audit trails for regulatory recordkeeping
- Independent verification against the published verify key
Asqav does not make legal admissibility claims. Whether a timestamp meets a given legal or evidentiary standard is for the customer and its legal counsel to determine.
OCSP Verification
OCSP (Online Certificate Status Protocol) verification is available on all tiers. Any third party can verify an agent's revocation status without authentication:
- Public endpoint for third-party verification
- No API key required to check status
- Returns good, revoked, or unknown
Compliance
Helps with compliance for:
- EU AI Act - Article 14 requires AI systems to maintain audit trails
- SOC 2 - Cryptographic audit trails for security controls
- GDPR - Provable data processing records
- HIPAA - Healthcare data access logging
Security Best Practices
- Rotate API keys regularly - Generate new keys every 90 days
- Use environment variables - Never hardcode API keys
- Revoke promptly - If an agent is compromised, revoke immediately
- Monitor sessions - Review audit trails for anomalies
- Use appropriate security level - ML-DSA-65 for most use cases, ML-DSA-87 for highly sensitive data
Take the readiness assessment to evaluate your current AI agent governance posture, or use the Setup Wizard to get started with the right configuration for your compliance needs.
Reporting Security Issues
If you discover a security vulnerability, please report it via GitHub Issues. We follow responsible disclosure practices.