# Architecture, security model, and known limits This document explains the technical claims we can support, the boundaries of our testing, and the conditions that can still cause detection or data exposure. It is not a certification or a promise that every site will accept every session. ## 1. System architecture and trust boundary Owl is a self-hosted Chromium and CEF browser engine. Browser contexts, profiles, page content, cookies, screenshots, proxy credentials, and automation output remain in the environment where you deploy the browser. The REST, WebSocket, and MCP interfaces expose the same local automation engine. Self-hosting moves the main security boundary to your host, container runtime, network, and chosen model or proxy providers. Olib does not receive automation traffic simply because Owl is running. License activation and validation are separate control-plane requests and include the identifiers described in our privacy policy. ## 2. How source-level fingerprint controls work Conventional stealth plugins often replace JavaScript properties after a page starts. That can leave observable property descriptors, prototype changes, injected functions, or inconsistent values across frames and workers. Owl changes selected fingerprint values in the Chromium and Blink implementation, before those values reach page JavaScript. This approach reduces one class of artifact. It does not create a cryptographic proof that a fingerprint came from physical hardware. A detector can still correlate TLS behavior, IP reputation, request timing, interaction patterns, account history, graphics output, fonts, codecs, or a new browser inconsistency. "Source-level" describes where a value is produced, not a guarantee of acceptance. ## 3. Validation and reproducibility We test releases with a public harness against CreepJS fingerprint signals and the published comparison profiles for Playwright and Puppeteer. For agent efficiency, we use six fixed tasks, a pinned local model, versioned clients, repeated runs, explicit expected answers, and machine-readable grading. We record correct, wrong, and abandoned runs separately. * Test harness: https://github.com/Olib-AI/owl-detection-report * Agent raw JSON: https://owlbrowser.net/detection-reports/agentic.json * Detection raw JSON: https://owlbrowser.net/detection-reports/report.json * Performance raw JSON: https://owlbrowser.net/detection-reports/benchmark.json These are Olib-run tests, not an independent laboratory audit. The public code and data make an independent rerun possible, but publication by us must not be mistaken for third-party validation. ## 4. Known failure modes No anti-detection browser is undetectable across all sites and versions. * Poor proxy reputation or a location, timezone, language, and IP mismatch can trigger review. * Unrealistic click timing, navigation patterns, or high request volume can reveal automation even when browser properties are consistent. * Authenticated sites can use account history and server-side signals that the browser cannot change. * New Chromium releases and detector updates can introduce signals before Owl adds or validates a matching control. * Fonts, GPU behavior, codecs, media devices, and graphics hashes can differ from the selected profile on some hosts. * A passed fingerprint scanner does not predict whether another site will accept a session. ## 5. CAPTCHA behavior and timing CAPTCHA solving uses a vision model and is not an instant or guaranteed operation. In our experience, a solve can take about 5 to 300 seconds depending on challenge complexity, model hardware, network latency, retries, and whether the provider presents another challenge. Some challenges will fail or require human review. Signed-agent allowlisting can avoid a challenge only on sites that explicitly recognize and permit that identity. ## 6. Security controls and SOC 2 status Olib follows controls mapped to the SOC 2 Trust Services Criteria and maintains an evidence package. Olib and Owl Browser are not SOC 2 certified and no SOC 2 attestation report is currently available. Product controls include encrypted credential storage, protected handling of sensitive memory where the operating system supports it, TLS for network interfaces, rate limiting, integrity-protected security logs, non-root container execution, capability dropping, and read-only container deployment options. These controls can support a customer's compliance program, but deploying Owl on a compliant cloud does not make the customer's workload or Olib SOC 2 compliant. Enterprise customers can request the control mapping and available evidence for vendor review at enterprise@olib.ai. ## 7. Privacy, telemetry, and retention "No product telemetry" means Owl does not send browsing history, page content, cookies, screenshots, automation output, or feature analytics to Olib by default. It does not mean the website, license service, a configured proxy, or an external model provider collects nothing. License identifiers, activation timestamps, website analytics, retention periods, and deletion rights are listed in the privacy policy. Operators remain responsible for retention, access controls, lawful processing, data-subject requests, and the terms of sites they automate. Self-hosting gives the operator control of the data plane. It does not transfer or remove those legal obligations.