Skip to content

[G19] Audit trust admission and cross-worker secret boundaries #19

Description

@jjangg96

Goal

Verify and enforce the advertised trust profiles so untrusted work cannot enter trusted-only pools and jobs cannot reach manager credentials/control in the supported configuration.

Create one active Codex goal from the statement above when this issue is dispatched. The Project Goal field is a work specification; it does not start an agent. Do not invent a token budget.

Execution contract

Field Value
Goal key G19
Stage M3 - Reliability qualification
Initial status Backlog
Primary agent gpt-5.6-luna / max
Priority / risk P0 / High
Test profiles offline, trusted-runtime, trusted-live-github

Use one issue branch/worktree and one focused PR. Independent Luna max review is required for authentication, protocol, concurrency, resource ownership, cleanup or service identity boundaries; other changes need independent contract review. Model fields are routing instructions, not GitHub user assignments.

Dependencies

Dependencies must be Done before implementation begins. A new issue is not blocked simply because its future evidence has not been collected.

Scope

Threat-model closure, policy preflight, native UID and Docker DinD profiles, adversarial non-destructive probes. No unsupported claim of hostile-container isolation.

TDD and failure evidence

  1. Red: mismatched runner-group access, ambiguous fork provenance and job invoking official CLI cannot bypass policy.
  2. Try reading controller home/state/keychain/socket, sibling files/env and manager Docker socket from controlled test jobs.
  3. Exercise SDK secret-in-error, proxy inheritance, wrong-org endpoint, unsafe mount/device/host-network requests.
  4. Test shared-App blast radius/rotation docs and reject unsupported arbitrary backend flags.

Capture a meaningful failing case before the implementation, then green evidence and relevant refactor checks. Tooling/prose-only work uses appropriate negative checks without artificial application tests. Live/runtime profiles require reviewed commits, a dedicated trusted test environment and explicit authorization for the concrete experiment. Public PR CI uses hosted environments without credentials. Planned or skipped tests never count as passed.

Acceptance criteria

  • Runner-group restrictions verified before new admission; no automatic broadening to all repos.
  • Outer runner launches unprivileged; only reviewed worker-specific DinD has manager-runtime privilege. Trusted jobs control inner daemon; no claim that inner privileged containers are prohibited.
  • Same-user native insecure mode is not protected default; unresolved boundaries block release.
  • Public-fork support deferred until isolated VM/network provenance design is proven.
  • Record exact validation commands, actual results, skipped/live-test gaps and applicable rollback notes in the PR.
  • Independent review is resolved and the focused PR is merged under the repository execution policy.
  • Update issue/Project accurately; mark the active goal complete only after all required evidence and work are complete.

Safety invariants

Preserve existing manual runners; no global Docker prune/context switching, broad process kill, implicit App enrollment, busy-job cancellation during ordinary scale-down or transparent workflow replay. Use only verifiably owned resources. Keep management credentials and raw secret-bearing SDK errors out of worker environments, logs, fixtures and commits; per-worker JIT transport follows G01. Native pools remain trusted-only.

Design references

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent:astra-xhighPrimary implementer: gpt-6-astra, xhigh reasoningpriority:P0Critical contract, security or reliability dependencyrelease:distributionApproved delivery sequencing; does not change acceptance or dependency gatesrisk:highIndependent Astra review on risky boundariestype:gateEvidence gate before dependent work

    Type

    No type

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions