Security

Read-only by default

Connecting AWS creates one role, groundcrew-read-only, from a CloudFormation template you can read before you run it. Only Groundcrew's platform identity can assume it, only with your workspace's ExternalId, for one hour at a time. It reads configuration, metadata, logs, and metrics. An explicit deny blocks secret values, parameter values, KMS decryption, and S3 object contents, and an explicit deny wins over any permission added later. Groundcrew also refuses any AWS call outside a read-only allowlist before it is sent.

On Kubernetes, the read-only ClusterRole has get, list, and watch on workloads, services, ingresses, pods, and events, plus pod logs. It has no access to Secrets or ConfigMaps, no exec, and no write verb. Vercel and GitHub reads go through allowlists of read-only endpoints.

Write tiers you opt into

• Deploy (Tier=deploy): a role that may create and change only resources named groundcrew-* and tagged project=groundcrew, in a dedicated groundcrew-deploys ECS cluster. It can write deploy secrets under groundcrew/* but never read them.
• Operate (EnableOperate=true): a role for emergency fixes (roll an ECS service back to an earlier revision, restart it, move a secret back to its previous version, roll back a Lambda alias, reboot an impaired EC2 instance), limited to the exact resources you list. It cannot pass Groundcrew's own roles and cannot read secret values.
• On Kubernetes, deploys go only into gc-* namespaces, enforced by an admission policy, and emergency fixes are a separate, optional role that can only patch Deployments and StatefulSets.

• Every write (a deploy plan, a fix pull request) and every emergency action needs a person's approval.
• The approval is bound to a hash of the exact plan: the resources, the current state, and the desired state. If the plan changes, the approval no longer applies.
• An approved action can run once. Before it writes, Groundcrew checks the state again and stops if it changed since the plan was approved.
• Rejecting is always possible, and stopping a run rejects everything it was waiting for.
• Code fixes are pull requests on a new branch. Groundcrew never merges and never pushes to your default branch.

• Owners manage members, connections, and settings, and approve everything.
• Approvers start deploys and runs and approve deploys and fixes. A workspace can keep emergency actions for owners only.
• Viewers see everything in the workspace and change nothing.

Each workspace has an audit log of who approved or rejected what and when, and of every change to members, invitations, connections, and settings. Every member can read it in Settings. People outside a workspace cannot see that it exists: its pages and API routes answer as if it did not.

Building your code means running it. Builds and smoke tests run in a separate container daemon that runs without root under its own system user, with containers inside a gVisor sandbox. A build has its own network with no route to Groundcrew's database, API, or the cloud metadata service, and limits on CPU, memory, disk, processes, and time. Nothing from the host is mounted into it. Registry credentials are passed for a single push and not kept, and everything a build created is removed when it ends. An image leaves the sandbox only after you approve the deploy plan.

• No long-lived cloud keys: AWS access is short-lived role sessions, kept in memory.
• Tokens and kubeconfigs you paste are encrypted at rest and never shown again.
• Tokens and keys are redacted from logs, error messages, and text sent to models.
• All traffic to Groundcrew uses TLS 1.2 or later, with HSTS.
• Sign-in is GitHub or a single-use email link; sessions use secure, HTTP-only cookies.

The full list of what is read and stored is in the Privacy Policy.

You can cut Groundcrew off at any time from your side:

• AWS: delete the groundcrew-read-only CloudFormation stack. Every role it created goes with it.
• GitHub: uninstall the Groundcrew GitHub App, or remove repositories from it.
• Kubernetes: kubectl delete -f k8s-readonly-rbac.yaml (and the operate file if you applied it), or delete the service account.
• Vercel: delete the token in your Vercel account settings.

Then delete the connection in Groundcrew to remove what it stored. Step-by-step guides are in the docs.

Write to security@groundkrew.com with what you found and how to reproduce it. Please give us time to fix it before telling others, and do not access other people's data or disrupt the service while testing. We will reply as soon as we can and tell you when it is fixed.