Coroid carries out autonomous engineering work on your code. This page explains where that work runs, what it can access, how credentials and data are protected, and what records it leaves. It describes the controls currently in place. Planned controls are labelled as planned.
Where agent work runs
Every task runs in its own isolated cloud workspace. The workspace is created for that task and removed once it is finished. Agents read and write only to the repository checked out into it.
There are three zones:
| Zone | Owner | What it holds |
|---|---|---|
| Agent workspace | Coroid | The checkout, build and test tooling for one task. Created per task, removed after it is finished. |
| Control plane | Coroid | Scheduling, specifications, evidence and the decision trail. Holds project-scoped credentials through encrypted configuration. |
| Your network and production | You | Not accessible from an agent workspace. |
Work leaves the workspace in one form: a pull request. Your team decides whether to merge it, and your own deployment path takes it from there. Coroid needs no IDE extension, no local agent and no access to your private network.
Identity and access
Authentication is centralised in the gateway. It supports:
- JWT-based user sessions for portal access
- Service-to-service tokens with managed rotation
- API keys for external integrations
- Guards for user, service and mixed-access endpoints
Repository access is scoped to the project. Credentials for one project cannot be used by another project, and Coroid does not require organisation-wide credentials to work on a single repository. See Connect your code.
Organisation owners and admins manage members, sessions and the security event feed under Settings → Security and access. SSO/SAML with SCIM provisioning is part of Enterprise, which is in private preview.
Data protection
- Data is encrypted in transit and at rest.
- Sensitive configuration values, such as Provider keys and repository tokens, are stored encrypted.
- The public cloud service offers an EU hosting profile for teams with GDPR or data-residency requirements. The EU Only AI profile keeps model inference with EU-hosted providers. See AI profiles.
- You control how long execution history, transcripts and artefacts are kept. See Data retention.
The decision trail
Every autonomous change is explained in terms that reviewers and security teams already use:
- The specification, agent activity, review and approval decision remain linked to the task.
- The execution trail records each agent run, including failed attempts and why they failed.
- Pull-request history shows the final evidence before code is merged.
- Security, dependency, coverage, visual, end-to-end and browser-test evidence can be attached to a review. See Review evidence.
Merge gates keep production changes behind explicit policy. Nothing merges without the approval your quality gates require.
Production operations
- SBOM generation and container image scanning in CI
- HTTPS-only public endpoints with TLS termination
- Automated database snapshots and restore runbooks
- Monitoring and alerting across metrics, logs and errors
Deployment options
Coroid operates under three models. The workflow remains the same in each; only the location of runtime, storage, repository access and credentials differs.
| Model | Availability | Where it runs |
|---|---|---|
| Cloud | Generally available | Coroid-operated, with an optional EU hosting profile |
| Enterprise cloud | Private preview | Coroid-operated, with contracted capacity, SSO/SAML, SCIM and audit export |
| On-premises | Private preview | Your infrastructure, with Docker Compose or Kubernetes |
On-premises
On-premises deployments allow regulated teams to keep repository access, storage, credentials and network policy within infrastructure they control.
- Docker Compose suits single-server installations and pilots. Persistent volumes hold the database, repositories and logs.
- Kubernetes suits multi-server and autoscaled installations. Helm manages the application, worker, sync and runner services, and works with managed or self-hosted PostgreSQL and object storage.
- Restricted networks can use offline model and dependency strategies, self-hosted secrets management and internal TLS.
Git access uses personal access tokens rather than a third-party app installation, and can point at internal repository hosts.
Certifications
Coroid does not currently hold a SOC 2 report or any other third-party security certification. SOC 2 represents a target for achieving readiness. A control will not be described as certified until it actually obtains such certification.