Security, stated plainly.

How G-14 keeps decisions with your people: separate credentials for each job, decisions that fail closed, evidence recipients can check under their chosen trust policy, and deployment where you choose. Below are the security model, our assurance program and this website’s demonstration, each labeled.

For a customer deployment, discuss your security requirements with G-14: identity and tenant boundaries, key custody, supported targets, evidence access and the enforcement path. Agree on the review scope and evidence before granting production access.

The security model

Fail closed: Missing or ambiguous authorization blocks a new action, and an outage grants no authority. A reply lost after submission stays unknown until reconciled.
Separate credentials for separate jobs: Writing policy, deciding, enforcing and emergency stop use separate credentials. Different credentials alone do not establish separate administration or host isolation.
Identity and authority: Signing in identifies an account. The server checks action authority separately, and the release contract defines the independent approvals a workflow requires.
Tenant boundaries: Tenant scope must be enforced in the database and through every sensitive path. A deployment review establishes the actual boundaries and the evidence of denial.
Single-use authority: Each approved action gets one authority, bound to that exact action and consumed when the gate releases it. A standing permit can cover multiple uses; each action still needs its own authority.
A separate stop: Emergency halt has its own control path, for one tenant or the whole deployment.
Evidence you can check: A recipient with the matching verifier checks signed records under a trust policy they choose: the issuers, keys, permitted uses and rules they accept. A record states what it covers; it does not establish that every step was captured or that an outside event happened.
Deployment model and custody: Agree on the deployment model, signing-key custody and data location before connecting customer systems. Models cover local, hosted, private execution, self-managed and sovereign or air-gapped operation. Review the deployment models.
Shared responsibility: Your system must accept agent actions only through the gate, and the agent must hold no other credentials that reach it. Establishing and testing that boundary is part of every integration.

Identity and access requirements

Use these requirements to review a deployment before granting production access. Local tests establish a bounded result; the customer connection, enforcement paths and operating evidence still need their own review.

Identity connections: The identity contract defines OpenID Connect. Before enabling a connection, establish its issuer, key rotation, authentication flow and allowed claims for the deployment. Sign-in is identity evidence; the server still decides authority.
Sessions and scoped keys: The session contract specifies opaque handles held on the server, idle and absolute expiry, rotation, logout and revocation. Scoped-key lifecycle controls are tested locally, including one-time display and hash-only listings. Production key management and custody require separate qualification.
Step-up and independent approval: High-consequence release workflows require fresh step-up evidence under the identity and release contracts. Step-up grants no release authority by itself. The release contract separates requesters from approvers; distinct role names alone do not establish independent people or administrations.
Tenant boundaries: A locally tested runtime schema uses forced row-level security for tenant-bound queries. Deployment review must also test caches, jobs, exports, logs and telemetry. Database tests alone do not establish isolation across those paths.
Attribution and revocation: The audit contract binds approval and release records to their actor, session, tenant and environment. Role changes must invalidate dependent grants under a declared policy. Propagation paths and timing require verification in the deployment.
Support and external policy: Support-access rules require customer approval, time limits and no release authority, and exclude impersonation. Under the AuthZEN binding, an outside policy decision can add restrictions but cannot replace G-14’s own authorization checks.
Analytics boundaries: The analytics design calls for privacy-preserving aggregates. Deployment review must establish what is collected, redacted and retained; it must not infer those controls from a design statement.

Public ECL-1 specification and verifier source

Published source. ECL-1 Version 1.0: the specification is published under CC BY 4.0. Browser verification is available here, and Apache-2.0 verifier and test sources are public in the pinned repository. A recipient must choose an applicable verifier version and trust policy. Publication is not a conformance or independent-assessment claim.

Public source observed on 30 October 2026: ECL-1 Version 1.0 source and tests on GitHub (new window). Public ECL-1 tools check ECL-1 action evidence; other platform records have their own contracts. This source observation does not change the assessment or key-custody claims below.

Our assurance program

Company-level assessment and assurance items, separate from the demonstration’s controls.

Company assurance items, with their current status. Content reviewed 1 November 2026.
Control	Status	Detail
SOC 2 control assessment	Self-assessed	G-14 has assessed its controls against the SOC 2 Trust Services Criteria. This is our own assessment, not a third-party SOC 2 audit.
Penetration testing	Program active	G-14 runs penetration tests with security-focused AI models from Anthropic and OpenAI.
Bug bounty	Started	Our bug bounty program has started. Email security@g14.ai for testing scope and reward terms, or to report a vulnerability.
Published incidents	Commitment	We will publish our own incidents on this page, with what happened and what changed.

This website’s demonstration

When connected, the local example changes fictional records using public test keys. Its limits are not a status table for the whole G-14 platform. Security, key custody and assurance for a customer deployment must be established for that deployment.

Controls and limits of this website’s local record-update demonstration when connected. Content reviewed 31 October 2026.
Control	Status	Detail
Decision before action, fail closed	In place	The gate releases an action only after a valid signed allow decision, called an admit. If it cannot reach the decision service, it refuses the request with reason dependency-unavailable.
Single-use, scoped, time-boxed authority	In place	Each allow decision carries single-use authority for one exact action within a validity window. A standing permit can cover multiple uses; the gate consumes a separate authority when it releases each action.
Amount ceilings in a permit	Not in pilot	The pilot limits records, fields, requested uses and the time window. It does not enforce an amount ceiling such as credits under $50.
In-flight holds for approval	Not in pilot	The gate decides admit or deny before a change runs. It does not hold an admitted action for an employee’s or a customer’s approval.
Separation of planes and database roles	In place	Separate credentials are used for the gate, decision service, permit management and emergency stop. The gate can append evidence, and observers can read it. Different credentials alone do not establish separate administration or host isolation.
Stop-work and revocation	In place	A tenant-wide halt and per-permit revocation, each recorded by the emergency plane. Proposals during a halt are denied, each with a signed record. The pilot does not provide a signed export of the halt and release themselves.
Signed record of who issued a permit	Not started	Permits are written on the policy plane with a reason, and every decision names the permit. The issuance itself is not yet a signed record you can export.
Customer-held signing keys	Not started	This site runs on the pilot’s public deterministic test keys, so verification does not establish origin or private key custody. A customer deployment would need keys generated for it and a customer-chosen trust policy.
Conformance claim for this backend	In progress	The demonstration backend targets Level 1, Class A, for one action class: records.update. Class A means separated control powers under one operator, not independent assessment. This is a target, not a published conformance claim. It uses public test keys. Any future claim must identify its scope and publish the required results and verifier output.

When this demonstration’s decision service is unavailable

An outage grants no authority. If the gate cannot obtain a valid decision, it does not release the action. Where it returns a signed dependency-unavailable refusal, you can check that actual bundle on the verify page. A reply lost after submission leaves the outcome unknown, not proven refused. Your receiving system must accept the agent’s changes only through the gate; testing that boundary is part of the integration.

Saved bundles can be checked offline with the open ECL-1 verifier and the matching trust policy, without calling G-14. The result depends on the bundle being complete and intact, the applicable verifier version and policy history, and the keys the trust policy names. Whether those keys are still trusted today is a separate question from checking the record under its historical policy.

For your risk committee

Answers for this web demonstration, not a blanket claim about every customer deployment or product.

Where decisions are made and enforced: The decision point checks the proposal against the permit. The gate enforces the signed decision before a change reaches your system of record. An integration must keep that system’s credentials away from the agent and accept the agent’s changes only through the gate.
What an outage does: Without a valid decision, the gate releases no new action. If a reply is lost after an action was submitted, treat the outcome as unknown and reconcile it before you retry. Work the agent would have done falls back to people until the gate is back; plan for that as you would for any control that fails closed.
Who changes the rules: Holders of the policy-plane credential write permits. Holders of the emergency-plane credential stop work and revoke. The two are separate credentials, and neither can act as the agent.
Responsibilities before deployment: Before a customer deployment, name who owns the action register, who may issue or revoke permits, and who reviews the evidence. This demonstration does not establish your organization’s separation of duties or audit process.
This demonstration’s limits: No amount conditions or in-flight approval holds; no signed export of permit issuance or customer-held signing keys here. Each item is listed above with its scope and status.

Data handling on this site

Starting a room: No account is needed. Choosing “Issue permit and start” asks the backend to create a demonstration room, seed a fictional record and issue the displayed permit scope for a scripted demonstration agent. A lost reply can leave the outcome unknown. Loading a page, selecting a workflow or inspecting evidence does not issue a permit. Nothing in the room asks for your name or email. The room id appears in addresses your browser requests, so it can appear in ordinary request logs. Decisions are retained as signed demonstration evidence in the backend.
Room closure and evidence: A room becomes eligible to close eight minutes after creation if it has no decisions, or after thirty minutes without a room request. Views and bundle downloads reset only the request-inactivity clock. Busy operations finish before cleanup. Signed demonstration evidence persists separately in the backend evidence store. Session closure and these deadlines do not promise evidence deletion or retention.
The workflow planner: Submitting sends your draft to this site, which builds the PDF and returns it. The generator has no draft-saving or forwarding step; that is not a deployment-wide promise about request logs or retention. A prefilled workflow name can appear in the URL, browser history and request logs. Do not enter personal or confidential information. See privacy.
Analytics: No analytics scripts or cookies are set by this site. Fonts are hosted on this site. No third-party analytics or ad trackers. Requested addresses can contain a room id or prefilled workflow name and can appear in ordinary server request logs. See privacy.
Theme preference: Stored in your browser only, if you set it.

For procurement

Legal entity: G-14, Inc., Florida.
Security contact: security@g14.ai
Assurance status: Self-assessment against the SOC 2 Trust Services Criteria, AI-assisted penetration testing and a bug bounty program. Read our assurance program for the scope and current status of each.
Infrastructure and outside services: G-14 owns its servers and the infrastructure inside the racks. Confirm the data-processing terms and provider list for your deployment with G-14 before sharing customer data.
Data location: Data location and residency terms are set in your deployment agreement.
Service levels: Service levels, support and response commitments are set in your agreement.
Early-access terms: Early-access scope, pricing and terms are set in a separate written agreement.
Site assets and tracking: Fonts are hosted on this site. No third-party analytics or ad trackers. Requested addresses can still appear in ordinary request logs.

Reporting a problem

Report a site vulnerability to security@g14.ai. For ECL-1 or verifier issues, follow the security-reporting instructions on the standard’s technical site (new window).