Skip to main content
Back to all releases
// October 28, 2026v1.48.2

Platform

Security and Policy

Hold risky tool calls for approval before they run, rolling out in Guardrails

A risk policy could already flag or block a matching MCP tool call. Now it has a third option: hold the call until a named approver says yes, then let exactly one retry through. Approvers decide from Guardrails or straight from a Slack DM, and every project gets the MCP server an agent needs to ask for approval set up automatically. This is rolling out behind a feature flag; ask your account team to turn it on.

Features

  • Require approval for tool calls #7726 - Guardrails gets a new policy use case: choose the tools it covers, name approvers as specific people or roles, then review held calls from a Tool approvals tab where each argument sits on its own row beside the agent's reason, with Approve and Deny. (#7712, #7713, @mfbx9da4)
  • Approval requests arrive as Slack DMs #7728 - Each named approver gets a direct message from the Speakeasy app with the tool, the agent's reason, and every argument as its own field, plus Approve and Deny buttons that resolve the same request Guardrails shows. (Author: @mfbx9da4)
  • Every project gets a built-in approvals server #7739 - Agents on the Default plugin can call request_approval right away. Speakeasy creates a dedicated <organization>-<project>-approvals server and adds it to the plugin automatically, so a team no longer has to wire one up by hand before approvals work. (Author: @mfbx9da4)

Bug fixes

  • Held calls on proxied servers come back as a usable result #7732 - A call waiting on approval now returns as a tool result marked isError, carrying the request token and the steps to request approval, instead of a JSON-RPC error that agents treat as a plain failure. (Author: @mfbx9da4)
Sagar Batchu
Sagar Batchu
View on GitHub