Security & Trust Center

Data Handling

What BitDrip sees — and what it doesn't

BitDrip is a policy-enforcement layer, not a data collector. It evaluates traffic in memory and records only the metadata required to produce an audit trail. The content itself is never persisted.

What BitDrip processes and records

Request metadata Provider URL, timestamp, HTTP method, and the device certificate identity of the requesting user.
Policy evaluation result Whether the request was allowed or blocked, and the final disposition (block / warn / log).
Violation category and rule name Which detection rule triggered (e.g., PCI_CARD_NUMBER, GDPR_EMAIL). Human-readable, no content.
Content hash (SHA-256) for blocked requests A one-way fingerprint of the content that triggered the rule. Used for deduplication — cannot be reversed to recover the original text.

What BitDrip never stores

The actual text of AI prompts or responses Content is read in memory for policy evaluation and immediately discarded. Nothing is written to disk or a database.
User-readable PII or PHI content Names, addresses, medical information, financial details — if detected, they trigger a hash and a rule match, not a copy.
Cleartext secrets or credentials API keys, passwords, and tokens are detected by pattern and hashed. The credential value is never written to the audit log.
AI provider response content Responses are scanned in memory for jailbreak signals and hallucinated PII. The response text itself is not retained after evaluation.

Architecture

How a request flows through BitDrip

Every step runs on your infrastructure. BitDrip's servers are never in the path.

1

User sends a request to an AI provider

A browser tab, CLI tool, or API call targets ChatGPT, Claude, Gemini, or another configured provider. The OS proxy setting routes traffic through the local BitDrip proxy daemon.

2

Proxy daemon intercepts the HTTPS connection

BitDrip terminates the TLS connection using the locally generated CA certificate, decrypts the request body in memory, and presents an authenticated forwarding connection to the provider.

3

Policy engine evaluates the request

The decrypted content is passed to the policy engine — running locally on your machine or policy server. All 29 detection rules are evaluated against the request body. Evaluation time is typically <10ms. No content leaves your environment at this stage.

4a — Violation detected

The request is blocked before it reaches the AI provider. An audit event is created containing only: timestamp, rule name, violation category, content hash (SHA-256), user identity, and policy decision. The prompt text is discarded.

4b — No violation

The request is forwarded to the AI provider over a fresh TLS connection. The provider receives the original request exactly as the user intended, with no modification.

5

AI provider response passes back through the proxy

The response is decrypted and evaluated by the response-scanning rules. BitDrip checks for hallucinated PII and jailbreak success signals. If clean, the response is re-encrypted and delivered to the user. Response content is not stored.

6

Audit entry is closed and signed

The audit record for this request is finalised with a cryptographic signature and written to the local audit database. The record contains metadata only — no prompt or response content.

None of this involves BitDrip's servers. The proxy daemon, policy engine, and audit database all run on your infrastructure. The only outbound connection to BitDrip's infrastructure is a periodic license validation heartbeat, which transmits a deployment fingerprint hash and your license JWT — no content, no user activity, no audit data. See the Privacy Policy for full details on the heartbeat payload.

Certificate Authority

How the CA certificate works

BitDrip uses HTTPS interception to read encrypted AI traffic. This section explains the mechanism honestly, including what it means for your TLS trust model.

Plain language: To inspect HTTPS traffic, BitDrip acts as a local man-in-the-middle for connections to AI providers. This is the same mechanism used by enterprise DLP, next-gen firewalls, and corporate proxy products. It requires installing a CA certificate into your OS trust store. We explain exactly how this works below.

1 Local CA generation during installation: The installer generates a unique CA keypair (RSA-2048 or ECDSA P-256) on your machine. This keypair is created locally and never transmitted anywhere. Each BitDrip deployment has a distinct CA — there is no shared Anchor Cyber Security CA certificate distributed to customers.
2 The CA private key stays local: The private key is stored in the system keychain or an encrypted file on the host filesystem, depending on platform. It does not leave the device or server where BitDrip is installed. Backup and key management are your responsibility.
3 OS trust store installation: The CA certificate (public key only) is added to the OS certificate trust store. This tells the operating system to trust TLS certificates signed by the local BitDrip CA. On macOS this requires an administrator password; on Windows it writes to the Machine certificate store; on Linux it writes to the system CA bundle.
4 Dynamic leaf certificate generation: For each proxied connection, BitDrip generates a short-lived leaf certificate for the target hostname (e.g., api.openai.com), signs it with the local CA key, and presents it to the browser. The browser sees a valid certificate because it trusts the CA. This is how BitDrip can read the encrypted request content.
5 Scope is limited to AI providers: By default, BitDrip only intercepts traffic to the configured AI provider domains. Other HTTPS traffic is tunnelled without interception using standard CONNECT proxying. You can inspect and customise the allowlist in the configuration file.
6 Removal: Uninstalling BitDrip removes the CA certificate from the OS trust store automatically. If you remove the software manually, run bitdrip ca remove first, or remove the certificate from the trust store by hand. The CA key material is deleted from disk during uninstall.

What this protects

Intercepted traffic is your traffic

Because the CA is generated locally and unique per deployment, no third party — including Anchor Cyber Security — can use it to intercept your connections. The CA is only trusted by machines where BitDrip is installed.

What you should know

Any software with CA access on that machine can inspect traffic

Installing a root CA in the OS trust store is a significant trust decision. Any process running with sufficient privileges on the same machine can potentially present certificates signed by that CA.

This is an inherent property of OS-level certificate trust, not a BitDrip-specific risk. Standard enterprise DLP products carry the same consideration.

Audit Integrity

Audit log integrity model

The audit log is designed to be tamper-evident. If any entry is modified or deleted after the fact, the chain breaks and the tampering is detectable.

audit_event — stored fields (JSON)

{
  "id":              "evt_01j...",      // ULID, monotonic
  "timestamp":       "2026-06-06T14:23:11.042Z",
  "user_hash":      "sha256:9f86d08...",  // hash of device cert identity — not the name
  "provider":       "api.openai.com",
  "rule_id":        "PCI_CARD_NUMBER",
  "category":       "pci",
  "decision":       "blocked",
  "content_hash":   "sha256:2ed98e3...",  // one-way; content not stored
  "prev_event_hash": "sha256:7b14c2f...",  // hash of previous event (chain link)
  "signature":      "ed25519:4a8f..."      // over id + timestamp + content_hash + prev_event_hash
}

🔗

Hash chain

Each event includes the SHA-256 hash of the previous event. Deleting or modifying any event in the middle of the log invalidates every subsequent hash, making the tampering immediately visible when the chain is verified.

🖊

Per-event signatures

Each event is individually signed with an ed25519 key pair. The verification key is exported at installation time so auditors can verify log integrity independently, without access to the signing key or to BitDrip's systems.

🕐

Retention policy

Default retention is 90 days on the Community tier. Starter and Professional tiers support configurable retention up to 3 years. Enterprise deployments can write audit events directly to an immutable SIEM (Splunk, Elastic, Azure Sentinel) for long-term preservation.

Threat Model

How BitDrip handles adversarial scenarios

Four scenarios security architects regularly ask about — and the specific controls that address each one.

Scenario 1

Attacker compromises the BitDrip installation

No stored content to exfiltrate: AI prompts and responses are never written to disk. An attacker who compromises the host gets audit metadata — timestamps, rule names, and content hashes — but not the underlying conversations.
CA key is local: The CA private key lives on the host. A compromised host could expose past and future proxied traffic, but only for connections routed through that specific BitDrip instance. Scope is bounded to one deployment.
License signing uses ed25519: License JWTs cannot be forged without the private key held by Anchor Cyber Security. A compromised installation cannot issue valid licenses.
Regular updates: BitDrip ships with an automatic update checker. Security patches are released promptly. SHA-256 installer checksums prevent tampered packages from being installed silently.

Scenario 2

Malicious insider with admin access to BitDrip

Org-scoped data isolation: Each organisation's data is isolated at the database query level. Admin users cannot query data from other organisations, even on a shared infrastructure deployment.
RBAC with least privilege: Admin, policy manager, and viewer roles are distinct. Policy changes require the policy-manager role; admin actions are visible in the audit trail.
Admin actions are logged: Every policy change, user enrollment, and configuration update generates a signed audit event — including the admin identity and timestamp. These entries are subject to the same tamper-evident chain as regular events.
No standing access to content: Because prompt and response content is never stored, there is nothing for an insider to retrieve after the fact. Access to the live proxy stream requires direct access to the running process, which is an OS-level control.

Scenario 3

BitDrip itself exfiltrates customer data

Air-gap deployment supported: BitDrip can run with no internet access at all. License validation can be done manually (offline license files) for deployments that require complete network isolation.
Minimal outbound connections: The only outbound connection to Anchor Cyber Security infrastructure is the license heartbeat. No content, no audit data, no user activity is included. The exact payload is documented in the Privacy Policy.
AI traffic goes directly to providers: BitDrip forwards allowed requests to AI providers directly from your network. There is no relay or inspection hop through Anchor Cyber Security infrastructure.
Open for security review: We welcome security teams to inspect the binary, capture network traffic from a deployed instance, and validate the outbound connection behaviour. Contact security@anchorcybersecurity.com to arrange access.

Scenario 4

Certificate trust abuse after deployment

CA is unique per deployment: The CA certificate generated during installation is not shared across customers or deployments. Compromising one customer's CA does not affect any other deployment.
Scope limited to configured providers: The CA is only used to sign leaf certificates for the AI provider domains in your allowlist. It does not grant the ability to intercept arbitrary HTTPS traffic without a reconfiguration that requires admin credentials.
CA can be revoked and regenerated: If a CA key is compromised, bitdrip ca rotate generates a new keypair, removes the old CA from the trust store, and installs the new one. The old CA ceases to be trusted immediately.
CA lifecycle is audited: All CA generation, rotation, and removal events are written to the audit log with timestamps and admin identity. Professional and Enterprise tiers include a dedicated CA audit log tab in the dashboard.

Responsible Disclosure

Security disclosure policy

Report a vulnerability

If you discover a security issue in BitDrip — the software, the portal, the documentation site, or any component we operate — please contact us at security@anchorcybersecurity.com.

We commit to responding within 48 hours with an acknowledgement and an initial assessment. For confirmed vulnerabilities, we will provide a remediation timeline within 7 days.

We credit researchers who follow coordinated disclosure — please allow us 90 days to patch before public disclosure. We will name you in the release notes unless you prefer to remain anonymous. We do not currently offer a monetary bug bounty, though we do offer recognition and reference letters for material findings.

For encrypted reports, our PGP key is available at docs.bitdrip.app/security/pgp.