How agent actions work

Agent actions are MarBoba’s safe surface for Day-2 operations — things like rotating a vault secret, scaling a service, or rolling back to the last good deploy. Every action runs through a two-person approval flow: one person proposes it, a different person reviews and approves it, and only then does it execute.

Three actions ship out of the box: rotate a vault secret, scale a service, and roll back to the last green deploy.

The action lifecycle

Every agent action moves through the same states:

proposed → pending approval → running → succeeded
              │                  │
              └─→ rejected        └─→ failed → (auto-rollback, if configured)

The person who proposes an action cannot approve their own proposal — the two-person rule is enforced for you. Each transition is recorded in the audit log.

Dry-run previews

When someone proposes an action, MarBoba computes a dry-run — a preview of exactly what would happen, with no side effects. The preview shows which items change, what the before-and-after values are, and what health check runs afterward.

This is what makes the approval informed: the reviewer reads the dry-run preview and decides whether it’s what they want — they don’t have to take the proposer’s word for it.

For example, a “rotate vault secret” dry-run shows which secret will rotate, when it was last rotated, every environment that will pick up the new value, and the health check that runs after.

Blast radius

Every action has a blast radius — low, medium, or high — that determines who is allowed to approve it:

Blast radius can also be raised by the action’s target. Scaling a service in production, for example, is treated as high blast radius and requires an admin or owner to approve — regardless of the action’s normal rating. Dependencies you’ve marked as high blast radius in your catalog drive the same upgrade.

The audit trail

Every proposal, approval, rejection, and execution writes an immutable audit-log entry. A failed action keeps its full record, including the execution log, so the reviewer can fix the underlying issue and re-propose — the screen pre-fills the original inputs.

This trail is what compliance reviewers and incident postmortems trace through.

See also

• Propose an agent action — the step-by-step user flow.
• The catalog data model — how dependencies and blast radius are modeled.