Keep the tools and systems you use. Add control where AI changes them, and evidence where an outside reader needs to check what happened.
G-14’s own AI agents build connector and adapter changes as Missions: bounded jobs with their own permissions, workspace and evidence. They work inside the platform, under the same limits and review as every other change.
Your team reviews and admits each one. Production access and supported targets are agreed with you.
In supported local deployments, the action check doesn’t require a hosted round trip. Current authority, freshness, expiry and revocation rules still apply. Receipt delivery can happen asynchronously.
Tell us your environment, and we’ll confirm the supported release.
TypeScript, Python and Go verifiers, plus the one in your browser, check ECL-1 receipts offline under the trust policy you choose. They check records; they don’t produce them.
Use this site’s ECL-1 verifierObserve-only. Connect allowed source, registry, build and runtime observations through the secure import broker, pinned to exact versions.
Read access never becomes edit, merge or deployment authority. Unobserved objects and missing delivery links stay explicit.
Missions and candidates. Declare intent, work from an authorized baseline, reconcile what actually changed, and submit a frozen candidate for acceptance.
Work done outside G-14 carries a different provenance claim; importing it can’t invent a history. Accepting a change is a separate step from merging or releasing it.
Local enforcement. Enforce the runtime authority’s decision on your side before the operation reaches its target. ECL-1 defines this runtime-edge contract.
You own the agent’s identity, the target’s credentials, and closing every other path to the target. Saying the gate is the only path doesn’t make it so. Test it.
Portable evidence. Export the declared evidence with its subject, issuer, method, status and limits. Check the applicable format under your own trust policy.
A valid signature is not permission to act, proof of an unobserved result or a guarantee of complete capture. Different record formats need their own verifiers.
A tool’s label, a model’s structured output or a field that says “approved” never counts as a decision. Only an authenticated decision does. Read the Mission and authority model.
The model proposes. The proper authority decides. Your receiving system must accept the agent’s effects only through the agreed boundary.
These responsibilities cannot be discharged by a green dashboard or an adapter’s self-report.
Name the actor, tenant, environment, exact action and intended target. Identify who owns the target and who may issue, change, review or revoke authority. Each agent acts under its own identity; delegation can keep or narrow authority, never widen it. Separate the credentials for policy, decisions, enforcement and emergency stop.
Bind each business check and readiness signal to its authoritative source, action and expiry. Missing or conflicting answers stay unresolved. The acting agent cannot invent satisfaction of its own requirement.
Separate no-effect preparation from dispatch. Require affirmative authority and satisfied release conditions before reaching the target. Keep credentials and alternate access paths from defeating the gate.
Distinguish released, dispatched, acknowledged, observed, failed and unknown. Define concurrent use, retries, expiry and recovery. A lost reply is not success or proven refusal; never blindly replay an unknown outcome.
Agree what is captured, who signs it, who may receive it and how the reader trusts those identities. Key custody, trusted timing, status and completeness need their own evidence. Never invent a terminal event.
Bind the actual delivery path, not just a hash supplied by the caller requesting approval. Every join names its subject, issuer, environment, method, time and exclusions.
Join the admitted source and exact candidate to the build environment, locked dependencies, provenance and resulting bytes. A passing build does not authorize release.
Join the complete release set, configuration, policy and versioned inputs to the proper decision and target. Authorized dispatch differs from observing someone else’s deployment.
Keep the target’s acknowledgment separate from runtime observation and effect observation. State when exact runtime identity cannot be measured.
Check issuer, key purpose, schema, trust and status policy, subject, environment and freshness. An old receipt, or one for another candidate, cannot answer the current question.
Declared, deployed, acknowledged, observed and effect-observed are separate claims, each with its own evidence. See the five claim definitions.
Two example integrations, described as contracts.
An agent proposes a tool call to a tool service, such as an MCP server. The runtime authority evaluates it and obtains a person’s decision where required. The host enforces the bounded result before calling the tool, then reports the actual outcome.
A production change waits for the exact qualified candidate, approved environment and applicable conditions. The deployment record, acknowledgment and separately observed runtime remain distinct.
ECL-1 defines bindings for AuthZEN, AARM, OWASP ACS, MCP, OpenTelemetry export and OAuth authority. Each binding has its own requirements, and each deployment’s conformance is assessed on its own.
Tell us what you run, what AI may change, who should authorize it and what you need to prove. Include deployment and data-custody constraints, and tell us which CLI or SDK interfaces your team needs. Describe the system without sharing credentials, customer data or private source.
Authentication, supported adapters and deployment details are agreed for your environment.
Read the ECL-1 explanation or the specification on externalcontrollayer.ai (new window).
