ECL-1: External Control Layer Standard

What ECL-1 is and what it guarantees

ECL-1 describes a control layer that stands outside an AI system, between what the system proposes and what takes effect. The layer decides whether each consequential action may go ahead, applies that decision before the action takes effect, and records evidence of it.

ECL-1 opens with the guarantee that a deployment provides when it conforms under a mediation claim, which covers either every reachable consequential action of the system or only named classes of action. The guarantee concerns the governed AI system, meaning the AI system whose actions the claim governs. That includes its models, the runtime that carries out their output, and the tools, memory stores, credentials, and processes that the runtime can use or change.

Each action that the claim declares in scope crosses an enforcement boundary that the governed AI system cannot bypass, under a decision that it cannot change. A failure that leaves the action without the proof it requires ends in denial, restricted mode, or halt, and the action does not go ahead. Such failures include an integrity failure, an ambiguous policy, and a decision service that does not answer. Each decision leaves tamper-evident evidence that a third party can check and, from level L2, verify offline outside the main control plane.

The guarantee holds only within the boundary, level, independence class, and trust assumptions that the claim states, and only as far as the claim’s assessment establishes it. At L1, the absence of a bypass rests on the claimant’s documented method for finding paths to an effect and on the interception points it has tested. From L2, it also rests on the assessor’s own attempts to get around the enforcement point. A claim about one component or one profile does not provide the guarantee. The standard states the guarantee in full at its opening, in The ECL-1 Guarantee.

The specifications page describes ECL-1 alongside AARM, OWASP’s Agent Control Standard, and NVIDIA OpenShell. ECL-1 will be added to the gap-by-gap comparison once someone outside G-14 has done the mapping.

The four levels

A conformance claim is made at one of four levels. The level sets how independent the control layer must be of the AI system and its operators, and how far an assessment must go to establish the claim.

The conformance page explains the independence classes, the kinds of claim, the tests, and how a claim is declared and listed.

The documents

ECL-1 Version 1.0 is a set of documents around one core standard. Reading copies are on this site. GitHub repository: coming soon.

Start here, by reader

ECL-1 is written for organizations that deploy AI systems able to take consequential actions, and for the people who check those systems and connect them to a control layer. Each uses different parts of the document set.

Buyers and operators

Read the guarantee and the section on reading a claim, which shows what a public claim about ECL-1 must state. The repository’s docs folder (coming soon) has a guide for buyers, and the procurement page has contract language.

Assessors

Start with the checklist in Section 11 and the assessment each level requires, then the evidence format, EBMP-2, with its trust-policy model, and the verifier with its sample evidence.

Integrators

Start with the functional requirements in Section 6, then the conformance tests with their expected results, the verifier, and the guide for implementers in the docs folder (coming soon).

Agent and tool builders

Start with the integration contract (coming soon), which states what an agent, a tool server, or a gateway must expose, and must not hold, to be controllable, then the decision messages of DCMP-2 and the conformance tests.

Formal-methods reviewers

Start with the TLA+ and Tamarin models (coming soon), their recorded results, bounded configurations, deliberately broken variants, and explicit limits. They check rules of the design and do not prove an implementation.

Version 1.0

Version

ECL-1 Version 1.0, release ECL-1-1.0, publication date to be announced. It states 628 requirements and has 953 conformance vectors, each a test case with its expected result.

Documents

The core standard, seven protocols, ten profiles, and three informative guides, with the JSON Schemas, registries, conformance tests, and formal models. The specification page gives the version of each.

Download

Release package, checksums and SBOMs (coming soon)

Status

ECL-1 Version 1.0. G-14 certifies nothing, and no certification program or certification mark is authorized. Implementers declare their own conformance claims, and the implementers registry lists them as self-declared.

Earlier candidates

Six release candidates, RC-1 to RC-6, preceded Version 1.0. None was published, and all are retired.

Next versions

Changes follow the change process in the repository. Each new minor or major version has a public review window before it is published, 30 days for a minor version and 60 days for a major one. Errata and patch versions follow the change process. Public review

Licenses and the patent pledge

The specification text and its documentation are under the Creative Commons Attribution 4.0 license (CC BY 4.0). The machine-readable files and the public code are under the Apache License 2.0. They include the schemas, the registries, the conformance tests with their vectors and fixtures, and the offline verifier.

G-14, Inc. makes a royalty-free, worldwide, non-exclusive commitment not to assert its essential patent claims against any implementation of ECL-1 Version 1.0 and its companion specifications at their 1.0 and 2.0 versions, to the extent that the implementation conforms to their normative requirements. An essential claim is one that implementing a normative requirement necessarily infringes, because no commercially and technically feasible alternative exists. The pledge does not cover enabling technologies, informative text, examples, reference or sample implementations, or techniques of G-14’s platform that the normative text does not require. It ends for any party that asserts a patent claim against an implementation of ECL-1, or against G-14 over ECL-1. Contributors make the same commitment for their contributions.

The full text of the pledge, in PATENTS.md, governs. G-14 has patents pending on related technology.

• LICENSE-CC-BY-4.0, for the text
• LICENSE, the Apache License 2.0, for the code and the machine-readable files
• PATENTS.md, the patent pledge
• LICENSING.md, which license covers which part of the repository

G-14’s own implementations of ECL-1 are its platform. They are not part of the standard and remain proprietary.

How ECL-1 is maintained

G-14, Inc. maintains ECL-1. It hosts the repository, provides the editors and the chair, runs public review, and publishes releases and errata. The ECL-1 Working Group develops the standard in the open, and anyone can join it for free. The editors propose changes, the working group discusses them, and the editors decide by rough consensus and record the reason for each decision.

G-14 keeps ECL-1 versioned separately from its products and states the known limitations of each version. The governance page lists G-14’s interests.

How the working group worksThe charter on GitHub, current version (coming soon)

The six control layers

Of the six control layers, Decision, Authority, Enforcement, and Provenance act on each action, while Verification and Fleet keep the controls working over time.

Decision

Returns admit, deny, hold, or challenge under versioned policy. Admit corresponds to a permit on the architecture page, and a challenge asks for specified evidence or input before evaluation can finish.

Authority

Issues or validates bounded, revocable authority to act.

Enforcement

Applies the outcome before execution, with a separate emergency halt.

Provenance

Records tamper-evident evidence of each decision and action.

Verification

Detects control drift and triggers restricted mode or halt.

Fleet

Distributes policy and revocations and can quarantine instances, even in a fleet of one.

The control layer must be architecturally independent of the AI system, so that no single credential, role, privilege domain, or trust root is enough to change both the system’s behavior and the control outcome.

The one-way rule for decision inputs

ECL-1 puts each input to a decision in one of three classes.

Verifiable

A value that the AI system cannot write by any route, including through its tools or through actions it was allowed to take. The decision service obtains it from its source, or checks it by the source’s signature, instead of taking it from the request. Examples are a system of record, a budget ledger, a signed record from an independent witness, and an instruction that a person confirms to the control layer with a credential the AI system does not hold.

Actor-supplied

Anything the AI system produces or can write, including its own statements about an action’s purpose, its authority, or an approval. An input that arrives with the request, or through another channel the AI system can write, counts as actor-supplied unless the decision service can confirm its source.

Judgment

The output of a model or detector about meaning or risk, such as a score of intent, drift, anomaly, or risk, whoever runs it.

Outcomes run from least to most strict as admit, challenge, hold, and deny. An admit must follow from the policy applied to the verifiable inputs alone. Judgments and actor-supplied inputs can make the outcome stricter than the one that policy gives, but never less strict. A high risk score can turn an admit into a hold, but a favorable score, or the AI system’s report that a person approved, cannot turn a hold into an admit or widen what an admit allows. An input that is missing, late, or malformed cannot support an admit, and an action whose class requires that input is not admitted.

The claim’s register declares the inputs that decisions on each class of action may use, with the class and source of each, and the decision service consults no other input. Each decision records its inputs, with the class of each, whether it was available, and its effect on the outcome. A reviewer or an offline verifier can then check that no admit rested on a judgment or on the AI system’s own word, though not whether the decision service consulted an input it did not record.

What counts as consequential

An action is consequential if it:

• changes external state,
• discloses, exports, or transforms non-public data outside the agent’s isolated execution context,
• creates or authorizes financial, legal, contractual, identity, infrastructure, network, or physical effects,
• expands authority, execution reach, or access to tools and resources, or
• invokes an external service, system, or actuator at material cost, obligation, or exposure to the operator.

A statement that a conversational system sends in the organization’s name about a price, a term, a policy, eligibility, or a legal or health matter, on which the recipient may rely, is also consequential. It is released only if it matches approved reference content or an authorized person approves it.

An action counts as non-consequential only if it passes all of the standard’s exclusion tests, and a deployment whose scope is uncertain is treated as in scope until a documented review concludes otherwise.

How a conformance claim is built

Each claim defines its System of Interest (SoI) and declares whether it covers all reachable consequential actions of the SoI, only named action classes, or one component or profile. Its Consequential Action Register lists each action class with its classification, rationale, affected resources and data, enforcement class, decision inputs, and any approval threshold. Its Negative Boundary Annex lists excluded effect channels, tools, resources, and shared surfaces, and known alternate paths to external effect. An effect path that is neither in scope nor in the annex makes the claim invalid.

A public claim states at least the SoI, level, claim status (full conformance, conditional conformance, or assessment-only), claim class, achieved independence class, core and companion versions, any profile, the date of the latest assessment or evidence refresh, and material limitations.

Conformance levels and independence classes

Levels run from L1 (Foundational) to L4 (Critical Infrastructure), each including the requirements of those below it. The required level is the highest of the scores for autonomy, data sensitivity, and action consequence, and from L2 the assessment must be independent and include negative tests.

Class A, minimum at L1

Same-operator separated controls, which a public claim must disclose.

Class B, minimum at L2 and L3

Control approval and evidence verification both in a separately administered trust domain that the AI system and its ordinary operators cannot change on their own.

Class C, minimum at L4

Class B, with both functions held by a named, externally independent authority.

Hard and soft enforcement

Soft enforcement runs in a layer of the host platform that the AI system cannot modify, disable, or bypass but that shares the platform’s trust root, such as the operating system, middleware, a gateway, or a service. Hard enforcement relies on a separate trust boundary that is materially harder to compromise than the AI system, such as a trusted execution environment, a hardened hypervisor path, or an out-of-band gateway. Action classes with L4 consequence or an irreversible physical effect, and those for which a sector requires an independent actuation boundary, must use hard enforcement. Other classes may use soft enforcement if the register records the reason and the residual risk.

A component that the AI system can rewrite, disable, or bypass is an enforcement point of neither kind. That rules out a hook in a process, container, or account where the AI system can run code, or one that the system can start, stop, or reconfigure. Such a hook can still pass a request, or another system’s decision, to the decision service, and an enforcement point outside the AI system’s reach then applies the outcome.

Consequence, approval, and change controls

• The register states the largest effect that each action class could have in an hour and in a day if every action were admitted. From L2, each class with financial, legal, data-disclosure, communication, identity, infrastructure, or physical consequence has a budget, enforced outside the AI system and counted across all of the system’s sessions, workflows, and instances. An action that would exceed the budget is denied or held.
• At L2 and above, each admit of a financial, legal, identity, infrastructure, or physical action needs at least one verifiable fact about the action’s target or subject. That fact comes from a system of record, an independent witness, or an authenticated outside party.
• Approvers decide on a presentation of the action and of the verifiable inputs behind the decision, and the evidence records what they were shown and when. An action at or above a declared approval threshold is not admitted until as many authorized people as the threshold requires have approved it.
• From L2, an approval given sooner than a declared minimum review time does not release the action. At L3 and L4, each approver’s approval rate and review times are also measured, and a declared anomaly leads to a review of that approver’s decisions.
• Declared detections, such as monitoring alerts, anomaly signals, and reports from people outside the system, bring a hold, restricted mode, quarantine, or halt. From L2, the response takes effect without anyone’s action and within the declared revocation time, and only a recorded control action lifts it.
• Disabling or bypassing a control, or setting it to approve automatically, needs another person’s approval, an expiry, and a signed record. A control found off or bypassed without such a record counts, from L2, as a critical verification failure.
• Changes to the policy, the register, the tools the system can reach, enforcement settings, the trust policy, and detection responses need review by someone other than their author before they take effect. From L2, changes to the AI system’s model, instructions, and tools are also versioned, and each decision request names the version of the AI system that requested the action.

Evidence an assessor can check

Each mediated action produces a signed, tamper-evident evidence bundle recording the actor, the policy and authority used, the inputs the decision rested on, the outcome, and the timing, kept for at least 12 months. The keys that sign evidence are listed in an inventory and kept out of the AI system’s reach, and each key signs for one role only, such as the decision point or the enforcement point.

A verifier checks a bundle offline under the checking party’s own trust policy and reports one verdict: verified, invalid, incomplete, or current trust failed. The last means that the bundle would otherwise verify but a signing key is no longer accepted, for example because it was revoked. A signed record shows what its producer asserted. An effect counts as corroborated only when a separately keyed observation binds that terminal event and attempt, with the signature and causal checks established.

Reading a claim about ECL-1

Not valid

“ECL-1 certified.” No certification program or certification mark is authorized.

Not valid

“ECL-1 compliant,” with nothing more. A claim must include the minimum public claim statement.

Not valid

“ECL-1 ensures compliance with [a law].” Conformance must not be represented as legal compliance or sector certification.

Valid

The standard’s own example: “ECL-1 Version 1.0, L2, assessment-only, bounded-action-class-mediation, Class B independence, assessed 2026-11-16 for the declared SoI using DCMP-2 v2.0 / EBMP-2 v2.0, with production-equivalent=false explicitly disclosed.”

The conformance page lists what a public claim must state and how an implementer is listed.

What ECL-1 leaves to other tools

ECL-1 standardizes one layer, the decision, authority, enforcement, and evidence around each consequential action. It leaves other functions to other tools by design and states how each connects. No connection changes the guarantee, because an admit still rests on policy over verifiable inputs, and a failure that removes required proof still ends in denial, restricted mode, or halt.

Judging what an action means

Intent alignment, semantic drift and anomaly detection, risk scoring, and the analysis of conversations and sessions connect as judgment inputs, which can only make a decision stricter. They can also connect as declared detections that hold or stop the affected actions.

Monitoring and evaluation

Observability and security monitoring tools can receive ECL-1’s decisions and evidence as OpenTelemetry log records, and an alert that shows wrong behavior comes back as a declared detection. Model-quality evaluation stays outside runtime control, and its results can inform the policy and the register.

Components that decide or enforce

Sandboxes, guardian agents, tool gateways, and policy engines can act as decision sources or enforcement points under ECL-1’s rules. A sandbox can be the enforcement point for the actions it mediates if it meets ECL-1’s enforcement requirements and fails closed. A guardian’s judgment about meaning or risk is a judgment input, and a policy engine’s permit does not by itself create authority to act.

Binding profiles state how ECL-1 works with particular systems. Each applies only to a claim that declares it, and a profile claims no conformance with the other system and no endorsement by that system’s owners. Under each profile, an action is released only on an ECL-1 admit for that exact request.

AARM-BINDING-1

An AARM control plane either 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.

ACS-BINDING-1

A Guardian under OWASP’s Agent Control Standard becomes a decision source whose decisions reach an action only through a signed ECL-1 decision. If the Guardian does not answer, the action is not released.

MCP-GATEWAY-1

A gateway outside the AI system’s control sits between it and the Model Context Protocol (MCP) servers it uses, sends each tool call for a decision, and forwards only the exact call that an admit covers.

OTEL-EVIDENCE-EXPORT-1

Decisions and evidence are copied into OpenTelemetry log records for monitoring tools, outside the decision path, so that an export failure does not by itself change a decision or delay an action.

OAUTH-AUTHORITY-1

One admit is expressed as one short-lived OAuth access token, tied to a key the AI system does not hold, so that a resource server that already accepts OAuth tokens can enforce it.

AUTHZEN-BINDING-1

A policy engine reached through the OpenID AuthZEN Authorization API adds a check to a decision, and its permit creates no authority to act.

ECL-1 defines the runtime-control layer, for use alongside management, legal, safety, and sector controls. It is not by itself legal or sector-safety certification, model-quality assurance, or organization-wide AI governance, and conformance is not proof of liveness, performance, or business continuity. The controls of IEC 62443 or ISO 26262 are co-normative where a deployment profile claims conformance in those sectors.

How ECL-1 is tested

The conformance tests are a shared corpus with a passing and a failing case for each part of ECL-1’s message, claim, and assessment formats and for each of its checking rules. Three items that cannot be tested on their own are left out, each with a stated reason. The conformance page describes the tests and how to run them.

An incident replay suite turns entries 1, 4, 14, 17, 22, 23, 24, 25, 27, and 29 of the record into 10 test scenarios. Each scenario configures a deployment as ECL-1 describes and replays its entry as a timed series of steps, with some steps added that are not in the entry. It states the outcome each step must have, such as a purchase that waits for the user or a code freeze enforced outside the agent. Each scenario must also catch at least one deliberately weakened control plane, such as one that admits actions while the decision service is down or lets a risk score admit an action.

A scenario simplifies its entry and is not an account of the incident, and a run shows only how a deployment configured as declared behaves on the replayed steps. Other control systems, such as an AARM control plane, a Guardian under OWASP’s Agent Control Standard, or an OpenShell sandbox, can run the scenarios through an adapter, and the suite reports no result for any of them.

G-14 runs the corpus against its own implementations in Python, TypeScript, and Go, which reach the same results. The TypeScript, Python and Go command-line verifiers are part of the ECL-1 document set. G-14 is responsible for all three, so their agreement is not evidence of an independent implementation. A security review by people outside G-14 has not yet taken place.