EVIDE ANCHOR

On July 31, 2026, RedHotCyber documented a real incident: an AI agent, connected directly to a production database with autonomous access to a code repository, executed a migration command that treated production as a disposable test environment — deleting all tables of the project, two of them unrecoverable. The agent noticed the anomaly and reported it. The boundary between production and development had never been technically enforced, nor preserved through an independent evidentiary declaration — it existed only as an implicit expectation.

An evidentiary boundary can never be made "impassable." EVIDE ANCHOR does not attempt to. It preserves the declaration of a boundary — independently, before the agent acts — without enforcing it, without verifying it, without deciding whether it was correct.

Without an independently preserved declaration, the reconstruction of an operational perimeter after an incident depends entirely on the systems and narratives of the parties involved — logs, internal policies, configuration files, emails, commit history, human recollection. Sometimes that reconstruction succeeds. Sometimes it cannot.

Declaration is not a structure specific to ANCHOR. It is an architectural primitive of EVIDE — distinct from Event/Decision (decision_record, intervention), Artifact/Evidence (evidence_references), and Chain (chain): an explicit, attributable, and time-locatable statement.

Accessible everywhere as the declarations: [Declaration, ...] array, activated with extensions: ["declarations"] — the same bidirectional pattern already used for evidence_references.

Canonicalization follows RFC 8785 (JSON Canonicalization Scheme): declaration_digest = SHA-256("EVIDE_DECLARATION_V1:" || JCS(Declaration_Payload)). The prefix provides domain separation — it prevents a Declaration's digest from colliding with that of another EVIDE object type, and explicitly versions the canonicalization scheme itself.

Both authority_source.references[] and subject_references[] use the same Reference shape already used for evidence_references. This is where a Declaration can optionally carry an integrity hash — not on the Declaration itself, but on a document or system it cites. Full field reference: EVIDE JSON Schema — ANCHOR fields.

Surfaced during end-to-end MCP validation, not designed in advance: an agent combined environment and privileges into a single composite declaration. The rule that followed:

A later Declaration can relate to an earlier one through declared_relations[] — stating that it supersedes, clarifies, revokes, restricts, or expands it, by pointing to the earlier Declaration's target_declaration_digest, never to its evide_id. A Declaration is never rewritten. A change to a perimeter is itself a new, dated, attributed Declaration.

declaration_type is free text, not a closed enum — consistent with chain_type and every other categorizing field in EVIDE. Six documented types, not exhaustive:

Seven forensic questions, each verified against the schema — none required a field that did not already exist at the time it was posed.

The questions above are abstract. What follows is not — eleven scenarios, across the incident that motivated ANCHOR and ten unrelated domains, contrasting what a post-incident investigation can establish without a declared perimeter, against what it can establish with one.

The scenarios in Section 5 answer, domain by domain, the same underlying question the design process posed for the model to hold generally: what was the declared perimeter, and who declared it, before the agent acted?

Full sector-by-sector detail, including what each declaration would make independently reconstructible: EVIDE ANCHOR Working Paper, Section 6.

Four protocols, four distinct questions — no overlap.

Seven constraints, not six — the seventh is what prevents the system from filling an absence on its own:

• Does not verify whether declarations correspond to operational reality, nor compare what was declared with what was observed — that comparison is for later investigators, never for EVIDE
• Does not enforce or apply any declared policy, limit, or privilege
• Does not block, authorize, or prevent any agent operation
• Does not judge whether the declared authority was legitimate, sufficient, or actually held by whoever exercised it
• Does not attribute responsibility or establish fault
• Does not assume that the absence of a declaration equals the absence of the corresponding constraint — it is a neutral fact (no one declared it), not a judgment (therefore it did not exist)
• Never infers, completes, or interprets declarations that do not exist

ANCHOR does not itself provide the long-term integrity of a Declaration. That guarantee comes from the underlying EVIDE evidentiary infrastructure. Each Declaration becomes part of the canonical intake payload, benefits from the same hash-verifiable, tamper-evident evidentiary record as the rest of the intake, and is anchored through the platform's standard canonicalization and integrity mechanisms — the same RFC 8785 canonicalization used across every other EVIDE object type.

EVIDE ANCHOR is implemented in Schema 2.1. The declarations field is subject to whitelisting and structural validation, travels through the existing intake endpoint, and is included in EAR records and archive views. Validation enforces the conditional requirement of hashed_by whenever hash is present, and declaration_digest is computed server-side.

Validated through five end-to-end scenarios executed via a real MCP client: standard intake, Evidence References, the Epistemic Stabilization Buffer, ANCHOR, and a combination of all three extensions in the same record. Validation confirmed that multiple Declarations can coexist within one intake and that ANCHOR does not alter FCC/DWC/FAC inferences.

EVIDE ANCHOR Working Paper (signed): app.certifywebcontent.com/working-papers

EVIDE JSON Schema — ANCHOR fields: app.certifywebcontent.com/json#anchor

EVIDE Intake Schema Documentation: Intake schema reference

EVIDE MCP Server: MCP Server documentation

EVIDE for Autonomous Robotics — worked ANCHOR example: Use case with declared operational perimeter

EVIDE for Critical Infrastructure — worked ANCHOR example: Use case with declared control_state

Forensic Cross-Check (FCC): Related evidentiary construct

Evidentiary Continuity: Chaining responsibility across decisions

Originating incident: RedHotCyber, July 2026