Compounding knowledge, contained per tenant.

Tenant isolation

The fact cache is partitioned per tenant by construction. Cache reads and writes carry the tenant id from the auth envelope; the storage layer rejects cross-tenant access at the wire, not at application level. Two tenants who retrieve the same fact pay extraction cost twice on first hit; we do not deduplicate facts across tenants.

Per-tenant policy namespaces. CEL programs (when used) cannot reference state outside their tenant's namespace. Audit logs are written into per-tenant indices.

Fact-cache custody

The cache is encrypted at rest with a per-tenant data-encryption key, wrapped by a customer-controlled KMS-CMK on the Enterprise tier. On the managed tier, the wrapping key is held by Good Ventures Lab Inc.; we never have plaintext access to the cache without unwrapping through KMS, and KMS access is audited.

Decay-driven deletion. When a fact's decay schedule expires, the cache row is shredded; expired rows are not retained for analytics.

Right to delete. Customers can purge their cache on request. Cache export is available before purge so the tenant can take its accumulated knowledge with it.

Firewall

Every fact candidate is firewalled before it reaches the cache, rerank, or the calling agent. Quarantine, surface-with-warning, drop. The firewall is what makes compounding safe; without it, a single poisoned page can corrupt a tenant's cache for all future queries. See Firewall.

Key custody

API keys are stored hashed; we cannot recover a key once issued. Rotation is one click in the dashboard and is non-disruptive (old key remains valid for a configurable grace window). Keys carry tenant id and depth-tier scope; a depth-1-only key cannot run a depth-3 research request.

Backend model-provider keys are not handled by DeepTap; we do not proxy to OpenAI/Anthropic on the customer's behalf. The pipeline calls the providers we contract with, and the customer's traffic is metered against DeepTap credits, not against external provider keys.

Network surface

The managed plane accepts inbound traffic on the public API endpoint only, terminated with TLS 1.3, minimum cipher TLS_AES_128_GCM_SHA256. mTLS is available for service-to-service deployments on the Enterprise tier. Outbound traffic from the engine is restricted to contracted backend providers and configured search endpoints; there is no telemetry phone-home.

Audit and reporting

Every query produces a signed receipt. Receipts are TrueCom-compatible, Merkle-chained, and verifiable offline given the signing public key. The receipts log is a complete record of which agent retrieved what, with which firewall verdict, and which cache outcome.

SOC 2 Type I is in progress; report expected before GA. Penetration tests run twice per year by an external firm. Customers under NDA can request the most recent summary letter.

Vulnerability disclosure

Security reports go to [email protected]. Critical reports get acknowledged within one business day and triaged within three. In-scope: cross-tenant cache access, firewall bypass, receipt forgery, fact-cache exfiltration, multi-tenancy boundary violations. Out-of-scope: denial-of-service against the public marketing site; social engineering of staff; physical attacks. Eligible reports receive a bounty under our coordinated-disclosure program.