Approvals

Some actions are never an agent’s to take alone, because they give out access or send your data somewhere new: creating an API key, or adding, removing or re-enabling a webhook endpoint. An agent that needs one asks, and a person who could do it themselves decides.

How it works

1. The agent asks, with the action, its details and a reason, such as “I’m connecting acme-web and need an API key that can read the workspace”. Everyone who could approve it gets a notification.
2. A person decides, from the notification or the link the agent shows. You see exactly what will happen and why, and choose Approve or Deny.
3. It happens as you, with your permissions. The audit log records it under your name, along with the agent that asked.

A request expires after 24 hours, and a person can decide it only once.

Secrets stay out of the agent’s hands

When the action creates a secret, such as an API key or a webhook signing secret, the agent never sees it:

• Asked from the command line: after you approve, the command line writes the secret straight into a file in your project. It’s never printed, so an agent working in the terminal can’t read it.

  reminix workspace approval-requests create --action workspace.apiKey.create \
    --input '{"name":"acme-web","scopes":["workspace:read"]}' \
    --reason "Connect acme-web" --json
  reminix workspace approval-requests redeem <id> --wait --write-env .env
  # Done: … Wrote REMINIX_API_KEY to .env (the value is not shown).

• Asked by an agent over MCP: the action runs when you approve, and you see the secret, once, on the approval page.

For developers

GET /v1/workspace/approval-actions lists what an agent can ask for, each with its input schema and who approves it. POST /v1/workspace/approval-requests asks, and GET /v1/workspace/approval-requests/{id} reports the decision. Asking needs the workspace.approvals:write scope and a person’s credential: a personal access token, or an app a person connected, but not a workspace API key.