AgentLoom does not currently hold SOC 2, ISO 27001, HIPAA, or other third-party compliance certifications. We are deliberately stating this in the first section of this page rather than burying it.

The controls described below are designed to support customer evidence collection, vendor review, internal audit, and incident response — they are not a substitute for an external attestation. If your procurement process requires a SOC 2 Type II report or equivalent, AgentLoom is unlikely to meet that bar today. We expect to engage with a recognized auditor as our enterprise customer base grows; we will update this section with timeline detail once a scoping engagement is signed rather than committing to dates we cannot hold.

Current security documentation, DPA review, and questionnaire support are available on request. Formal third-party assessment summaries will be shared with enterprise customers once they exist; we do not present placeholders as completed artifacts.

AgentLoom's hosted control plane runs on Google Cloud Platform. Customer-facing services, agent orchestration, run state, and operational logs are hosted in US-based GCP regions by default. Enterprise customers with specific data-residency requirements can negotiate region constraints in their DPA.

Production network posture follows least-exposure conventions:

The data-flows section below enumerates the direct subprocessors that may see customer code or run data. We do not control the upstream subprocessors of every third party we depend on; those are governed by the third party's own terms and enterprise agreements.

Each agent run executes in an isolated, ephemeral workspace provisioned for that run. Source code is fetched from your GitHub installation at the start of the run via a scoped installation token, written to the workspace, and the workspace is discarded after the run completes, is cancelled, or is re-dispatched.

Workspaces are not shared between runs and are not reused across tenants. Compute, filesystem, and process namespace are isolated per run. Execution environments are configured to use only the external services required for the run: the cloned repository, configured connector endpoints, and the model providers backing that run. AgentLoom does not maintain a long-term mirror of customer repositories; we re-fetch from GitHub each run rather than serving from a persisted clone.

Run artifacts that are persisted past workspace teardown — worker logs, generated patches, checkpoint files, implementation summaries, and related execution artifacts — are stored in tenant-scoped artifact storage and registered in the control plane. Retention follows the active environment policy (see What AgentLoom reads, keeps, discards).

To deliver agent runs, AgentLoom transmits customer code, ticket context, and run metadata to a small set of subprocessors. The list below identifies the direct third parties used by the current implementation and whether they may see customer code or run data.

AgentLoom's data flow is scoped to active execution and operational records. The breakdown below is written in the language we use internally so reviewers can map it directly to questionnaire categories.

Customer data is processed in Google Cloud regions per the active environment policy (US by default). Enterprise customers with specific data-residency requirements can negotiate region constraints in their DPA.

AgentLoom logs are designed to support customer evidence collection — for security questionnaires, internal audit walks, regulator requests, and incident review. The trail is queryable from the dashboard; exports are available on request for Enterprise reviews.

Each entry is structured around the run it belongs to, the originating issue, and the resulting PR, so reviewers can trace a single piece of work end-to-end without stitching across systems. Logged events include:

Log retention follows the active environment policy. Enterprise customers can negotiate retention terms in their DPA. AgentLoom does not provide a customer-facing affordance to alter individual audit entries; deletion and retention exceptions are handled as scoped administrative requests.

Workspace owners can request deletion of an AgentLoom workspace through support or their Enterprise contact. Deletion removes the workspace record, member associations, run logs, generated artifacts, connector credentials, and audit history associated with the workspace, subject to legal and billing retention obligations.

Live records are deleted or irreversibly disabled as part of the deletion workflow, and backups containing deleted records age out under the active environment backup policy. Stripe billing records required by tax and accounting law are retained per Stripe's retention policy and our financial obligations; these records contain account and invoice metadata, not run content.

Enterprise customers can request written deletion attestation or scoped deletion of specific runs or repositories under their DPA. Email security@agent-loom.com with your workspace identifier and the scope of the request.

If you believe you have found a security vulnerability in AgentLoom, please report it to the address below rather than disclosing publicly. We treat coordinated disclosure as the default and will work with you on a remediation timeline before any public write-up.

We commit to acknowledging vulnerability reports within 5 business days and sharing a remediation plan as soon as the issue is triaged. Critical incidents affecting customer data are communicated to affected workspaces by email; we do not currently operate a public status page, and we do not list this as a commitment we cannot hold.

AgentLoom does not currently run a paid bug bounty program. We will credit researchers in a security advisory on request and are happy to coordinate disclosure timing.