The ECL-1 Version 1.0 specification

The document set at a glance

The core standard

The core standard states what a deployment must do and what a claim must say. Its Section 7 sets the conformance levels and the claim rules, and its Section 11 is the checklist an assessor works through.

• ECL-1: External Control Layer StandardECL-1 1.0, core standard, source on GitHub

  The guarantee, the six control layers, the requirements, the conformance levels and claims, and the checklist that an assessor applies.

Protocols

The protocols define the messages, evidence, and signatures that pass between the parts of a control layer. They are normative companions of the core standard, which cites each by version in its Section 3.4.

• DCMP-2: Decision and Control Message ProtocolDCMP-2 2.0, normative protocol, source on GitHub

  The messages that carry each proposed action to the decision service and its decision back to enforcement, with the facts that the decision rests on.

• EBMP-2: Evidence Bundle and Manifest ProtocolEBMP-2 2.0, normative protocol, source on GitHub

  The signed records and bundles that show why an action was or was not released, what was observed, and how the evidence was verified.

• ECL Integrity Envelope 1INTEGRITY-ENVELOPE-1 1.0, normative protocol, source on GitHub

  The signed envelope and canonical JSON form of every ECL object, and the offline package, so that evidence can be checked without a network.

• ECL Timing, Availability, and Safe-State Semantics 1TIMING-SAFE-STATE-1 1.0, normative protocol, source on GitHub

  Time classes, clock skew, timeouts, and the safe state that an action class falls back to when part of the control layer fails.

• ECL Distributed and Long-Running Workflow Semantics 1DISTRIBUTED-WORKFLOW-1 1.0, normative protocol, source on GitHub

  Identities and causal order for actions that are delegated, retried, run by several agents, or left partly complete.

• ECL Evidence Lifecycle Protocol 1EVIDENCE-LIFECYCLE-1 1.0, normative protocol, source on GitHub

  Retention, legal hold, export, redaction, and destruction of evidence, each recorded as a new signed fact that leaves the history unchanged.

• ECL Extension and Registry Protocol 1EXTENSION-REGISTRY-1 1.0, normative protocol, source on GitHub

  How an extension is declared, versioned, and marked critical, and how registry entries are allocated.

Trust policy and offline verification

A verifier checks evidence under the checking party’s own trust policy, so that keys and policies carried with the evidence never vouch for it. These documents say what that policy holds and how evidence reaches a reader with no network path to its producer.

• ECL Trust Policy Profile 1TRUST-POLICY-1 1.0, normative profile, source on GitHub

  The trust policy that the checking party supplies: policy versions, key roles, principals, revocations, and limits on loading a policy.

• ECL Offline Verification Profile 1OFFLINE-VERIFICATION-1, informative guide, source on GitHub

  How an offline package lets a reader verify evidence with no network path to its producer or to any control plane.

Profiles

A profile tightens the core for a declared deployment or assurance context. It may add requirements and prohibit optional behavior, but it may not weaken a core requirement while claiming the same conformance scope, and it applies only to a claim that declares it.

• ECL Strict Failure Profile 1STRICT-FAILURE-1 1.0, normative profile, source on GitHub

  Forbids fail-open handling of the action classes in scope and requires that missing proof fail closed.

• ECL DCMP-2 HTTP Binding Profile 1DCMP2-HTTP-1 1.0, normative profile, source on GitHub

  DCMP-2 over HTTPS: framing, bearer principals, limits, signed outcomes, and failure classes.

• ECL Transactional Effect Profile 1TRANSACTIONAL-EFFECT-1 1.0, normative profile, source on GitHub

  Obligations on timing, privilege, and evidence for actions that take effect as transactions, and the evidence that each outcome leaves.

• ECL AuthZEN Binding Profile 1AUTHZEN-BINDING-1 1.0, normative profile, source on GitHub

  Adds a check by a policy engine reached through the OpenID AuthZEN Authorization API. The engine’s permit creates no authority to act.

Binding profiles

A binding profile states how ECL-1 works with another system. It claims no conformance with that system and no endorsement by its owners, and under each profile an action is released only on an ECL-1 admit for that exact request.

• ECL AARM Binding Profile 1AARM-BINDING-1 1.0, binding profile, source on GitHub

  An AARM control plane serves as the ECL-1 decision service or feeds one as a source of judgment inputs, and its receipts are bound to the ECL-1 evidence.

• ECL ACS Binding Profile 1ACS-BINDING-1 1.0, binding profile, source on GitHub

  A Guardian under OWASP’s Agent Control Standard becomes a decision source whose decisions reach an action only through a signed ECL-1 decision.

• ECL MCP Gateway Profile 1MCP-GATEWAY-1 1.0, binding profile, source on GitHub

  A gateway outside the AI system’s control sends each Model Context Protocol tool call for a decision and forwards only the exact call that an admit covers.

• ECL OpenTelemetry Evidence Export Profile 1OTEL-EVIDENCE-EXPORT-1 1.0, binding profile, source on GitHub

  Copies decisions and evidence into OpenTelemetry log records for monitoring tools, outside the decision path.

• ECL OAuth Authority Profile 1OAUTH-AUTHORITY-1 1.0, binding profile, source on GitHub

  Expresses one admit as one short-lived OAuth access token, tied to a key that the AI system does not hold.

Informative guides and records

These documents state no requirement of their own. Each obligation they describe is set, with its identifier, in the core standard or a normative companion that they cite.

• ECL Conformance Claims 1CONFORMANCE-CLAIMS-1, informative guide, source on GitHub

  The parts of a conformance claim and the limits of an assessment, gathered from the core standard in one place.

• ECL Deployment Profiles 1DEPLOYMENT-PROFILES-1, informative guide, source on GitHub

  Hosted, federated, sovereign, offline-edge, and air-gapped deployments, and the controls that the core standard requires of each.

• Issues on the normative textRecord, source on GitHub

  Questions about the normative text that needed a decision, each with its resolution.

The repository also holds guides for buyers, implementers, and assessors in its docs folder, among them the integration contract, which states what an agent, a tool server, or a gateway must expose, and must not hold, to be controllable.

Schemas, registries, and tests

The core standard lists the schema set, the registry set, the validator, and the conformance vectors among its companion artifacts, which are part of the normative assessment package at every level (Section 3.4). They do not override the core, and a contradiction between them and the text is an error to report.

schemas

JSON Schemas for every DCMP-2 message, EBMP-2 record, envelope, claim, register, assessment package, trust policy, and offline package.

registries

The compiled requirements, the semantic rules, the error codes, the extensions, the algorithm suites, and the terms, each with a stable identifier.

conformance

The conformance tests: positive and negative vectors with their expected results, signed fixtures, the incident replay scenarios, and the report format. The conformance page explains them.

formal

A TLA+ model of the runtime control invariant and a Tamarin model of DCMP-2 signing and binding. Why these models are used explains the ordering problems, assumptions, deliberately broken variants, reachability witnesses and recorded results. They check the modelled design, not an implementation.

web/verifier

The offline verifier for a web browser, and the TypeScript library and command line it is built on, in packages/ecl-ts.

packages/ecl-verify

The Python verifier and its command line, ecl-verify.

go/crosscheck

The Go verifier and its command line, ecl-verify-go.

Versions

Each document has its own version. A claim names the core version and the version of each companion it uses, as Section 7.7 of the standard requires. DCMP-2 and EBMP-2 messages also carry the version of their format in schema_version.

Requirement identifiers are never reused. A change follows the change process in the repository, and each new minor or major version has a public review window before it is published. Six release candidates, RC-1 to RC-6, preceded Version 1.0. None was published, and all are retired.

Citing ECL-1

Cite the version you used:

The repository also provides citation metadata for reference managers.

A conformance claim needs more than a citation. The conformance page lists what a claim must state.

Report a problem in the text

Open an issue in the repository for an error, an ambiguity, or a contradiction between documents, and give the requirement identifier where there is one. A confirmed error is corrected through the change process, as an erratum or in a later version. The working group page explains how to propose a change.

Open an issue on GitHubHow errata are published, current version