Security & Trust Center

Data Handling

What BitDrip sees — and what it doesn't

BitDrip evaluates supported configured traffic in the customer-controlled path. Validated audit configurations can retain bounded metadata or hashes instead of full matched content; confirm logs, diagnostics, support flows, and retention for the deployed version.

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.

Data-minimizing audit model

The actual text of AI prompts or responses On validated supported paths, evaluation handles content in memory and the standard policy-event schema can omit full prompt and response text. Confirm other logs, diagnostics, support flows, and deployed configuration.
User-readable PII or PHI content Supported detections can produce a rule match and hash rather than a content copy in the standard audit record. Detector and schema behavior require deployed-version validation.
Cleartext secrets or credentials Supported credential patterns can be represented by a rule match or hash instead of the matched value in validated standard audit records.
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

The supported AI-content evaluation path runs in customer-controlled components. The separate Anchor-operated portal handles the bounded commercial data categories described in the privacy notice.

1

User sends a request to an AI provider

A proxy-aware browser, configured CLI tool, or API call targets ChatGPT, Claude, Gemini, or another configured provider. The OS proxy or tool-specific 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 customer-controlled policy engine. Its enabled supported detectors evaluate the request body; actual coverage and performance depend on rules, content, deployment, and application path.

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

Where signing is enabled and validated, the audit record is finalised with a cryptographic signature and written to the customer-controlled audit database. Validated data-minimizing configurations record bounded metadata rather than prompt or response content; confirm the deployed schema and diagnostic paths.

The AI-content path shown above uses customer-controlled components. The separate portal receives authentication and license data, deployment fingerprint, optional hostname, running version, and health status for automated validation. Prompt or conversation content, policy configurations, and workstation end-user identity are excluded from that documented telemetry path. See the Privacy Policy for the current categories and other support or account flows.

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 supported installer generates a CA keypair (RSA-2048 or ECDSA P-256) on the machine. The application is designed not to transmit the private key to the policy engine or hosted portal. Validate endpoint, keystore, backup, and diagnostic controls for the deployed environment.
2 The CA private key is designed for local custody: The supported workflow stores the private key in the system keychain or a protected host file, depending on platform, and does not intentionally upload it to BitDrip services. Endpoint privileges, backups, diagnostics, and customer key management can affect actual custody and must be validated.
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: The supported uninstaller attempts to remove managed CA certificate and key entries. Administrators must verify the physical OS and browser trust stores, loaded user stores, keystore entries, files, and backups after uninstall, and use the documented manual removal path for anything that remains.

What this protects

Intercepted traffic is your traffic

Per-deployment CA generation and local key custody reduce cross-deployment exposure. They do not eliminate risk from privileged endpoint access, copied key material, trust-store changes, backups, or other administrative compromise. Validate the installed trust scope and key custody.

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 supports tamper-evident verification where the documented hash chain is enabled and validated. Changes to covered chained entries can be detected when verification runs; this is not an immutability guarantee.

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

Chained events include the SHA-256 hash of the previous event. Deleting or modifying an event breaks subsequent verification, so the change is detectable when the documented chain verification runs.

🖊

Per-event signatures

Where the release and deployment evidence confirms per-event signing is enabled, signed events can be checked with the corresponding verification key. Validate the actual deployed audit schema and verifier before relying on this control.

🕐

Retention policy

Audit retention is controlled by the customer's self-hosted storage and compliance policy. Enterprise SIEM export can support customer-managed long-term preservation, but BitDrip does not promise tier-specific retention periods.

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

Data-minimizing audit design: Validated audit configurations can store bounded metadata or hashes rather than full matched content. Confirm other logs, diagnostics, support flows, and deployed retention when assessing exposure.
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.
Release verification: Authenticated release evidence and SHA-256 checksums support detection of changed installer bytes when administrators perform the documented verification. Checksums alone do not prevent installation or establish publisher identity.

Scenario 2

Malicious insider with admin access to BitDrip

Org-scoped authorization: Covered organization-scoped routes enforce and test tenant authorization. This is not a universal claim for every route or query; validate the current API security inventory and close documented gaps before relying on shared-infrastructure isolation.
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.
Administrative evidence: Supported administrative events can include the actor and timestamp in the audit trail. Confirm event coverage, signing state, and chain verification against the deployed version before relying on this evidence.
Customer-controlled live path: Access to live evaluated content depends on the customer's host, process, access, logging, and diagnostic controls. Assess the deployed environment rather than assuming universal non-storage.

Scenario 3

BitDrip itself exfiltrates customer data

Offline deployment option: Supported customer-controlled components can use offline license files in a deliberately configured isolated deployment. Validate update, provider, support, diagnostic, and other integration requirements before describing a deployment as air-gapped.
Documented portal check-in: Automated validation can send authentication and license data, deployment fingerprint, reported hostname, running version, and health status to the Anchor-operated portal. Prompt or conversation content, policy configurations, and workstation end-user identity are excluded from that documented telemetry path; assess other configured integrations and support flows separately. See 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.
Runtime routing scope is not a certificate constraint: The runtime allowlist and proxy policy limit normal BitDrip interception to configured supported destinations, but the CA has no documented X.509 hostname constraint. Compromise of its trusted private key could enable arbitrary-host certificates. Endpoint and key protection are therefore critical; incident response must rotate the key and verify removal of the old CA from relevant physical trust stores, user stores, browsers, files, and backups.
CA rotation workflow: If a CA key is compromised, bitdrip ca rotate attempts to generate and install a new keypair and remove managed old trust entries. Administrators must verify every relevant physical OS and browser trust store after rotation; an old CA can remain trusted wherever cleanup did not complete.
CA lifecycle evidence: Supported CA generation, rotation, and removal events received by the policy engine can be recorded with available timestamps and actor fields. Confirm event coverage and deployed audit integrity before relying on the evidence. Professional and Enterprise tiers include a CA audit log view.

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.