Compliance & Audit

Map Droid activity to audit, compliance, and monitoring workflows with Trust Center resources, audit events, and telemetry.

Security and compliance teams need clear answers to who did what, when, where, and with which data. Droid fits into that posture through Factory's Trust Center, Factory-side audit events for cloud-managed features, customer-owned telemetry exports, and workflow logs in systems such as GitHub Actions.

Use this page for audit and compliance posture. For telemetry setup, exported metric names, and the hosted Analytics API, see Telemetry & Analytics.

Certifications and Trust Center

Factory maintains an enterprise-grade security and compliance program, including:

  • SOC 2 Type II
  • ISO 27001
  • ISO 42001

Our Trust Center provides up-to-date reports, security architecture documentation, and sub-processor lists. Use it as the primary reference for security and compliance reviews.

Audit trails and events

There are two complementary sources of audit information:

  1. 1
    Factory-side audit logs (for cloud-managed features).
  2. 2
    Customer-side OTEL telemetry emitted by Droid.

Factory-side audit logs (cloud-managed)

When you use Factory's hosted services, the control plane records key events such as:

  • Authentication events and SSO/SCIM changes.
  • Org and project configuration updates.
  • Policy changes (model allow/deny lists, autonomy limits, Droid Shield settings, hooks configuration).
  • Administrative actions in the web UI.

Use the Trust Center for current compliance materials. For audit-log export or security-system integrations, coordinate the supported path during your enterprise engagement.

Customer-side OTEL telemetry

Droid exports OTEL metrics by default as fine-grained activity data inside your own systems. You can also opt in to customer-only message content trace spans for session auditing. Exported metrics include:

  • Tool and MCP tool invocations, including execution duration.
  • Commands blocked by policy.
  • Code modification activity (files read and modified, lines modified).
  • Git activity (commits and pull requests created) and successful logins.

Every data point carries user.id, organization.id, and session.id attributes, so you control how long these signals are retained and how they are correlated with other systems such as CI/CD pipelines, SIEMs, and case management tools. Because the metrics land in collectors you operate, you can enrich or redact attributes against your own policies before forwarding them, keeping ownership of telemetry in your hands even when you use Factory's cloud-managed features.

For aggregated usage, token, and cost data, use Factory's hosted Analytics API, which is backed by Factory's internal tracing.

Note

The full exported-metric catalog, OTLP collector configuration, and provider examples are owned by Telemetry & Analytics. This page covers only how that data supports audit and compliance workflows.

Securing the GitHub Action and CI

The Factory Droid GitHub Action (Factory-AI/droid-action) runs entirely inside GitHub Actions on runners you control. It does not provision external compute, code is checked out transiently for the workflow run and discarded afterward, and authentication uses your Factory API key subject to your org's model allowlists, rate limits, and policies.

Authentication and authorization

  • Factory API key. Store FACTORY_API_KEY as a GitHub Actions secret; never commit it. The key authenticates Droid Exec sessions and is subject to your org policies.
  • GitHub App tokens. When using the Factory Droid GitHub App, the app requests a short-lived installation token scoped to the repository, automatically revoked after the workflow completes.
  • User permission verification. Before executing any @droid command, the action verifies the triggering user has write access to the repository. Bots are rejected unless explicitly allowed via the allowed_bots input.

Permission scoping

The generated workflow requests only the GitHub permissions the action needs:

YAML
permissions:
  contents: write # Read code, write for fixes
  pull-requests: write # Comment on and update PRs
  issues: write # Comment on issues
  id-token: write # OIDC token for secure auth
  actions: read # Read workflow run metadata

You can further restrict permissions in your workflow file based on your security requirements.

Wired security inputs

InputPurpose
allowed_botsComma-separated list of bot usernames allowed to trigger, or * for all. Default: none.
automatic_security_reviewRun security review automatically on non-draft PRs without requiring a manual @droid mention.
security_modelOverride the model used for security review candidate generation and full-repository scans.

For the full security review workflow, modes, and methodology, see Security Review.

Audit and monitoring for CI

  • Workflow logs. All Droid activity is recorded in GitHub Actions workflow runs, with timestamps, step status, and links to comments or changes made.
  • Factory telemetry. If your org exports OTEL metrics, Droid Exec sessions from GitHub Actions are included in your metrics, tagged with session.id and tool/activity attributes.

Deployment recommendations

For security-conscious organizations

  1. 1
    Use repository or org secrets for FACTORY_API_KEY.
  2. 2
    Review workflow permissions so the workflow requests only what it needs.
  3. 3
    Restrict bot access - keep allowed_bots empty unless you have a specific need.
  4. 4
    Enable branch protection to require PR reviews before merging Droid-assisted changes.
  5. 5
    Monitor workflow runs in your GitHub Actions logs regularly.

For regulated environments

  • Self-hosted runners in your controlled environment.
  • Model allowlists via Factory org policies to restrict which models Droid can use.
  • Integrate with SIEM by exporting GitHub Actions logs and Factory telemetry to your security monitoring tools.

Regulatory and industry use cases

Factory is designed to support organizations operating under strict regulatory regimes. While implementation details differ, common patterns include:

Use caseCommon pattern
Financial servicesUse hybrid or airgapped deployments for systems subject to strict data residency and record-keeping requirements. Route LLM traffic through gateways that implement your bank's data policies, and use OTEL telemetry plus hooks so Droid activity is visible in your SIEM.
Healthcare and PHIDeploy Droid in environments that never expose protected health information to external LLMs. Use model allowlists that include only providers and gateways that meet your PHI handling requirements, and use approved gateways, DLP hooks, and Droid Shield to reduce exposure.
National security and defenseRely on fully airgapped deployments with on-prem models and collectors. Treat Droid as an internal tool whose artifacts and logs never leave your network, and integrate OTEL plus hooks with mission-specific monitoring and incident response tooling.

Deployment and configuration for compliance teams

To integrate Droid into your compliance and monitoring stack:

  1. 1
    Decide on deployment pattern: cloud-managed, hybrid, or fully airgapped.
  2. 2
    Define model and gateway policies: which providers and gateways are allowed, and where.
  3. 3
    Configure OTEL collectors and destinations: ensure all Droid telemetry flows into your SIEM and observability tools.
  4. 4
    Set up hooks and Droid Shield: enforce DLP, approval workflows, and environment-specific controls.
  5. 5
    Document policies and mappings: connect Droid controls to your internal control framework and regulatory obligations.

Most of this configuration is expressed through Enterprise Controls & Managed Settings.