Blog · MCP guide

MCP approval gate for AI agents

An MCP server gives an AI agent tools. An MCP approval gate makes sure the dangerous tool call pauses until a person reviews the exact action and approves it with a passkey.

What an MCP approval gate does

The Model Context Protocol makes tool access portable across agent runtimes. That is useful, but it also concentrates risk: the same agent that can summarize a ticket may be able to deploy a service, rotate a secret, refund a customer, or delete data. A gate belongs immediately before those side effects.

Cosignet exposes a remote MCP server with a request_human_approval tool. The agent calls it with the human-readable action and the exact payload it intends to execute. Cosignet creates an approval request, the approver signs the payload hash with a passkey, and the agent receives a decision.

The minimal pattern

// The agent runtime invokes this MCP tool before a high-risk action.
// In the JS SDK, the equivalent helper is cosignet.requestApproval(...).
const decision = await cosignet.request_human_approval({
  action: "Deploy api to production",
  approver_username: "alex",
  payload: {
    service: "api",
    environment: "production",
    commit: "8f31c2a",
    migration: "2026-06-27-add-tenant-flags"
  },
  wait_seconds: 25
});

if (decision.status !== "approved") {
  throw new Error(`deployment blocked: ${decision.status}`);
}

// Only now run the deploy, and only for the same payload.

The important part is not the button. It is the binding: the WebAuthn challenge includes nonce ‖ SHA-256(payload). If the agent, script, or operator changes the commit, target environment, amount, recipient, table, or filter after approval, the signed decision no longer matches the operation that is about to run.

Where to put the gate

Inside the dangerous tool, not only in the agent prompt. Prompts can be bypassed; code paths are easier to audit.
After the final parameters are known. The approver should sign the actual commit, amount, user id, destination, or SQL migration name.
Before the irreversible side effect. Do not create the approval after the deploy, payment, deletion, or external message has already happened.
With fail-closed handling. Proceed only on approved; treat pending, rejected, expired, API errors, and timeouts as stop signals.

Configure the remote MCP server

Cosignet's MCP endpoint is available over streamable HTTP. Send the API key as an X-Api-Key header; the same endpoint works from local agents, hosted runners, and locked-down networks because the agent makes the outbound call.

claude mcp add --transport http cosignet https://cosignet.com/mcp \
  --header "X-Api-Key: $COSIGNET_API_KEY"

Then instruct the agent to call request_human_approval before privileged or irreversible actions. For API details, see the MCP server reference.

What the approver sees

The approval page shows the action label, each payload field, and the payload hash. The approver signs with a passkey on their own device. Cosignet stores the raw assertion and writes approved decisions into an append-only transparency log, so the decision can be audited later. Public reveal is optional and off by default; keep secrets out of payloads and pass references instead.

Next steps

If your immediate risk is production deployment, use the same pattern in a CI/CD gate:

Read the deployment workflow Open MCP docs