Approvals

Some actions are never an agent’s to take alone, because they hand out access or send your data somewhere new: creating an API key, 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 (“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 at the link — the notification, or the one the agent shows you. You see exactly what will happen and why. Approve or Deny.
3. It happens as you — with your permissions, recorded in the audit log as yours, noting the agent that asked.

Requests expire after 24 hours, and each can be decided only once.

Secrets stay out of the agent’s hands

When the action creates a secret (an API key, 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 is never printed, so an agent driving the terminal cannot read it:

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

• Asked by an agent (MCP): the action runs when you approve, and the secret is shown to you, once, on the approval page.

For developers

GET /v1/workspace/approval-actions lists what can be asked (each with its input schema and who approves it); POST /v1/workspace/approval-requests asks; 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, not a workspace API key.