Skip to main content

Approvals and safety

Last updated on

Every write tool asks for your approval. Harness MCP Server asks for confirmation before it changes anything, stops the operation when it cannot get that confirmation, and applies limits at both the transport and API layers. This topic walks through the approval flow and the safeguards that back it.

Elicitation​

Write tools (harness_create, harness_update, harness_delete, harness_execute) use MCP elicitation to prompt the user for confirmation before making changes.

  1. The LLM calls a write tool (for example, harness_create with a pipeline body).
  2. The server sends an elicitation request to the client with a summary of the operation.
  3. The user sees the details and clicks Accept or Decline.
  4. If accepted, the operation proceeds. If declined, it is blocked.
ClientElicitation Support
CursorYes
VS Code (Copilot)Yes
Claude DesktopNot yet
WindsurfNot yet
MCP InspectorYes

For clients that do not support elicitation, harness_create, harness_update, and harness_execute proceed without a dialog, while harness_delete is blocked to prevent unintended destruction.

Auto-approve for autonomous workflows​

For fully autonomous agent workflows (CI/CD bots, headless agents, batch automation), set a risk threshold so operations at or below that level proceed without a confirmation prompt:

HARNESS_AUTO_APPROVE_RISK=low_write

Operations are evaluated against this threshold in ascending order of risk: none (default, always prompt), low_write, medium_write, high_write, all.

warning

HARNESS_AUTO_APPROVE_RISK=all skips confirmation for every operation, including destructive ones such as harness_delete. Pair it with HARNESS_TOOLSETS to restrict which resource types are available.

HARNESS_SKIP_ELICITATION is deprecated. Setting it to true is equivalent to HARNESS_AUTO_APPROVE_RISK=all, and the server logs a deprecation warning to stderr. If both variables are set, HARNESS_AUTO_APPROVE_RISK takes precedence.

Sessions can also send an x-harness-auto-approve-risk header on the MCP initialize HTTP request to tighten (but not loosen) the deployment-level threshold configured through the environment variable.

Platform safeguards​

The following safeguards are always in effect, regardless of the client you connect from or the approval threshold you configure.

  • Secrets are never exposed. The secret resource type returns metadata only. Secret values are never included in any response.
  • Write operations use elicitation when available. harness_create, harness_update, harness_delete, and harness_execute prompt for user confirmation.
  • Destructive writes fail closed. If confirmation cannot be obtained, harness_delete is blocked, unless HARNESS_AUTO_APPROVE_RISK=all is set.
  • CORS restricted to same-origin. The HTTP transport prevents CSRF attacks from malicious websites.
  • Rate limiting. HTTP transport enforces 60 requests per minute per IP. The API client enforces 10 requests per second to avoid upstream rate limits.
  • Pagination bounds enforced. List queries are capped at 10,000 items total and 100 per page.
  • Retries with backoff. Transient failures (HTTP 429, 5xx) are retried with exponential backoff and jitter.
  • Localhost binding. The HTTP transport binds to 127.0.0.1 by default.
  • HTTPS enforced. HARNESS_BASE_URL must use HTTPS. Set HARNESS_ALLOW_HTTP=true only for local development.

Read-only deployments​

Set HARNESS_READ_ONLY=true to block create, update, delete, and execute operations entirely. Only list and get operations are allowed, which makes this the safest configuration for shared, demo, or exploratory environments.