Skip to main content
Some actions are too consequential to run just because an agent asked. For those, Apostra records the agent’s request and waits until a person approves it on the Apostra site. The agent gets a link to share with that person; nothing happens until they approve.

​
Which actions need approval

An action needs approval when it grants or removes access to an account, creates an account or another commercial commitment, or cannot be undone. Routine and reversible work, such as reading, drafting and edits you can undo, runs straight away on the authority you gave the agent. The page for each action says whether it needs approval. These actions need it today:

​
Why the approval happens on our site

When an agent calls Apostra through MCP or the API, Apostra cannot tell whether a person is behind that particular call or the agent chose to make it. An agent’s client could also show a convincing “Approve?” button that the agent controls. So for these actions the approval happens somewhere the agent and its client are not involved: a page on the Apostra site, opened in your own browser and signed in with your own login. This follows the approach the MCP specification recommends for interactions that must not pass through the model or the client.

​
What the agent receives

The action does not fail. The agent receives an approval_required result with:
  • a link to the approval page, https://<your Apostra site>/approve/<approval id>
  • the approval’s state
  • when it expires
If the agent’s client supports MCP URL-mode elicitation and keeps a streaming connection, it also receives the link once as a prompt it can show you directly (“open to approve”). Apostra does not push a notice at the moment you decide. When the agent next repeats the request and the approval is final, the client also receives the elicitation completion notice on that same connection. Clients without that support get only the result above, which already includes the link. The link carries only an unguessable id: no account name, no operation details and no token. The agent shows you the link and checks the outcome later by repeating the same request with the same idempotency key. Repeating the request never creates a second approval, and reusing the key for a different request is refused.

​
Who can approve

Only a person who:
  • is signed in to the Apostra site in their own browser, and
  • holds the role the action requires on the account, usually administrator.
API keys, service tokens, MCP access tokens, impersonated sessions and support sessions cannot approve, even for a user who holds the role. Apostra checks the role when the page opens and again at the moment the person approves, so removing someone’s role stops them approving from then on. The person who approves does not have to be the person whose agent asked. Any administrator of the account can approve or reject.

​
What the page shows

The approval page shows what will happen, which account it applies to, who asked for it and how they authenticated (for example, “a personal API key”), which client the request came through, and the deadline for deciding. The client is recorded from the requester’s own connection, never from what the request says about itself: an MCP client the connection identified (for example “Claude over MCP”), “An MCP client” when it did not identify itself, or “The REST API”. If you do not recognise the client, reject the request.

​
What happens next

Once a request is final, Apostra deletes the detailed request data it kept for running the action, and keeps only the outcome and an audit record of the decision.

​
Limits

An account can have at most 50 requests waiting for approval, and one user can make at most 100 approval requests an hour. Beyond that, new requests are refused until some are approved, rejected or expire.