The rulebook for what an AI agent may do, before it does it.
G-14 wrote ECL-1, the External Control Layer Standard, so that companies can let AI agents act on real systems and still show, with evidence, what each agent was allowed to do. It is an open standard: anyone can read it, build to it, and check a system against it.
ECL-1 Version 1.0. Specification under CC BY 4.0; verifiers and test suites under Apache-2.0.
An AI agent that can act can act wrongly.
An agent that can change a record, move money or send a message on your behalf will sometimes propose the wrong change. It may misread an instruction, be misled by something it read, or simply be mistaken. Instructions can guide an agent, but they cannot by themselves enforce permission. The check must sit outside the agent.
Industry learned this long ago. Dangerous work waits for a permit that a person issues, and the power is cut by a lock outside the machine, so the machine’s own controls cannot switch it back on. ECL-1 applies the same discipline to AI agents.
Seven things a conforming deployment must do.
For the actions a deployment declares in scope, ECL-1 sets out one guarantee in seven parts.
No hidden way around the gate.
Every action in scope passes through an enforcement point before it takes effect, no undisclosed route goes around it, and the AI system cannot rewrite, switch off or bypass it.
The agent cannot change the decision.
A control layer outside the AI system decides. Anything that comes from the agent itself, and any judgment about meaning or risk, can only make a decision stricter; it can never be the reason an action is allowed.
When in doubt, nothing goes ahead.
If required proof is missing, a record fails its integrity check, a rule is unclear, or a service the decision needs does not respond, the action is refused. Depending on the failure, only that kind of action is restricted, or the whole deployment stops.
Permission is narrow, temporary and revocable.
Each permission is tied to a specific transaction, expires, and can be withdrawn. Passing it on can keep it the same or narrow it, never widen it. At the moment of release, the gate checks again that the permission is still good.
Every decision leaves tamper-evident evidence.
Each decision records what it rested on. From Level 2, that evidence is a signed bundle a recipient can verify offline under a trust policy they choose, without relying on the operator’s systems. That policy names the issuers, keys, permitted uses and rules the recipient accepts.
The claim says exactly what it covers.
A conformance statement lists which actions and routes it covers, which it leaves out, the level it meets, its independence class and how it was assessed, so no one mistakes a partial check for full coverage.
The controls stay true in operation.
Revocation takes effect within a declared time, declared alarms hold or stop the affected actions, an emergency stop works without the AI system’s cooperation, and any change to the controls is reviewed by a second person.
These seven core requirements summarize ECL-1’s control model. The full Version 1.0 source contains 628 compiled requirements; a deployment’s claim must identify which apply within its declared scope.
The guarantee applies only within the boundary, level and trust assumptions a deployment declares, and only as far as its assessment has shown. A standard on paper cannot stop an agent by itself: the deployed system has to show that every route to an action goes through the gate. A product that claims to be one ECL-1 component does not, on its own, give you the guarantee.
The same rules, wherever an agent acts.
ECL-1 does not care what kind of work the agent does. It cares whether an action has consequences: whether it changes something outside the agent; moves or exposes private data; creates a financial, legal, contractual, identity, infrastructure or physical effect; widens what the agent can reach; or calls an outside service in a way that creates real cost or obligation. If it does any of these, ECL-1 applies.
At very high volume
Whether an agent fleet proposes a handful of actions a day or a very large number every second, the rule is the same for each one: decided before it runs, with its evidence recorded when it is decided. ECL-1 sets no speed requirement of its own. Each deployment sets its own time limits for decisions, and anyone claiming a speed must say exactly what it was measured on.
Regulated records, including pharmaceuticals
Where every change to a record must be authorized in advance, an agent’s proposed change waits for a permission that covers it. Each decision leaves tamper-evident evidence of the permission and inputs it rested on, and from Level 2 a signed bundle an auditor can verify offline. That evidence supports a company’s wider compliance program; ECL-1 does not itself claim to satisfy any regulation.
A bank authorizing a payment
A payment the agent proposes is refused unless a permission covers it. From Level 2, ECL-1 also requires a hard cap on the number, rate or total value of the actions it allows over a set period, enforced outside the AI system and counted across every session, workflow and running copy of the agent. Anything that would go over the cap is refused or held, so many small payments cannot quietly add up to a large one.
These are requirements of the standard. G-14’s demonstration on this site covers record changes only. It does not enforce amount ceilings or consequence budgets.
Conversational systems
A public question-answering bot with no tools, no access to private data and no way into other systems may be outside ECL-1. So may an assistant that only prepares drafts a person reviews and sends separately, although the system that does the sending is still covered. A conversational system is inside ECL-1 once its output can disclose private data, set off or advance an action, widen what it can reach, or state a price, term, policy, eligibility, legal or health matter in the company’s name. A statement of that kind must be checked against approved content, or approved by an authorized person, before it goes out.
A register of what the agents can actually do.
Every conforming deployment publishes a register of the actions its agents can actually reach, checked against their real tools, permissions and connections. For each kind of action it says whether it has consequences, when a person must approve it, and the largest total effect the system could have in one hour and in one day if every request were allowed. A route the register leaves out must be listed as excluded; leaving it unlisted is a defect in the claim.
ECL-1 specifies control requirements. It does not supply model tests, content filters or monitoring tools. A deployment can connect those tools to its control layer: a risk score can make a decision stricter, sandboxes and gateways can enforce decisions, and monitoring can receive the evidence.
Four levels, each checked more independently.
| Level | For | How it is checked |
|---|---|---|
| L1 Foundational | Early-stage or lower-impact agent workloads | Annual internal assessment, with a signed attestation and evidence matrix, by a reviewer who is not the main implementer. |
| L2 Standard | Regulated or enterprise workloads with consequences | Independent assessment at least every two years, with yearly updates, including hands-on tests that try to bypass the gate, force unsafe failure, exercise the emergency stop and probe excluded routes. |
| L3 Advanced | High-autonomy, multi-agent or high-impact workloads | Everything in L2, plus a yearly exercise that tries to break the controls and an independent test of the architecture under pressure. |
| L4 Critical infrastructure | Critical infrastructure and safety-critical workloads | Assessment by a government body, regulator or formally recognized independent authority where applicable, with no open critical findings. |
Every level includes the levels below it. The public Version 1.0 source contains 628 compiled requirements and a documented shared corpus of 953 test vectors. Its Python, TypeScript and Go verifiers must agree on all of them.
Written by G-14. Open to everyone.
G-14 wrote ECL-1 and maintains it. The specification is published under CC BY 4.0; the public verifier and test sources use Apache-2.0.
G-14’s patent pledge covers its essential patent claims for anyone implementing ECL-1 Version 1.0’s normative requirements, royalty-free and on the pledge’s terms. Read the patent pledge on GitHub (new window).
ECL-1 is the contract for G-14’s runtime edge and portable action receipts. Explore the wider G-14 platform or discuss an observe-only connection. Like anyone else’s, a G-14 deployment would need its own scoped assessment before it could claim to conform.
Read this demonstration’s security limits or inspect what verification establishes.
Read the standard itself.
Read the specification and use the browser-verifier page on the standard’s own site. Inspect the pinned Version 1.0 verifier and test sources on GitHub. Each technical link names its destination and opens in a new window.
View the fictional dispute example