Propose an agent action

Agent actions are the safe surface for the Day-2 operations that need to happen quickly but should never happen on a single person’s say-so.

Three actions ship out of the box; more are added as the platform catches up to the long tail.

The approval gate is intentionally short: any sensitive action requires two people — a proposer and an approver — both with the right scope. The audit log captures who, when, what, and the full payload.

Propose an action

There are three propose paths:

From the AI Concierge

When you describe an action in the Concierge chat, phrasings like “rotate the stripe vault secret” or “rollback billing to last green” surface a Propose action CTA. Clicking it opens the agent-runs propose flow with the action pre-selected.

From the MCP server

If you’ve connected the MCP server to Cursor, Claude Code, Copilot, or any other MCP-aware client, the propose_agent_action tool (write scope) opens an agent run for a privileged production action right from your AI coding tool. It never executes directly — the run still lands in the two-person approval flow described below, where a different person approves it in the web app.

From the agent-runs screen

Sidebar → Agent Runs → + New run. Pick an action, fill in its required parameters (which secret, which service, which environment), submit.

What an approver sees

After you propose, the run lands in Pending approval status. Anyone in the org with the right scope sees it on the Agent Runs screen with a Review button.

A reviewer screen shows:

• Who proposed.
• What the action does. The summary is generated from the action’s metadata, not user-supplied text.
• Where it’ll run — environment, project, blast radius.
• Why (the proposer’s note, if they wrote one).
• Dry-run output — what the action would do if approved, computed without making any side-effecting calls. For rotate-vault-secret, that’s the new secret name + the environments it’ll be wired into. For rollback, the target build SHA + the diff between current and target.
• Approve / Reject buttons. Approval requires re-typing the approver’s email so a misclick doesn’t fire.

What happens on approval

• The run transitions to Running, then Succeeded / Failed.
• A live log streams from the action’s output. Closing the screen doesn’t cancel the run.
• The audit log captures: action id, proposer, approver, payload, every side effect, and the final result.
• For rotate-vault-secret + rollback, the post-action health check is part of the action — a failed check rolls the action back automatically.

Roles + scopes

The action’s metadata declares which scope is required:

{
  id: "rotate-vault-secret",
  requiresScope: "vault.write",
  blastRadius: "high",
  requiresApproval: true,  // off only for trivial actions
}

A user without the scope can’t propose; an approver without the scope can’t approve. The blastRadius field affects the approver’s required scope (high-blast-radius actions need an Org Admin or Owner approver, not just vault.write).

Why this exists

The platform engineering team that’s wired up MarBoba has hands on every credential, every deploy target, every secret rotation. Without a guardrail, every Day-2 action is one tired senior engineer at 2am from production-killing. The two-person approval flow is the same primitive that keeps databases sane (GRANT review), money sane (dual control), and aircraft sane (challenge- response checklists). Catalog-aware AI just makes proposing cheap; the approval is the safety.

See also

• Architecture: Agent actions — kernel design, blast-radius algorithm, dry-run framework.
• Add a new agent action — for platform engineers who want to wire a custom action.