Skip to content

hosted: persist attestation metadata beyond boolean checkbox (P1-1) #32

Closed

Description

@CodewithJha

Problem

docs/PRODUCTION_READINESS.md P1-1: attestation is not authorization — it is a boolean.

Evidence:

  • CampaignStartRequest.attestation: bool = False (apps/api/src/mutiny_api/schemas.py)
  • supervisor.start_campaign raises if not attestation
  • Ingest similarly requires attestation=true (ingest.py)

Bearer auth (M-PR7 / P0-1/P0-4) identifies the single-tenant operator when configured, but campaign records do not store a durable “who attested / when” principal beyond an event payload flag.

Why it matters

For Hosted safe-mode and audits, “checkbox true” is weak. Strengthening toward logged attestation metadata is the contributor-sized step without inventing multi-tenant AuthZ or bringing back customer exec.

Proposed direction

  1. Extend start/ingest attestation to accept an optional non-empty attestation_note or require attested_at server-side timestamp always.
  2. Persist on campaign config / events: {attestation: true, attested_at, token_fingerprint?} (hash of bearer, never raw token).
  3. Document in SECURITY.md that AuthZ remains “holds MUTINY_API_TOKEN” for single-tenant; attestation is operator acknowledgment, now auditable.

Acceptance criteria

  • Campaign start stores attestation timestamp (and optional note) in config or events
  • Raw API token never logged or stored
  • Tests for reject-when-false unchanged; new assert on persisted metadata
  • Docs updated (SECURITY / PRODUCTION_READINESS P1-1 status note)
  • No multi-tenant redesign; no customer exec_module

Testing expectations

uv run pytest tests/integration/test_api_hosted_auth.py tests/unit/… -q + new cases

Difficulty

M · security / backend

Activity

  1. added
    enhancementNew feature or request
    help wantedExtra attention is needed
    backendAPI / Core server-side
    securitySecurity-related
    priority:P1Important reliability/adoption
    on Sep 9, 2026
  2. self-assigned this
    on Sep 9, 2026
  3. BasilZafar11 commented on Oct 22, 2026

    @BasilZafar11
    Contributor

    Opened PR #133 to fix #32. Campaign starts and ingest now persist server-generated attestation timestamps. Retries preserve the original timestamp, and no bearer token is stored in attestation metadata. Security docs updated; 740 tests and Ruff pass.

    #133

  4. added a commit that references this issue on Nov 3, 2026
    50b3555
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

backendAPI / Core server-sideenhancementNew feature or requesthelp wantedExtra attention is neededpriority:P1Important reliability/adoptionsecuritySecurity-related

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions