crew-cloud

Files (1)

• SKILL.md

SKILL.md (first lines)

# Cloud MCP servers

Both clouds ship official MCP servers. Both authenticate as **you**, with your
existing credentials — which is the part that deserves care before the part
about which package to install.

---

## Read the risk first

An MCP server that reaches your account does so with whatever your credential
chain grants. If your default AWS profile is an admin role, so is the agent's.
There is no "read-only mode" flag that saves you; the constraint has to come from
the credential.

Three rules, and `crew-setup` should enforce them by asking:

1. **A dedicated profile, scoped read-only**, pointed at a non-production account
   wherever possible. Not your daily driver profile.
2. **Never `AWS_PROFILE=production`** or a subscription with write scope, in any
   repo where an agent runs unattended.
3. **Start with the documentation and pricing servers**, which touch no account
   at all, and only add account-reaching servers when a task actually needs one.

crew's cloud guard (below) can refuse destructive `aws`/`az` commands and
commands run as the wrong identity, but a guard on the shell does not cover an
MCP tool call. The credential is the real boundary. A cloud credential in the
agent's environment is also one `env` away from its context and transcript:
`guards.envGuard` (off by default; README "Environment guard") refuses the
commands that print it, and a sealed, per-command credential keeps it out of
the environment in the first place.

---

## The cloud guard and identity pinning

`hooks/scripts/cloud_guard.py`, a PreToolUse hook on the Bash **and** PowerShell
tools. **It ships off.** Turn it on per machine or per repo:

```json
{ "guards": { "cloudGuard": "report" } }
```

`report` logs to `.crew/guard.log` what it *would* have refused, shows you the
same as a message, and refuses nothing — it answers with **no** permission
decision, so your normal prompts run exactly as they would without it (it never
answers `allow`). Run it for a few days first. `block` enforces. A repo can
never turn off a machine-global `block` (the `guards` ratchet).

What each recognised command gets is the existing per-rule key, `block` by
default: `guards.cloudDestructive` for `aws … delete-*/terminate-*/purge-*`,
`aws s3 rm|rb`, `aws s3 sync --delete`, `az … delete|purge` and `Remove-Az*`;
`guards.sqlDestructive` for `DROP`/`TRUNCATE` sent to `psql`, `mysql`, `sqlcmd`,
`sqlite3` or `Invoke-Sqlcmd`; `guards.terraformApply` for `terraform`/`tofu`
`apply`/`destroy`; `guards.forcePush` and `guards.adminMerge` for git and gh.
`ask` prompts; `allow` lets it through and logs it — except that since crew
1.0.42 a terraform destroy (or an apply of a plan crew cannot read) asks even
under `allow`, and `environments.*` lets non-production applies run unattended
under `ask` (README "Cloud guard", docs/crew/config-rationale.md).

`guards.deployWorkflow` (T-0009) judges `gh workflow run <wf>` and its REST
twin, `gh api -X POST repos/<o>/<r>/actions/workflows/<wf>/dispatches`, when
`<wf>` matches a key of the repo-only `environments.workflows` map
(`{"deploy.yml": "input:environment", "deploy-prod.yml": "production"}`). A
workflow matching no key is not judged. Under `ask` in both layers a nonProd
environment runs unattended; production does only with
`environments.prodUnattended` true in both layers. `allow` covers nonProd only:
production without `prodUnattended`, and an environment crew cannot identify
(no input, conflicting values, two workflow arguments, no workflow named),
still ask and are refused unattended. Not seen: an unlisted spelling of the
workflow (display name, numeric id), the workflow YAML, `gh run rerun`,
`gh alias`, `curl`.

DISPATCH GRAMMAR. A dispatch line is judged only when every word is a plain
literal or one whole single-quoted word, joined only by `;` `&&` `||` `&`,
newlines, `>`/`>>`/`&>`/`&>>` to a plain word and `2>&1`; anything else — a
pipe, any `<`, `$`, double quotes, a glob, a nested or `xargs`-fed dispatch, a
copy or alias of `gh`, a command word made at run time whose arguments could
follow part of a dispatch (`$X $Y run x`, `$C`, `xargs -I CMD CMD workflow
run x`, `Start-Process $x`, an alias to a run-time value), gh reading stdin or
a file (`--json`, `--input`, `-F k=@f`), a PowerShell launcher or alias
holding gh, `workflow` or a run-time word with any parameter that is not a
full, value-taking name (a switch, `-Fi`, `-Args`), and a malformed
`environments` block in either layer — is could-not-tell; gh and `workflow`
count only in one command, so `alias g=gh; echo workflow` is not judged. A
could-not-tell line is asked when attended, refused unattended, and approved
one exact command at a time by the marker the refusal names. Write
`-f` fields and single quotes instead (README "The dispatch grammar"); a
literal `--help` is not judged.

Not destructive, so not refused: `aws … --dry-run` / `--dryrun`, `Remove-Az*
-WhatIf`, and `terraform apply -help`. SQL is read in the client's own dialect —
PostgreSQL for `psql` (a backslash is a plain character except in `E'…'`),
MySQL for `mysql`/`mariadb` (`#` comments, `\'` escapes, `/*! … */` runs),
T-SQL for `sqlcmd`/`Invoke-Sqlcmd` — so a correct literal is not misread as a
statement.

Refused whatever the policy, as `[cloudGuard]`, because crew could not read
them: a command nested more than six shells or substitutions deep, and hook
input that is not a readable Bash/PowerShell call. A destructive-capable tool
(`terraform`, `aws`, `az`, a SQL client, `git push`) run through `xargs` or
`parallel`, whose arguments come from stdin, is judged under that tool's own
rule as if it were destructive — `echo destroy | xargs terraform` is a
`terraformApply` refusal. A pipe is followed through every stage:
`echo 'DROP TABLE t;' | tee q | psql` is a `sqlDestructive` refusal.

### Pin the identity this repo may act as

In the repo's `.crew/config.json` (repo-only — a machine-global `cloud` block is
ignored, like `production`):

```json
{ "cloud": {
    "awsProfiles": ["acme-dev", "acme-sandbox-*"],
    "awsRegions": ["eu-west-1"],
    "azureSubscriptions": ["00000000-0000-0000-0000-000000000000", "Acme Dev"] } }
```

**AWS.** Every `aws` command's profile is read from `--profile`, then the

From mbadali25/useful-claude-add-ons, GPL-2.0.

More from mbadali25/useful-claude-add-ons