# Data Flows & Privacy Understand where code, prompts, model traffic, and telemetry move across cloud, hybrid, and airgapped Droid deployments. High-security organizations need precise answers to **what data goes where, when, and under whose control**. Factory's answer is simple: **data boundaries are determined by the models, gateways, and deployment pattern you choose**, and Droid is configurable to respect those boundaries. --- ## Overview: three main data flows When you run Droid, there are three primary ways data can move: 1. **Code and files**: local reads and writes on your filesystem and git repositories. 2. **LLM traffic**: prompts and context sent to model providers or LLM gateways. 3. **Telemetry**: OpenTelemetry metrics by default, with optional message content trace spans sent only to a customer-configured collector. How far each flow travels depends on whether you are in a **cloud-managed**, **hybrid**, or **fully airgapped** deployment. | Deployment pattern | Data boundary | | --- | --- | | Cloud-managed | Droid runs on laptops and CI, talking to Factory's cloud for orchestration and, optionally, analytics. LLM requests go to your chosen model providers or LLM gateways. | | Hybrid | Droid runs entirely inside your infra. LLM and OTEL traffic terminate in your network; Factory cloud may only see minimal metadata if you enable it. | | Fully airgapped | Droid, models, and collectors all live inside an isolated network. No runtime dependency on Factory cloud; **no traffic leaves the environment**. | ## Code and file access Droid is a filesystem-native agent, and this holds in every deployment pattern: - It reads your code, configuration, and test files **directly from the local filesystem** at the moment they're needed. - It uses LLMs to analyze existing code and generate new code, then applies patches on disk, with git as the source of truth where available. - It does **not** upload or index your codebase into a remote datastore; there is no static or "cold" copy of your repository stored in Factory cloud. - The **agent loop and runtime execute entirely on the machine** where Droid runs (developer workstation, CI runner, VM, or container), and **file reads and writes remain local** to that environment; any file contents sent off-machine are sent as part of LLM requests (prompts and context) to the model endpoints you configure, following the same LLM request pipeline described below. - Hooks run locally inside that agent loop unless you configure them to call an external service. Droid Shield's default source-backed protection scans staged git diffs before `git commit` and `git push` operations. You control which files and directories Droid can see through standard OS permissions and your repository layout. See [Agent Safety & Controls](/enterprise/llm-safety-and-agent-controls) for additional file-level protections. --- ## LLM requests and model-specific guarantees When Droid needs model output, it sends prompts and context to **your configured models and LLM gateways**. By default, Droid can target **enterprise-grade endpoints** for providers like Azure OpenAI, AWS Bedrock, Google Vertex AI, OpenAI, Anthropic, and Gemini, using contracts that support zero data retention and enterprise privacy controls. In these configurations, Factory routes traffic **directly** to the provider's official APIs; we do not proxy this traffic through third-party services or store prompts and responses in Factory cloud. If you instead configure your own endpoints - LLM gateways, self-hosted models, or generic HTTP APIs - the privacy guarantees are entirely determined by those systems and your agreements with them; Factory does not add additional protections on top. ### Model and gateway options OpenAI, Anthropic, Google, and others via their enterprise offerings. AWS Bedrock, GCP Vertex, Azure OpenAI, using your cloud accounts. Models served inside your network or airgapped environment via HTTP/gRPC gateways. Central gateways that normalize traffic, add authentication, enforce rate limits, and log usage. ### How Droid interacts with models - Org and project policies decide **which models and gateways are allowed**, and whether users can bring their own keys. - In high-security settings, orgs commonly: - Prefer the direct enterprise endpoints described above to get first-party zero-retention guarantees. - Disable ad-hoc user-supplied keys and generic internet endpoints. - Treat any LLM gateways or self-hosted models as in-scope security systems, subject to the same reviews and monitoring as other critical services. See [Enterprise Controls & Managed Settings](/enterprise/hierarchical-settings-and-org-control) for configuration details. --- ## Telemetry and analytics Telemetry is how you understand _what_ Droid is doing and _where_. Factory uses OpenTelemetry metrics for customer-owned observability and the hosted Analytics API for aggregated cloud analytics. Customers can optionally export message content as trace spans to their own collector. ### OTEL as the source of truth - Droid exports **OTLP metrics** by default to the endpoint pinned in org-managed settings (`telemetry.endpoint`) or configured per machine with `OTEL_TELEMETRY_ENDPOINT`. You can also [opt in to message content trace spans](/enterprise/telemetry/privacy#message-content-logging), which are sent only to your collector. - **Spans never reach Factory's collector**, in any configuration. Droid builds a trace pipeline only where you have configured a collector of your own, so with none set no span is recorded at all. - Typical destinations include OTEL collectors feeding **Prometheus, Datadog, New Relic, Splunk**, and similar systems. - Customer metrics export runs as a fan-out alongside Factory's own metrics export in connected deployments. In [airgapped deployments](/enterprise/telemetry#airgapped-deployments) the fan-out has one leg: your collector, with no Factory-bound export built at all. Airgapped deployments do not use Factory-hosted analytics. - Organizations that cannot collect per-individual analytics can pin [`telemetry.granularity: aggregate`](/enterprise/telemetry/privacy#data-granularity), which strips user identifiers from every datapoint at the source on both legs. ### Optional Factory cloud analytics In cloud-managed deployments, you can opt into Factory's own analytics dashboards, which may: - Aggregate anonymized usage metrics to show adoption, model usage, and cost trends. - Surface per-org and per-team insights for platform and leadership teams. These analytics are optional; org administrators decide whether to enable them. For telemetry setup and the hosted Analytics API, see [Telemetry & Analytics](/enterprise/telemetry); for the exported metric names and schema, see the [Telemetry Data Reference](/enterprise/telemetry/data-reference); for how this data maps to audit and compliance workflows, see [Compliance & Audit](/enterprise/compliance-audit-and-monitoring). ## Data retention and residency ### Factory-hosted components In cloud-managed mode, Factory may store limited operational logs and metrics for: - Authentication and administrative actions (for example, org configuration changes). - Service health and debugging. Retention and residency for these logs are documented in the Trust Center and can be tuned per customer engagement. ### Customer-hosted components For hybrid and airgapped deployments: Handled entirely by your providers and gateways; Factory does not see it. Stored in your observability stack; retention is governed by your own policies. Never leave your environment unless you explicitly send them to external services via hooks or gateways. In fully airgapped environments, Factory never receives any runtime data; you are responsible for all retention and residency decisions. See [Airgapped Deployment](/enterprise/airgapped-deployment) for the runtime behavior and network contract. --- ## Governance controls in practice To make these guarantees enforceable rather than aspirational, Factory exposes **governance levers** at the org and project levels: - Model and gateway allow/deny lists. - Policies for whether user-supplied BYOK keys are allowed. - Global and project-specific hooks for DLP, redaction, and approval workflows. - OTEL endpoint configuration (including requiring on-prem collectors). - Maximum autonomy level and other safety controls, especially in less-trusted environments. These levers are implemented through [Enterprise Controls & Managed Settings](/enterprise/hierarchical-settings-and-org-control). Proxies, custom CAs, and regional data boundaries. Export OTEL metrics and optional message content traces.