Data Flows & Privacy

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. 1
   Code and files: local reads and writes on your filesystem and git repositories.
2. 2
   LLM traffic: prompts and context sent to model providers or LLM gateways.
3. 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.

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 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

Cloud model providers

OpenAI, Anthropic, Google, and others via their enterprise offerings.

Cloud AI platforms

AWS Bedrock, GCP Vertex, Azure OpenAI, using your cloud accounts.

On-prem / self-hosted models

Models served inside your network or airgapped environment via HTTP/gRPC gateways.

LLM 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 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 you configure with OTEL_TELEMETRY_ENDPOINT. You can also opt in to message content trace spans, which are sent only to your collector and never to Factory's collector.
• 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. Fully airgapped deployments do not use Factory-hosted analytics.

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 the exported metric names, schema, and hosted Analytics API, see Telemetry & Analytics; for how this data maps to audit and compliance workflows, see Compliance & Audit.

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:

LLM traffic

Handled entirely by your providers and gateways; Factory does not see it.

Telemetry

Stored in your observability stack; retention is governed by your own policies.

Code, configuration, and secrets

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.

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.