AAuth × Mujin Fleet — Technical Companion

document:  aauth-fleet-technical
date:      2026-08-31
audience:  machine consumption (an agent reasoning about changes to the AAuth drafts),
           plus anyone who wants wire-level detail
companion: "AAuth in a Working Agent Fleet" (design doc, same date) — read that first
           for narrative; this document is the inventory, flow traces, deployment
           profile, and numbered change requests.
scope:     architecture only. Credentials, network addresses, key locations, and
           personal data are deliberately absent; hosts are named by role. The
           trust-model description is deliberately candid about where enforcement
           is convention — shared on the operator's explicit decision, because the
           gaps are the design input.
against:   originally draft-hardt-oauth-aauth-protocol-10 (2026-08-06) plus the
           Bootstrapping / Budgets / R3 / Events documents; revised 2026-08-31
           against the working draft on main (-11 in progress) after the author
           read an earlier revision. CR statuses below reflect his answers.

1. System glossary and repos

Machine roles used below: tracker-vm (runs S2), marshal-host (runs S3, S5, S6), gateway-mac (runs S15 and capture lanes), producer-mac (any of several developer machines running S17), edge (Cloudflare Workers/Pages running S11).

2. Trust-surface inventory

Enforcement classes: HARD = survives a hostile client (key, ruleset, uid, or server-side check). CONV = convention; cooperating clients police themselves. DETECT = violation is detected after the fact but not prevented.

Summary the drafts should design against: authentication exists at the perimeter (SSH, access proxy, one bearer, payment signatures); there is no authenticated per-agent identity inside it. The hard boundaries that exist (T5, T8, T10-replay, T13) were added reactively after conventions failed, and none of them provides per-agent request identity.

3. Flow traces (today), with AAuth mapping

Traces are schematic: header names and API routes generalized, credentials named by kind.

F1 — tracker write

producer session (producer-mac)
  → POST <tracker>/... { actor: "<self-asserted string>", ... }
    Authorization: Bearer <fleet-wide static token>
tracker daemon (tracker-vm)
  → constant-time compare of bearer; no per-operation authz
  → records actor as supplied

AAuth target (agent identity mode, Phase 1):

producer session
  → local signing proxy (holds lane key; accepts callers ONLY via a
    uid-restricted unix socket with peer-credential checks — a loopback TCP
    proxy is a signing oracle for every process on the machine)
      adds Signature-Key: sig=jwt;jwt="<agent_token>"      (typ aa-agent+jwt, cnf.jwk)
      signs @method,@authority,@path,@query,signature-key,
            content-digest,content-type                     (RFC 9421, ed25519)
      — body and query MUST be covered: the tracker carries security-relevant
        values (labels, comments, actor fields) in JSON bodies and query params
  → verifying sidecar (tracker-vm)
      full agent-token verification per §5.2.4 (typ, dwk, exp/iat, alg
      fully specified, iss metadata match) + signature verification per
      §12.8.4 (covered components, created freshness, cnf.jwk binding)
      JWKS fetch under §12.9 discipline; in this closed-world deployment the
      issuer set is pinned to our own domain — no attacker-supplied iss is
      ever resolved (kills the SSRF/metadata-fetch class)
      policy[sub] → allow/deny this verb+label (default-deny on missing row)
      forward to loopback daemon; assert verified identity via the tracker's
      trusted-proxy actor mechanism (see §4) — never by rewriting bodies

Gap exercised: none at the protocol level — this is stock agent identity mode plus a proxy deployment pattern (CR-5). The engineering content is in the verification checklist and the caller-auth boundary above, both easy to get wrong.

F2 — marshal handoff and drain

producer: git push origin <branch>                 (shared user key — T4)
producer: post review-evidence comment             (T6; grammar, counts, oid)
producer: post marker comment                      merge: repo=<slug> branch=<b> oid=<40-hex> attempt=<ts>.<nonce>
producer: add label handoff-to:merge-marshal       (T3)
marshal (marshal-host), on poll:
  verify review evidence grammar + oid == marker oid + arithmetic
  pin branch head; if remote head != marker oid → bounce ("branch moved")
  rebase, sandbox gate, push main via deploy key   (T5, HARD)

Properties worth noting for the spec: the marshal consumes the producer's assertions minutes to hours after they were made, from a queue, with the producer's session possibly gone. Verification-at-consumption of a detached, signed artifact is the shape (CR-3, CR-9). The oid pin is the only cryptographic binding today, and it binds the branch state, not the asserting identity.

F3 — niwashi groom → human promote

nightly (marshal-host):
  snapshot backlog → classify → propose (model A) → review (model B, different family — enforced)
  writes: 1 comment + label niwashi-candidate | joi-decision   (closed write set)
  hygiene proposals → docket records (JSON files), single-shot, revision-pinned
human later:
  niwashi-promote review --ack        (drift since ack ⇒ refuse until fresh ack)
  niwashi-promote <ref>               → ordering links, provenance comment, designed-ready

Mission mapping (Phase 3): the candidate card = mission proposal (markdown, content-addressed by the revision pin); --ack + promote = mission approval; the provenance comment = the mission reference. Drift-refusal = mission immutability. This flow was designed before we read the AAuth drafts; the convergence is the strongest validation signal we can offer.

F4 — decision-docket approval (slow consent)

any agent, blocked on a human decision:
  post comment naming the decision + options; add label joi-decision; park
surfaces: morning brief (daily), ops board (live), phone chat taps (async)
human: decides — sometimes in minutes, typically hours, sometimes days
agent (a later session, often not the same process): reads the ruling, removes label, resumes

Two protocol-relevant facts: (a) the approving human is on a phone tapping a button, never in a browser redirect; (b) the requesting agent usually no longer exists when the grant lands — a successor session with the same lane identity picks it up. AAuth's 202+poll with a 5-minute resource-token lifetime does not describe this (CR-1); grant-to-successor requires the grant to bind to the durable identity, arguing for lane-level sub + session-level sub-agents (CR-4).

F5 — x402 handshake quest (public, live)

member in Discord: "@jibot handshake 0x<wallet>"
cell agent → POST edge /initiate      [internal server-to-server auth]
edge: on-chain community-token balance check (the real authorization)
edge: sends $0.01 USDC to member wallet (background)
member's own agent → POST edge /handshake  {wallet, audience}
edge: 402 PAYMENT-REQUIRED → agent signs EIP-3009 transferWithAuthorization ($0.01)
edge: verify + settle inline (self-hosted facilitator; public x402.org facilitator
      only supported one testnet for scheme "exact", so verify/settle moved in-process)
edge: cross-check x402 payer == registered wallet → admin-mint ERC-1155 → agent polls /status

Identity mechanisms in one flow: platform identity, shared secret, wallet-key possession. AAuth would add the fourth and unifying one; the enrollment moment (quest completion) is a natural agent-provider enrollment (Phase 4). Discovery today: the site publishes /.well-known/x402.json and /.well-known/agents.json; adding aauth-resource.json is one file.

F6 — jilog spool

producer-mac: jilog spool emit → segment files (source: self-declared, CRC32)
transport: file sync and/or SSH push to gateway-mac (gateway-mac holds no keys
           to the producer Macs by design; producers push)
gateway-mac: jilog spool ingest — CRC verify, filename/source identity match,
             traversal + duplicate rejection; rejected segments quarantined
nightly: learning loop → files structured issues into kata over T1

Gap: provenance is self-declared. Segment signing by the emitting agent's key is Phase 2; the ingest gate already has the right shape (verify-at-consumption, quarantine on failure) to add signature verification cheaply.

4. Proposed deployment profile (what we would actually run)

Identity plan, agent identity mode, initial mint (~10 identities, per-lane not per-session). Key architecture (corrected by the author): ONE AP verification key is published in the JWKS at the well-known URL; each lane identity below is an AP-issued agent token with its own sub and its own cnf key, and the lane keys live only inside their signing proxies — never published:

aauth:niwashi@<domain>            grooming lane
aauth:niwashi-auto@<domain>       auto-promoter (dark today; ships with its own identity)
aauth:marshal@<domain>            drain + bounce/land writes
aauth:roborev@<domain>            post-commit patrol
aauth:jilog@<domain>              nightly learning loop
aauth:producer.<host>@<domain>    one per producer machine (attended sessions)
aauth:promoter@<domain>           the human promotion surface (the ONLY writer
                                  of designed-ready besides niwashi-auto)
aauth:jilog@<domain>              nightly learning loop (creates issues/comments)
aauth:dashboard@<domain>          read-only projector
aauth:jibot@<domain>              the public agent (edge)

Sessions later become sub-agents per §10.2 of the draft: aauth:producer.<host>+<session>@<domain>, AP-issued sub-agent tokens with parent_agent, single-level depth (see CR-4 for the operational question that remains).

Agent-provider lifecycle (required for this to run at all, understated in an earlier revision): a small self-hosted AP issues the aa-agent+jwt tokens (24h per the draft's SHOULD NOT), signing proxies renew automatically before expiry, revocation = key removal from the published JWKS plus policy-row removal, and JWKS rotation is scheduled. Without automated renewal, Phase 1 stops working one day after it starts.

Sidecar policy sketch (static, versioned; the semantics we need a resource policy to express):

[defaults]
read = true                       # all identities may read

["aauth:niwashi@<domain>"]
create_comment = true
add_labels    = ["niwashi-candidate", "joi-decision"]
remove_labels = ["niwashi-candidate"]     # own corrections only, rate-capped upstream
everything_else = "deny"

["aauth:niwashi-auto@<domain>"]
add_labels = ["designed-ready"]           # nothing else, not even comments
everything_else = "deny"

["aauth:marshal@<domain>"]
create_comment = true
add_labels    = ["merge-blocked"]
remove_labels = ["handoff-to:merge-marshal", "merge-blocked"]
close_issue   = true                      # with evidence comment

["aauth:promoter@<domain>"]               # the human promotion surface
create_comment = true
add_labels = ["designed-ready"]
link_issues = true                        # ordering links written at promotion

["aauth:jilog@<domain>"]
create_issue = true                       # nightly loop files findings
create_comment = true
add_labels = ["jilog:*"]                  # its own namespace only

["aauth:roborev@<domain>"]
create_comment = true                     # patrol findings

["aauth:producer.*@<domain>"]             # attended sessions
create_issue = true
create_comment = true
claim = true
add_labels = "*"
deny_labels = ["designed-ready",          # promotion: promoter identity only
               "niwashi-candidate",       # niwashi's shadow label
               "merge-blocked",           # the marshal's bounce signal
               "on-deck",                 # deck state: deck writers only
               "joi-decision-resolved"]   # placeholder: every authority label
                                          # from the T3 row gets an explicit
                                          # deny here EXCEPT handoff-to:merge-
                                          # marshal, which producers legitimately
                                          # set when handing off

Policy-continuity warning (the author's most consequential catch): this table is keyed on the verified agent identifier and works exactly and only in agent identity mode. Auth tokens deliberately carry no agent identifier — cnf binds a key, the resource enforces sub (the person) and scope. Any operation that moves behind the PS in Phase 3 loses its per-lane row unless re-expressed as scopes or R3 operations. Plan: authority-label writes stay in agent identity mode permanently; only person-principal operations (approvals, promotions) move to auth tokens, policed by scope.

Two semantics that an earlier revision left implicit: unlisted identity ⇒ deny everything; listed identity, unlisted verb ⇒ deny. The producer row's deny set must enumerate every authority-bearing label from the T2 inventory (T3 row) — a wildcard-allow with one deny, as an earlier revision sketched, silently leaves the rest of the authority labels writable and falsifies the Phase 1 claim.

Sidecar behavior: verify per §3-F1; on deny → 403 with a machine-readable reason; on gated ops (Phase 3) → 401 + AAuth-Requirement: requirement=auth-token; resource-token="…"; every allow/deny logged with sub, jti, verb.

Actor assertion to the origin: the tracker upstream already designed the right mechanism — a trusted-proxy actor header on a dedicated listener, with inbound copies stripped, missing-header requests rejected, and the origin unreachable except through the proxy (kenn-io/kata#58). The sidecar uses that, never generic body rewriting: tracker actors appear in JSON bodies and query strings across routes, and re-serialization breaks content digests. This existing design is also prior art for CR-5.

Token lifetimes we would choose: agent tokens at the draft's 24-hour SHOULD NOT, automated renewal; signing-proxy keys rotated on schedule, not per request; resource tokens at the 5-minute SHOULD NOT are fine for the request leg — the open question is successor-collection semantics on the pending-approval leg (CR-1).

5. Change requests against the drafts

Format: current draft behavior → our constraint → requested change. Severity: B = blocks a phase for us, I = important, N = nice to have.

Revised twice on 2026-08-31: first after an independent-model review against -10, then after the protocol author read that revision against the working draft (-11 in progress). Statuses below carry his answers. Withdrawn items are kept, not deleted — where two careful passes still misread the drafts is itself data about what the documents could surface earlier.

CR-1 (I, Phase 3) — Pending grants across key rotation. Status: revised again after author feedback; two of our framings were wrong. Author's answers: fresh-resource-token-at-collect is already normative twice (Resource Token; Deferred Delivery), and "any caller with the same sub key" names a thing that does not exist — pending state, agent_jkt, and cnf bind keys, not sub; honoring sub would demote proof-of-possession to identity-level. Our lane-key-in-signing-proxy design also dissolves most of the successor problem: the durable key outlives sessions, so a successor session is not a successor principal. What survives (and the author agrees is unspecified): the pending record's lifetime has no stated relationship to the token lifetimes flowing through it, and under bootstrap's two-key refresh an agent token can rotate to a fresh ephemeral key while a grant is pending against the old one — the normal case, not the corner, whenever consent outlasts an agent token. Either pending state binds to the durable key, or rotation across a pending grant is forbidden, or re-presentation under a new key needs defined behavior.

CR-2 (N, Phase 3) — Standing consent rules are governance policy, not mission syntax. Status: reframed after author feedback. Author's answer: R3's operation access annotations already carry the split (agent-token / person-token / auth-token / per-call), with per-call defined for exactly the operations that block on a person, and r3_granted vs r3_per_call in the auth token — and the declaration deliberately lives at the resource, which knows the consequences, not in the mission, which is the agent's proposal. What survives: the person-side standing rule ("mechanical batch, judgment per-item") is the PS's governance policy, and no document defines what a governance policy is or how a PS decides — requirement=clarification exists on the wire with no decision procedure behind it. That is the governance-agent hole (see CR-11).

CR-3 (B, Phase 2) — Detached signatures over artifacts at rest. Status: open; home corrected. Author's answer: draft-hardt-httpbis-signature-key conveys keying material for RFC 9421 HTTP message signatures; a detached JWS over artifacts at rest does not belong there. Agreed — it is a separate small companion document. The ask stands: an interoperable detached-signature envelope under AAuth identities, covering domain separation from request signatures (an artifact signature must never validate as a request or vice versa), artifact typing and canonicalization, verify-while-live-and-archive semantics per the non-repudiation section, and durable-evidence keys kept apart from the online request key an internet-adjacent proxy holds. Our consumers (F2 drain, F6 ingest) are the deployment. Would a contributed draft be welcome?

CR-4 (I, Phases 1–3) — Operational custody for session churn. Draft: §10.2 already defines the sub-agent flow normatively — AP-issued sub-agent tokens, single-level depth, parent-signed PS requests carrying subagent_token, act.agent naming the parent. Our earlier ask for locally-minted parent-attested tokens was redundant at best and incompatible with AP JWKS verification at worst. Constraint: one operator machine runs long-lived lanes plus dozens of ephemeral sessions a day. Request, narrowed: operational guidance in the bootstrap draft for exactly this shape — is a co-located self-hosted AP issuing short-TTL sub-agent tokens the intended conformant answer to session churn? Plus custody guidance for many-agents-one-operator machines: per-uid isolation of signing components, local caller authentication for anything that signs (a loopback signer is an oracle for every process on the box), rotation cadence.

CR-5 (I, Phase 1) — The proxy pair as a first-class profile. Draft: assumes the resource implements verification and the agent implements signing. Constraint: our tracker is a mature third-party daemon; our clients are unmodified CLIs. Fastest adoption is a verifying reverse proxy in front of the resource and a signing forward proxy in front of the client — the oauth2-proxy path. Request: bless this in bootstrap guidance and specify the proxy→origin identity assertion. Prior art exists on the resource side: the tracker upstream already designed a trusted-proxy actor mechanism — dedicated listener, inbound header stripping, reject-on-missing, origin unreachable except via the proxy (kenn-io/kata#58). The client-side signing proxy needs matching guidance, especially its local caller-authentication requirement (CR-4). Every single-static-token daemon in the wild adopts AAuth this way or not at all.

CR-6 (I, Phase 3) — A "personal PS" profile. Status: narrowed twice; mostly a floor statement now. Author's answers: the callback parameter is optional with polling as the completion signal (no redirect exists anywhere in the agent-to-PS path — our premise was wrong), and a conformant PS is four metadata fields (issuer, auth_token_endpoint, person_token_endpoint, jwks_uri) plus interaction_endpoint if consent is wanted; everything else is OPTIONAL. Nothing says "this is the floor," which is why two careful readings (ours) inferred the full surface was required. Remaining asks: state the floor in the PS-metadata section; define out-of-band interaction completion — a PS completing consent on a channel it controls (a phone tap), and what happens to the single-use code in that case; and a personal-PS profile document, the natural home for CR-1's pending-lifetime clarification, since a personal PS is where slow consent is the normal case.

CR-7 — Budgets × settlement. Status: withdrawn, answered. The Budgets draft's scope section answers it exactly: "Not payment or settlement. No funds move. 402 Payment Required and the resource's commercial arrangement with the person are untouched" — and it uses x402's decimals by name with an x402 prior-art section. Deliberately payment-agnostic, deliberately denominated to compose with x402. Our trust402 datapoint (client-side spend-limit proof before payment complements resource-side ceilings) stands as a datapoint, not a request.

CR-8 (N) — Cross-namespace identity binding, privacy-scoped. Constraint: the fleet already holds Ed25519 identities in other namespaces — a P2P agent mesh (key = identity), a community relay (nostr npubs), wallets (key = economic identity, T14). One agent is currently a different principal on each transport. Request: an attestation format by which an aauth identity binds another key or address it controls (and vice versa), verifiable from published metadata — but designed privacy-first: pairwise or audience-scoped attestations rather than one public link-set (a global bidirectional binding makes an agent's social and economic history linkable forever), explicit disclosure consent, and revocation that actually severs the link. The use case is real — a resource that met an agent via x402 payment recognizing it later via mode 1 is exactly our quest-enrollment plan — but a naive also_known_as would be a correlation gift.

CR-9 (I, Phase 2) — A deployment profile for §14.16. Draft: §14.16 already answers deferred verification — verify and archive evidence while the key is live, or use trusted timestamps / JWKS snapshots / transparency logs. Our earlier proposal (trust a timestamp signed by the agent itself) was unsound: a compromised or expired key can backdate. Constraint: our consumers verify assertions minutes to hours after production (F2 drain, F6 ingest), and one of them gates code landing on the result. Request, narrowed: a recommended minimal profile among the §14.16 options for a single-operator deployment with no transparency-log infrastructure — we read it as "the queue consumer verifies at enqueue time and archives the verification evidence; consumption trusts the archive," and would like the draft to say whether that reading is the intended floor.

CR-10 — Events for intermittent agents. Status: withdrawn, answered. The Events draft scopes it out by construction: AP-to-agent delivery is platform-dependent and out of scope; the AP is the inbox, and retention/ack between AP and agent are an AP implementation matter. For our deployment that is workable — the lane's signing proxy (the durable principal) collects.

CR-11 (I, Phase 3) — Define the governance policy. Status: new, from the author's reading; now our top ask. The policy-evaluation section says the PS decides "based on user consent and, when the agent is operating under a mission, the mission's intent and prior log entries against the PS's governance policy" — and no document defines what a governance policy is or how a PS reaches granted / denied / clarification-required. A governance-service shape needs no new protocol objects: the PS calls it with the mission, prior decisions under that mission, and the resource token; it returns a decision with the warrant and the claims relied on, mapping onto existing wire artifacts including requirement=clarification. This is where CR-2's consent tiers actually live, and it is what makes a personal PS (CR-6) worth building: without a decision procedure it is a queue with a protocol on it; with one it answers routine requests without waking the person. Our fleet already runs the input side — a grooming lane that tiers proposals into mechanical and judgment classes against a ~100-deep human queue — and we would be a willing first deployment for a governance-policy companion.

6. Invariants any integration must respect

1. The marshal's deploy-key + ruleset boundary (T5) stays. AAuth complements it; nothing routes around it.
2. Niwashi's OS-uid isolation (T8) stays. Model stages never hold agent keys; the lane's signing proxy runs outside the model uid.
3. Fail-closed bias: unknown identity, unverifiable signature, or missing policy row ⇒ deny + alert, never warn-and-allow. (House precedent: consumers refuse an issue whose blockers they cannot read.)
4. The failure mode of any single compromised component must remain "a wrong proposal in front of a human with an audit trail," never "wrong work executes."
5. Rollback is a rehearsed, operator-run procedure, not a client setting: re-open the daemon's prior listener and restore the prior credential in one controlled step. (An earlier revision said "clients repoint at the daemon" — that contradicts the acceptance criterion that the daemon is reachable only through the sidecar, and quietly assumed the retired credential was still lying around on clients.)
6. Human approval surfaces don't change. The PS adapts to the morning brief and phone taps; the human does not adapt to the PS.
7. Nothing arms without a negative-path test suite: bad/expired/wrong-key tokens, uncovered-component tampering (body, query, content-type), replay, JWKS rotation and outage, signing-proxy caller-auth bypass attempts, direct-to-origin bypass attempts, actor assertion on every route shape, and policy-transition cases. "Policy iterates in production" applies to allow/deny rows, never to the verifier itself.

7. Provenance

Compiled 2026-08-31 by Claude agents in Joi Ito's fleet from a same-day source survey of the systems above, against draft-hardt-oauth-aauth-protocol-10 and the AAuth repo's exploratory specs. Corrections travel fastest as issues on the public repos in §1 or replies to Joi.