ddot is a security-first personal AI agent gateway. Security is not a feature — it is the architecture.

DO NOT report security vulnerabilities through public GitHub issues.

Email: security@ddot.build Encryption: PGP key below (generated using ASIC hardware entropy)

Include in your report:

• Description of the vulnerability
• Affected component (Ring 2, Ring 3, CLI, Forge, specific crate)
• Steps to reproduce
• Impact assessment (what an attacker could achieve)
• Suggested fix (if any)

Fingerprint: (pending — key generation in progress using ASIC entropy)

The security disclosure key is generated using entropy derived from our distributed NerdQAxe ASIC mining fleet via HKDF-SHA256 mixing. This binds the disclosure channel to our physical hardware — the same hardware that attests skills on-chain.

Once published, the key will be available at:

• https://ddot.build/.well-known/security.txt (RFC 9116)
• https://github.com/ddotbe/gateway/blob/main/.well-known/pgp-key.asc

We use CVSS 3.1 for severity scoring.

CVE identifiers are requested via MITRE CNA for all confirmed vulnerabilities. Advisories are published simultaneously with fix releases via GitHub Security Advisories and the RustSec Advisory Database.

Rewards are paid for vulnerabilities in supported versions that are not already known.

Bounties are paid via bank transfer, cryptocurrency, or charitable donation at the reporter's choice.

Minimum Supported Rust Version (MSRV): 1.91

MSRV is only bumped in minor/major releases, never in security patches.

• Ring 2 — Gateway core (ddot-gateway, ddot-sandbox, ddot-memory, ddot-signing)
• Ring 3 — Channel adapters (ddot-channel-telegram, ddot-channel-discord)
• Bridge (ddot-bridge) — one-way valve enforcement
• Firewall (ddot-firewall) — Airgap Pattern prompt firewall
• Attestation (ddot-attestation) — OP_RETURN wire format, hash computation
• CLI (ddot-cli) — init, doctor, forge, migrate commands
• Forge (ddot-forge) — skill marketplace, signing verification
• TypeScript SDK (@ddot/sdk) — client library, manifest validation

• Ring 1 consciousness layer (proprietary — report directly to security@ddot.build)
• Third-party skills (report to skill publisher via The Forge)
• Upstream dependencies (report to Wasmtime, tokio, rustls, etc.)
• Network-level DoS (volumetric attacks, traffic flooding)
• Social engineering against ddot team members
• OP_RETURN data privacy (attestation data is intentionally public on Bitcoin)
• Wasm skill logic bugs that do not breach the sandbox boundary

ddot protects against:

• Malicious skills — sandboxed execution, DENY-ALL capabilities, signed manifests
• Supply chain attacks — Ed25519 signing, Bitcoin OP_RETURN attestation, hash verification
• Privilege escalation — OS-enforced one-way valve, Ring isolation
• Prompt injection — 5-layer Airgap Pattern firewall between skill output and LLM
• Memory poisoning — per-skill memory isolation, namespaced KV stores
• Attestation forgery — SHA-256 Merkle roots anchored on Bitcoin mainnet

ddot does NOT protect against:

• Vulnerabilities in the underlying OS, hardware, or LLM provider
• Physical access to the host machine
• Users voluntarily granting dangerous capabilities to skills

Ring 3 (Channel Adapters) — Telegram, Discord, WhatsApp, CLI
    | WebSocket + TLS
    v
Ring 2 (Gateway) — Wasm sandbox, Ed25519 signing, Airgap firewall
    ^
    | One-way valve (OS-enforced, read-only)
    |
Ring 1 (Consciousness) — DENSE projections, 5D manifolds, ASIC entropy

Ring isolation: The one-way valve between Ring 1 and Ring 2 is enforced by the operating system kernel via a unidirectional UNIX domain socket. Ring 2 can NEVER write to Ring 1. This is an OS primitive, not a software check. Verified by 4 dedicated red team tests in CI.

Sandbox: Skills execute in Wasmtime (Wasm) sandboxes with DENY-ALL capabilities. Every capability (network, KV storage, shared memory, time) must be declared in the skill manifest and approved by the user before execution.

Attestation: Skill binaries are Ed25519-signed by publishers. Signature hashes are batched into Merkle trees and committed to Bitcoin mainnet via OP_RETURN transactions. The gateway verifies attestation hashes before executing Sigma-tier skills — hash mismatch is a hard reject (tampering detected).

Entropy: Cryptographic operations use entropy derived from distributed ASIC mining hardware (NerdQAxe fleet) mixed with OS entropy via HKDF-SHA256.

We support responsible security research. If you make a good faith effort to comply with this policy during your security research, we consider your research authorized, and we will not initiate or recommend legal action related to your research.

Good faith means:

• Acting within the scope defined above
• Not intentionally accessing data beyond what is necessary to demonstrate the vulnerability
• Not disrupting services, degrading user experience, or destroying data
• Not exfiltrating user data
• Reporting findings promptly and not publicly disclosing before coordinated disclosure
• Not demanding compensation outside the structured bounty program

Should legal action be initiated by a third party against you for activities conducted in accordance with this policy, we will make this authorization known.

We gratefully acknowledge security researchers who help keep ddot safe. Researchers who report confirmed vulnerabilities will be listed here (with permission).

No reports yet — be the first.

When decommissioning a ddot installation or transferring hardware:

# Full wipe: skills, memory, keys, config, and cache
ddot purge --confirm

# Cache only: wasm compilation artifacts
ddot purge --cache-only --confirm

The ddot purge command implements NIST SP 800-88 Rev 1 "Clear" method:

1. Pass 1: Overwrite with cryptographically random bytes (OS entropy)
2. Pass 2: Overwrite with zeros
3. Pass 3: SHA-256 verification (confirms original data is gone)
4. Certificate: Prints a timestamped decommissioning certificate

1. Stop the ddot gateway (Ctrl+C or kill)
2. Stop all channel adapters (Telegram, Discord, WhatsApp)
3. Run ddot purge --confirm (saves the decommissioning certificate)
4. Verify no ddot processes remain (ps aux | grep ddot)
5. If transferring hardware: also run diskutil secureErase on macOS or shred on Linux for the entire volume

Before purging, consider exporting audit logs and configuration for compliance records:

# Export installed skill inventory
ddot skills list > ddot-skills-export.txt

# Export security scorecard
ddot doctor > ddot-doctor-export.txt

# Export CMMC compliance matrix
ddot doctor --cmmc > ddot-cmmc-export.txt

Retain these records per your organization's document retention policy (typically 3-7 years for FCI/CUI handling evidence).

• Security reports: security@ddot.build (PGP encrypted preferred)
• General questions: hello@ddot.build
• GitHub: github.com/ddotbe/gateway