Escanor

Use case

Safe deploys for AI coding agents

Let coding agents such as Claude Code and Cursor inspect deployments and propose changes, while the redeploy or rollback that reaches production waits for a person. Escanor gives agents five MCP tools that reach your connected providers through one revocable key, and keeps the risky steps behind confirmation and approval.

Sign up freeSee Escanor MCP

How it works

  1. Step 1

    Give the agent one key

    Open MCP in the dashboard. It creates a key and shows the exact setup for Claude Code, Claude Desktop, Cursor, VS Code or any app that supports remote MCP servers. Name one key per agent so you can revoke one without touching the others.

    Connect an agent

  2. Step 2

    Let it read before it writes

    The agent finds operations with escanor_list_tools and runs them with escanor_invoke. Start with a read, such as the last three staging deployments, and compare the answer with the provider dashboard.

    Before granting access

  3. Step 3

    Confirm destructive operations

    Destructive operations need confirm=true in their arguments, so an agent cannot delete or overwrite something by accident. Check the target resource before the agent supplies it.

    Escanor MCP

  4. Step 4

    Approve the deploy, then verify

    Supported deployments offer approve, reject, redeploy and cancel. Review the exact target, then check the new provider deployment, the deployed revision and the user flow it was meant to fix.

    Approvals and changes

What stops an agent from shipping by itself

  • Each MCP call runs with your workspace’s stored credential for that provider, only for the length of the call. Provider credentials never go into prompts or tool arguments.
  • Read-only tokens and limited allowed-write policies keep an agent to the operations you choose.
  • MCP activity lists every call in plain language, and every key shows its last use. Revoking a key cuts that agent off at once.
  • Workspace roles and provider permissions apply on top of every key.

Keys and their lifecycle are covered in API and keys.

Rollbacks start as a dry run

A rollback request names the service, a known-good commit and dry_run, which defaults to true. With the dry run on, the request proposes the rollback without changing production. Rollback works on supported connected services.

{"service_slug":"YOUR_SERVICE_ID","target_sha":"KNOWN_GOOD_COMMIT","dry_run":true}

More in Deployments: rollback.

Agent runs that wait for you

Automations runs a goal with optional “Done when” criteria and records each step. Anything that needs a decision shows under Needs you, where an owner or manager can approve, deny or stop it. Settings hold the autonomy level, per-action overrides and budgets, including run/day and automatic-approval limits. Stop everything now pauses automation across the workspace.

A good first goal is read-only: investigate the most recent failed staging deployment, report the first build error with evidence, propose one fix, and do not deploy. See Automate operations with Autopilot.

A deploy checklist for agent-driven changes

  1. Connect providers with the narrowest permissions that do the job.
  2. Ask the agent to explain a failure from the logs without redeploying.
  3. Approve one bounded change against the exact target.
  4. If a request times out, check activity before retrying, so you do not deploy twice.
  5. Confirm the provider accepted the action, check the deployed revision, and test the affected flow.
  6. Record the outcome in activity or your team's change record.
Sign up freeWatch the demoBook a call