---
title: "Control-plane canary evidence"
description: "Inspect signed external evidence for semantics, journeys, and safety boundaries."
canonical: "https://ens.tools/docs/control-plane-canary"
section: "Agent platform"
stability: "beta"
version: "receipt v1 · runner 1.0"
verifiedAt: "2026-07-29"
owner: "ENS.Tools Control-plane Canary"
---

# Control-plane canary evidence

Inspect signed external evidence for semantics, journeys, and safety boundaries.

## Overview

The control-plane canary is an external, read-only agent that tests what ENS.Tools responses mean rather than stopping at HTTP availability. Every run produces an immutable Ed25519-signed receipt with assertions, latency, evidence, freshness, and semantic-drift state.

## What this covers

- Hourly semantic checks for MCP catalogue consistency, positive and negative fixtures, routing, policy, escrow truth, and fleet evidence.
- Daily browser loading, navigation, and automated WCAG journeys.
- Nightly malformed-payload, CORS, SSRF-boundary, and insecure-URL rejection checks.
- Verified Ed25519 signatures, public key identity, source-run links, assertion evidence, and latency.
- Wallet-backed enstools.eth operator identity kept separate from the receipt-only Ed25519 key.
- No funded wallet, transaction-broadcast authority, or production self-healing.

## Before you run this workflow

### Networks

- No funded transaction network
- External HTTPS against production

### Prerequisites

- Pinned Ed25519 public key
- Fresh hourly, daily, or nightly receipt

### Wallet permissions

- None; the canary cannot sign or broadcast Ethereum transactions

### Expected result

- Signature-verified assertion receipt with evidence, latency, and semantic-drift state

### Errors and recovery

- Open or update one drift issue
- Keep production self-healing disabled
- Close the issue only after fresh passing evidence

## How to use it

1. **Choose a suite.** Read hourly, daily, or nightly evidence according to the platform behaviour your task depends on.
2. **Verify provenance and freshness.** Require signature.verified, the expected key ID, and a fresh receipt. Missing or stale evidence is not a pass.
3. **Read semantic assertions.** Treat receipt.status=fail as unavailable even when the API returned HTTP 200. Inspect every non-passing assertion and semanticDrift flag.
4. **Use evidence narrowly.** A passing receipt is point-in-time evidence. It does not guarantee future behaviour or grant the canary authority to change production.
5. **Inspect the source run.** Follow the source-run link when you need the external execution context behind a receipt.

## Safe operating boundary

- Read-only external execution
- Dedicated Ed25519 signing key rather than an Ethereum wallet
- No funded wallet or transaction broadcast
- One tracked drift issue for alerts
- No automatic production repair

## Examples

### MCP request arguments

```
{ "suite": "hourly", "limit": 3 }
```

## HTTP 200 is not a passing canary

> Check signature verification, receipt freshness, receipt status, and every semantic assertion before relying on a dependent capability.

## Related guides

- [Create and control agent fleets](https://ens.tools/docs/fleets-and-control)
- [Complete MCP tool catalogue](https://ens.tools/docs/mcp-tools)
- [Troubleshooting](https://ens.tools/docs/troubleshooting)