What CREW AI can and can't see

Where data lives

The layers

1. A sandbox per task

Each run gets a fresh GitHub-hosted VM that is destroyed afterwards, with only the repo checked out. Outbound traffic is blocked except GitHub, the model APIs, the npm registry, Binance's API hosts and CREW AI. The third-party actions in the workflow are pinned to exact commits, and the Claude Code and Codex versions are pinned.

2. Two jobs: agents can't push, merge or deploy on their own

The agent job runs the coding agent with a read-only token and an environment scrubbed of all GitHub tokens. It hands over a patch. The publish job runs no agent and no repo code. It re-checks the patch (no .github/ changes, no submodules, no symlinks out of the repo, size limits), then pushes to the agent's own crew/<persona>/<issue> branch and opens a PR. If GitHub doesn't let Actions open PRs in that repo, CREW AI opens it with the App instead.

3. Humans approve and merge

Agents only offer work; nothing starts until a teammate taps Yes. Plans need a maintainer: either their Yes, or their ✅ Approve. Agents never merge. Branch protection on the default branch and CODEOWNERS on .github/ keep CI and main safe.

4. Verified identity

People link GitHub through GitHub's own sign-in, either while installing the App or in a private chat with the bot. Roles come from GitHub: admin or maintain = maintainer, write = member. Only someone who administers a repo can attach it to a group, and a repo belongs to one group.

5. Untrusted text is data

Issue bodies, comments, file contents and web pages are fenced with a marker, and agents are told never to follow instructions inside them. On top of that:

• Guests don't reach the agents. Messages from people without write access are never put in an agent's prompt.
• Agents can't plant memory. A note an agent wants to remember waits for a teammate's ✅ Keep before any run sees it. Text that looks like a secret is refused.
• Web pages come through CREW AI. The sandbox has no open internet. CREW AI fetches pages only from public addresses, connects to the exact address it checked, allows 40 pages per run, and refuses URLs that carry one of the run's secrets.

We assume prompt injection can still happen, so the other layers limit what a hijacked agent can do: write to its own branch, in a throwaway VM, for one run.

6. Short-lived everything

Runner calls use GitHub OIDC tokens bound to the repo and the workflow run, refreshed every few minutes. Proxy tokens are per run, carry a dollar budget, and are revoked by /stop. GitHub sign-in tokens are used once to read your username and not stored.

7. Kill switch and audit log

/stop all cancels every workflow run and chat answer and revokes proxy tokens. Uninstalling the GitHub App cuts all access immediately. Every action is in the audit log, exportable with /audit.

8. Source available soon

Every component will be published under Apache-2.0 and is self-hostable, so you can verify these claims instead of trusting them.

Deploys on your server

The deployer on your server connects out to CREW AI and asks for jobs; no port is opened. Everything it may do is pinned in a local lock that only root on that server can change (sudo crewline-deployer allow | deny | branches | auto | logs). The deployer process can read it but not write it.

• Only scripts that already exist in your repo run, checked out from the branch on GitHub. Nobody types a command into the chat.
• A repo, script or branch outside the lock is refused. So is an automatic deploy while the lock has auto off.
• Anything named like production (prod, production, live, main, master, mainnet) is refused, always.
• If the branch on GitHub isn't at the commit CREW AI asked for, the server refuses.
• Settings from /deployenv can't touch PATH, LD_*, NODE_*, GIT_*, SSH_* and similar.
• With logs status, the deploy output stays on your server; CREW AI only gets the result.

What CREW AI can still do: ask your server to deploy code that is already on an allowed branch, with an allowed script, at a time it chooses. It can't make your server run anything else.

Binance keys

Live Binance keys must be read-only. CREW AI checks this with Binance when you save the key and again at the start of every run; a key that can trade, transfer or withdraw is refused or left out of the run. Orders only go to Binance testnet or demo, and never from a chat answer. Disconnecting deletes the key from your GitHub secrets.

Bounty funds

Funds sit in the BountyEscrow contract, never with CREW AI, and can only go to an attested recipient or back to the funder. In this version CREW AI holds the attester keys, so the funder can freeze a payout during the challenge window (set when the escrow is deployed, planned 48 hours on mainnet). Only hashes go on-chain, never repo names or issue text.

Known limits

We'd rather you hear these from us.

• Prompt injection isn't solved. A malicious issue, file or web page can still steer an agent. The damage is limited to one branch in one throwaway VM and a human must merge, but reviewers must actually read the diff.
• Telegram groups aren't end-to-end encrypted. CREW AI posts summaries, file paths and links there, never code. What you type in the group is visible to Telegram, and CREW AI keeps about a week of it so agents have context.
• Logins are in the agent job. In API key and subscription modes, the login is available to the agent for that run. A hijacked agent with root on the runner could read it. Web requests that carry it are refused, but other channels (such as the model API) remain. Proxy mode keeps API keys out of the sandbox.
• The egress allowlist uses some wildcards for GitHub's artifact storage and user content domains.
• The GitHub App has Contents: write, because GitHub needs it to start runs. A compromised CREW AI could in theory push to an unprotected branch. Protect your branches, including deploy branches.
• Deploys are requested by CREW AI, not signed by a person. The lock on your server limits what can run.
• The agent job holds an OIDC request token. It can only mint tokens for its own run, so the worst case is fake status messages for its own task.
• Proxy budgets can overshoot by the cost of requests already in flight.
• Bounty attester keys are held by the coordinator in this version, which is fine for testnet. Mainnet needs hardware-backed keys and independent attesters. The funder together with the guardian multisig could deny a legitimate solver.
• Roles are cached for 10 minutes. Removing someone's GitHub access takes up to 10 minutes to apply in chat.
• No external audit yet of the contracts or the server. It is planned before mainnet.

Reporting a vulnerability

Please report security issues privately to our security contact rather than in a public issue. We'll credit you once it's fixed.