CoRoid does autonomous engineering work on your code. This page covers where that work runs, what it can reach, how credentials and data are protected, and what record it leaves. It describes the controls in place today. Planned controls are labeled as planned.
Where agent work runs
Every task runs in its own isolated cloud workspace. The workspace is created for that task and torn down after it. Agents read and write only the repository checked out into it.
There are three zones:
| Zone | Owner | What it holds |
|---|---|---|
| Agent workspace | CoRoid | One task's checkout, build and test tooling. Created per task, torn down after it. |
| Control plane | CoRoid | Scheduling, specifications, evidence and the decision trail. Holds project-scoped credentials through encrypted configuration. |
| Your network and production | You | Not reachable from an agent workspace. |
- Agent workspaceRun by CoRoidOne task's checkout, build and test tooling.
- Control planeRun by CoRoidScheduling, specifications, evidence and the decision trail. Credentials stay encrypted.
- Your network and productionYoursNo IDE extension, local agent or network access needed.
An agent workspace cannot reach your network or production.
The only way out is a pull request, which your team decides whether to merge.
Work leaves the workspace in one form: a pull request. Your team decides whether it merges, and your own deployment path takes it from there. CoRoid needs no IDE extension, no local agent and no access to your private network.
What a workspace can reach on the internet
A workspace that builds and tests your code reaches public internet addresses directly, so installs and downloads work as they do on a developer machine. It never reaches private addresses: the cluster's internal network, the cloud metadata service and private ranges are closed to it.
Sandbox network, under Security → Settings, sends a scope's workspaces through CoRoid's egress proxy instead. It is off until you turn it on, for the organization default or for one project, on every plan:
- On (observe). Every connection goes through the proxy, which records the host and port for the task, never a path or any content. Nothing is refused.
- Refuse what isn't allowed (enforce), chosen in the protection's panel. The proxy allows public package registries (npm, PyPI, Go modules, crates.io, RubyGems, Maven Central and Gradle, NuGet, Packagist, Hex, pub.dev, conda), your project's git host and the hosts on the setting's allow list. It refuses everything else. When a command fails after a refusal, the agent is told which host was refused and why.
The panel shows where sandboxes connected in the last 30 days: each host and port, how many tasks and connections, the task that reached it last, and whether it was allowed, refused, or would be refused under enforce with today's list. Allow adds a host to the list. Start in observe: the list shows what enforce would refuse before you turn it on.
A task's Network section, in its Factory view, lists the destinations its workspaces reached, refusals first. A scan CoRoid runs itself (a security scan, for one) holds its workspace in a task of its own; that task says which scan it was and lists its destinations the same way.
In both modes a connection that bypasses the proxy, such as a raw TCP
connection, fails, and the proxy never connects to a private address. Tools
find the proxy through the standard proxy variables, which CoRoid sets; Maven
reads its proxy only from settings.xml, so a Maven build cannot reach the
internet while Sandbox network is on. Name lookups still go through the
cluster's resolver. A change applies to workspaces created after it.
Each allow list entry is a host (api.example.com), its subdomains
(*.example.com), or either with a port (example.com:8443; without a port,
80 and 443). A project with its own setup has its own mode and list; Use
the default returns it to the organization's. The setting travels with
settings portability, like the rest of Security's
settings.
Identity and access
Authentication is centralized 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. A project's credentials cannot be used by another project, and CoRoid does not need organization-wide credentials to work on one repository. See Connect your code.
Organization owners and admins manage members, sessions and the security event feed under Settings → Identity 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.
- Your organization's credentials, such as provider keys, repository tokens and other integration secrets, are encrypted with a data key of your organization's own. A key management service encrypts that data key in turn. Only CoRoid's credential broker can decrypt them, and it records every use. See Provider keys.
- CoRoid's own configuration secrets 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 artifacts are kept. See Data retention.
The decision trail
Every autonomous change is explained in terms reviewers and security teams already use:
- the specification, agent activity, review and approval decision stay connected 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 runs in three operating models. The workflow is the same in each; what changes is where runtime, storage, repository access and credentials live.
| 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 let regulated teams keep repository access, storage, credentials and network policy inside infrastructure they govern.
- 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 other third-party security certification. SOC 2 is a readiness target. We will not describe a control as certified until it is.
Related
- Security: finding and fixing vulnerabilities in your own code and dependencies
- Data retention
- Provider keys
- Plans and pricing
- Review evidence