Trust & security
Exactly as much as we can prove.
Security reviewers shouldn't have to decode marketing. This page states what is true of Aion today, what the enterprise pilot adds as it ships, and the claims we refuse to make early. Every material claim carries a status from the capability matrix and a named evidence owner.
True today.
The operating boundary of Community Aion and of this website, as they run right now.
Community runs inside one local OS-user boundary
AvailableThe CLI and local dashboard run on your host; the API binds to loopback only; workspace state lives on your disk; AI-provider secrets use the OS keychain. This is a local tool boundary, not an enterprise isolation boundary — and we say so.
Evidence owner: Vendor
Your code stays in your repository
AvailableAion works through branches, commits and pull requests in repositories you explicitly register, using credentials you already hold. Prompts and selected context leave your machine only toward the model provider you configure.
Evidence owner: Customer
The model you choose is a data destination
AvailableClaude by default, Codex, or a custom provider — whichever you configure receives prompts and code context. Choosing the provider, and any data-processing agreement with it, is yours.
Evidence owner: Customer
Consequential actions wait at human gates
AvailableMerge and deploy default to human approval; a local owner may enable supported local automation. Every phase transition is recorded in the local cycle trail.
Evidence owner: Joint
Secret shapes are scrubbed from stored output
AvailablePhase output is scanned for common token, key and JWT shapes before it is persisted or served locally. A convenience filter — not a DLP guarantee.
Evidence owner: Vendor
Team events are hash-chained, not source-signed
AvailableThe current Team service records org events in a server-side SHA-256 hash chain with exportable, offline-verifiable continuity. It is tamper-evident at the server — it is not the signed, commit-bound evidence envelope planned for the pilot.
Evidence owner: Vendor
This website collects the minimum it needs
Waitlist and contact submissions store what you type and when. Analytics run only after cookie consent. Licenses verify offline — the app does not phone home to check them.
Evidence owner: Vendor
The pilot boundary — as it ships.
The governed remediation pilot is built around these controls. Each stays Planned here until the corresponding application release and its security evidence are approved — we add claims to this page, we don't backdate them.
Execution in a disposable runner you operate
PlannedPilot tasks run in a single-use, isolated runner inside the customer environment with policy-controlled egress and destruction proof. Until this ships with security evidence, no runner isolation claim applies.
Evidence owner: Customer
One signed task contract per task
PlannedA human-authorized, immutable envelope fixes the finding, repository, commit, policy and permitted outputs before anything runs.
Evidence owner: Joint
Fail-closed, with machine-readable denials
PlannedA missing or invalid control — identity, policy, runner, commit binding, model, evidence sink — stops the task before execution. No fallback to local execution, static credentials, or unsigned evidence paths.
Evidence owner: Vendor
Verification bound to the exact commit
PlannedTests, required CI checks, and the scanner re-run execute against the exact head SHA of the change.
Evidence owner: Joint
Signed, independently verifiable evidence
PlannedThe evidence bundle binds the input finding, policy, runner image, commits, check results and human decisions, and lands only in the customer-approved sink. Verifier tooling ships with it.
Evidence owner: Vendor
Data minimization and named output channels
PlannedEverything leaving the runner flows through enumerated, policy-approved channels; context sent to models is minimized by policy.
Evidence owner: Vendor
A customer-operated data plane, no standing vendor access
PlannedThe coordinator runs in the customer environment with signed, pinned updates. Support access, when implemented, is customer-approved, time-limited, least-privileged, and evidenced. Kill switches are customer-held.
Evidence owner: Customer
Enterprise identity and dual control
PlannedIdP-managed sign-in, provisioning, RBAC and dual-control approvals arrive after the pilot.
Evidence owner: Joint
Where the claims stop.
- ✕No compliance certification (SOC 2, ISO 27001, or otherwise) is claimed today, and no feature name or evidence bundle implies one.
- ✕No on-prem or air-gapped package is generally available today; “customer-hosted” in pilot materials never means offline. The Docker packaging of this site is the existing Team service, not a customer data plane.
- ✕No SLA is active without an explicitly signed agreement — priority support is service-only.
- ✕Domain capture is a sign-in convenience, not SSO: SAML, OIDC and SCIM are planned, post-pilot.
- ✕No “zero-access” or “non-repudiation” absolutes: the local Community boundary is one OS user, and the model provider you configure receives prompts by design.
- ✕Windows is not supported, and desktop availability is limited to what has actually shipped as a public artifact.
Talk to a human about any of it.
Security contact
hello@aionagent.appVulnerability reports, data-handling questions, and review requests — a human reads every message, within one business day.
Pilot responsibility summary
Request the summary →A plain-language split of customer and vendor responsibilities for the design-partner pilot, suitable for procurement and security review. Also provided during pilot intake.
Privacy, terms and cookie policies apply to this website and the services described here — see Privacy, Terms and Cookies. Pilot agreements are separate signed documents and always take precedence for pilot data handling.