Approvals and audit log
Groundcrew's agents read freely and change nothing on their own. Every change to your infrastructure or repositories is a plan that a person approves, and every decision is recorded with who made it.
The rule
Every tool an agent can use is either a read, a write, or an emergency action. Reads run at once. Writes and emergency actions never run directly: they create an approval, and the run waits until a person decides.
Models never run their own text as an action. When Medic suggests a fix, Groundcrew builds the concrete pull request or action plan itself, and that plan is what you approve.
What needs an approval
| Change | Kind | Who can approve |
|---|---|---|
| A deploy plan | Write | Owners and approvers |
| A fix pull request | Write | Owners and approvers |
| A rollback after a failed deploy | Emergency | Owners, or approvers too if allowed |
| An emergency fix (rollback, restart, secret rollback, reboot) | Emergency | Owners, or approvers too if allowed |
Owners decide who approves emergency actions in Settings, Approvals and limits. Viewers never approve. All permissions by role.
Approving and rejecting
The approval card shows what will happen: for a deploy, every resource and the exact image; for a pull request, the files and diff; for an emergency action, before and after lines. Choose the approve button on the card (for example Approve and deploy or Approve and run) or Reject.
- Approving runs that plan once. The run picks up where it waited.
- Rejecting ends that step without any change. For an incident, Medic records the rejection.
- Stopping a run rejects all of its pending approvals.
Approving is always done signed in, in Groundcrew. Notifications never carry approve links; see why.
Bound to the plan
An approval is not a general permission. It is tied to one plan:
- The exact plan. The approval records a fingerprint of the plan: the action, the connection, the target, and the before and after state. A different plan does not match it.
- Used once. After approving, Groundcrew issues a signed, single-use token for that plan and that run. The first write spends it, so the change happens exactly once, however many workers pick it up.
- Checked again before writing. An emergency action re-reads the current state. If it no longer matches the plan, for example because someone deployed in the meantime, nothing is written and the fix is marked failed with the reason.
The Approvals inbox
Approvals in the sidebar lists everything waiting for a decision across the workspace, with a count badge, and the history of decided approvals: what it was, who decided, and when. The Overview page shows the pending count too.
The activity log
Settings, Activity is the workspace's audit log. Every member can read it. Each entry has who did it, when, and the client address. It records:
- Every approval and rejection, with the tool, its kind, and the run.
- Members added, removed, or given another role; invites created, changed, or cancelled; members leaving.
- Connections added, changed (regions, deploys, emergency fixes, deploy settings), or removed.
- Workspace name and settings changes, including notifications and limits.
- GitHub installations an owner proved access to.
Entries cannot be edited or deleted by members. When a person deletes their account, their name stays on the entries they made. The log goes only when the whole workspace is deleted.
What Groundcrew can access
Settings, What Groundcrew can access lists each connection with what it reads and what it may change after an approval, so you can review the whole workspace's access in one place. The full permission model is on the Security page.