Enterprise · design-partner pilot

One finding in. One proven PR out.

The enterprise design-partner pilot ingests an approved SARIF or CodeQL finding, creates one bounded authorization, runs in a customer-controlled disposable runner, tests and rescans the exact commit, and opens a draft pull request with verifiable evidence. It never directly merges or deploys.

This workflow is being built with a small number of design partners. Each control below carries its status from the capability matrix — nothing here is generally available today.

Apply for the pilotTrust & security →

The workflow, end to end.

The loop engine stays the same — plan, code, test, verify — but every consequential step sits behind an explicit boundary. Amber markers are the moments a human decides.

  1. 1

    An approved finding arrives

    Human decisionPlanned

    Your scanner already found the problem — CodeQL or any SARIF 2.1.0 source. A person on your team selects it; Aion never scans or picks its own targets.

  2. 2

    Intake & eligibility

    Planned

    The finding is normalized into one canonical record — rule, location, exact commit — and checked against what the pilot can safely attempt. Ineligible findings are declined with a written reason, not attempted anyway.

  3. 3

    One signed task contract

    Human decisionPlanned

    A human authorizes one bounded task: this finding, this repository, this commit, this policy, these permitted outputs. The authorization is immutable — the task cannot widen its own scope.

  4. 4

    A disposable runner you operate

    Planned

    Work happens in a single-use, isolated runner inside your environment, with only the network egress your policy allows. Aion has no standing access; the runner is destroyed after the task.

  5. 5

    Bounded execution

    Planned

    The loop engine — the same fresh-context, checkpointed state machine Community runs — writes the minimal fix. If any required control is missing or invalid, the task stops before it starts and returns a machine-readable denial.

  6. 6

    Verified on the exact commit

    Planned

    Tests, your required CI checks, and a scanner re-run execute against the exact head commit of the proposed change — not “latest”, not a branch name.

  7. 7

    A draft pull request

    Planned

    The workflow terminates at a draft PR in your repository. There is no merge step, no deploy step, and no setting that enables one.

  8. 8

    Evidence you can verify

    Planned

    A signed, commit-bound evidence bundle lands in your approved sink: the input finding, policy, runner image, source/base/head commits, CI and scanner results, and every human decision — independently verifiable.

  9. 9

    Your reviewers decide

    Human decision

    A human on your team accepts or rejects the PR like any other contribution. Branch protection, review rules, and repository ownership are untouched.

  10. 10

    Closure confirmed by the scanner — later

    Human decision

    A finding counts as closed only when your scanner confirms it on a subsequent scan after your team merges. Opening a PR closes nothing by itself, and Aion never dismisses a finding.

→

The pilot ends here: a draft pull request plus verifiable evidence. Merging, deploying, and closing the finding are your calls, made with your tools, on your timeline.

The boundary, drawn plainly.

Everything consequential lives on your side of the line. The vendor ships software and schemas — not access.

Your environment owns

  • ✓Repositories, findings, branch protection and policy
  • ✓The disposable runner and its egress allowlist
  • ✓Model / provider choice and data-region constraints
  • ✓The evidence sink, retention, and keys
  • ✓Every authorization, every merge, every kill switch

Aion provides

  • ▸Signed, pinned software artifacts and documentation
  • ▸The task-contract, policy and evidence schemas
  • ▸Verifier tooling for the evidence bundle
  • ▸Support through the contracted boundary — zero default access

Never crosses the line

  • ✕No standing vendor access to your environment
  • ✕No source code or durable credentials to the vendor
  • ✕No direct merge, deploy, or finding dismissal
  • ✕No unapproved outbound channel from the runner

When a required control is missing — authorization, policy, runner, commit binding, model, evidence sink — the task fails closed: it stops before anything runs and returns a machine-readable denial. Planned

How to read the labels.

Available

Implemented, tested, and generally supported today.

Pilot

An implemented path for selected users — external deployment or operational evidence is still incomplete.

Planned

A roadmap commitment. No supported implementation in the current build.

Service-only

Delivered by people under an explicit agreement, not an in-product control.

Apply for the pilotFull capability matrix →Trust & security →Plans →