Verifying an EVE Monitoring Envelope

A monitoring envelope is a signed summary of agent behavior over a window. EVE produces it from deterministic statistical detectors (rolling / robust z-score, EWMA, CUSUM). The envelope lets a reviewer confirm that a behavioral summary is authentic and unaltered — without trusting the EVE server.

Readiness: signed monitoring envelopes and behavioral anomaly detection are PILOT_READY. Monitoring is observational; enforcement decisions are made by CoreGuard, sequence, and budget controls, not by the envelope.

What it proves

• Integrity — the summarized window (counts, detector outputs, anomaly events) has not been altered since signing.
• Authenticity — the envelope was signed by the EVE signing key (ECDSA P-384 in the production configuration; HMAC-SHA256 fallback is symmetric and not independently verifiable).
• Deterministic derivation — the anomaly events were produced by named deterministic detectors (z-score / EWMA / CUSUM) over the recorded window, not by an opaque model.

What it does NOT prove

• It does not prove that an action was blocked or allowed. Monitoring is observational; it flags deviations. Enforcement is performed by CoreGuard decisions, sequence governance, and budget controls — verify those with their own evidence (see Linked evidence).
• A flagged anomaly is advisory unless it is wired to a deterministic enforcement action. A signed envelope proves the detector fired; it does not prove that anything was prevented.
• Statistical detectors flag deviations from a baseline; the envelope does not claim the deviation was malicious, nor that the absence of a flag means the absence of a problem.

Required keys

A monitoring envelope carries at least:

Verification fails closed if a required key is absent.

Canonicalization (jcs-1)

The envelope is signed over jcs-1, a constrained RFC 8785 profile with proven byte-for-byte parity across Python, TypeScript, and the browser for the supported value domain. jcs-1 is fail-closed on non-integer floats / NaN / Infinity, so rate-like values are carried as integer permille. This is a constrained profile, not full RFC 8785 float formatting. A verifier reading an envelope whose canon is not jcs-1 reports unsupported canonicalization.

Verification profiles: strict vs standard

• Standard — verifies canonicalization, content hash, signature, and schema; accepts an ECDSA P-384 signature (with a supplied public key) or, where configured, an HMAC fallback.
• Strict — additionally requires an independently verifiable ECDSA P-384 signature and rejects HMAC-fallback evidence. Use strict for third-party review with no shared secret.

Linked evidence

A monitoring envelope summarizes what happened; the corresponding enforcement is recorded elsewhere:

• Decision Certificate — the CoreGuard ALLOW / BLOCK / MODIFY decision.
• MCP Execution Evidence — approved-versus-executed binding for a tool call.
• Red Team Report — adversarial regression results, including zero-side-effect proof for blocked attacks.

Verify each linked artifact independently; a monitoring envelope does not vouch for the contents of an artifact you have not separately verified.

Selective-disclosure / omission checks

The signature covers the canonical bytes of the whole payload, including the detector outputs and anomaly-event set. A dropped or altered anomaly event invalidates the content_hash and the signature. Verify the full envelope before reading any subset; do not re-canonicalize a reduced object.

Failure categories

Freshness

A monitoring envelope describes a specific window and does not expire on its own. Enforce freshness as a policy: reject envelopes whose window ends outside your acceptance horizon (for example, "only consider windows from the last hour" for a live dashboard). Treat an over-age envelope as stale.

Replay behavior

A monitoring envelope is a record, not an authorization. Re-presenting it does not cause a side effect and does not re-trigger enforcement — monitoring is observational. If the same envelope is submitted twice, deduplicate on its window bounds and content hash.

Verify it yourself

Python

# Synthetic fixture — no production credentials.
import json
from eve_coreguard import verify_decision_record

with open("public_key.pem", "r", encoding="utf-8") as fh:
    public_key_pem = fh.read()
with open("monitoring_envelope.json", "r", encoding="utf-8") as fh:
    envelope = json.load(fh)

# VerificationResult is truthy when valid; independently_verifiable is True for ECDSA P-384.
result = verify_decision_record(envelope, public_key_pem=public_key_pem)
print(result.valid, result.independently_verifiable)  # True, True

Node (TypeScript / ESM, Node >= 18)

import { verifyDecisionRecord } from "eve-ai-governance";
import { readFileSync } from "node:fs";

const publicKeyPem = readFileSync("public_key.pem", "utf8");
const envelope = JSON.parse(readFileSync("monitoring_envelope.json", "utf8"));

const result = await verifyDecisionRecord(envelope, { publicKeyPem });
console.log(result.valid ? "VERIFIED" : "FAILED");

CLI

# The `eve` CLI ships with the EVE service/repo. Form: verify <kind> <evidence.json>
# [--strict]; the ECDSA P-384 public key is auto-fetched from /.well-known/eve-pubkey.
python -m core.eve_sdk.cli verify monitoring monitoring_envelope.json --strict

Readiness

• Signed monitoring envelopes and deterministic behavioral anomaly detection are PILOT_READY.
• Offline verification (Python / Node / browser) is SUPPORTED; jcs-1 canonicalization is SUPPORTED (constrained RFC 8785 profile).
• Independent verification requires the ECDSA P-384 public key; the HMAC fallback is symmetric and not independently verifiable.
• Monitoring runs in embedded (in-service) mode; the Python eve-coreguard client (0.2.10) reaches the service via hosted mode. TypeScript (eve-ai-governance 0.4.0) verifies offline and never signs.
• The clients are published on public registries: pip install eve-coreguard (PyPI) and npm install eve-ai-governance (npm).

Limitations

• Monitoring is observational; a signed envelope proves a detector fired, not that any action was prevented. Enforcement is a separate, deterministic decision verified with its own evidence.
• Statistical detectors produce advisory signals; they are not a zero-false-positive classifier and require a deterministic enforcement action to have effect.
• In the pilot, monitoring state is in-process; durable cross-instance aggregation is a deployment concern.
• HMAC-fallback signatures are not independently verifiable; use the ECDSA P-384 configuration and the strict profile for external review.