Agent-scoped token can override authorship to another local custodial agent

[zsculac]

This was generated by AI during triage.

Summary

Agent-scoped API tokens may be able to request finalization/publishing as another local custodial agent by supplying a different authorAgentAddress in the request body.

Why This Matters

This is not a Solidity token-drain issue. It is a daemon/API authorization boundary issue.

Example:

Daemon has local custodial agents:
- Alice
- Bob

Caller authenticates with Alice's agent-scoped token.
Request body says authorAgentAddress = Bob.

If body author wins, daemon signs/finalizes as Bob.

That breaks identity attribution and can let one agent token act as another local custodial agent.

Code References

• packages/cli/src/daemon/routes/knowledge-assets.ts
  • resolveFinalizeOptions uses explicit authorAgentAddress if present, otherwise falls back to token-derived agent address.
• packages/cli/src/daemon/routes/memory.ts
  • shared-memory publish path has similar body/token authorship resolution logic.
• packages/agent/src/dkg-agent-publish.ts
  • assertionFinalize can use a local custodial agent private key for authorAgentAddress.

Expected Behavior

If a request is authenticated with an agent-scoped token, finalization should either:

• force authorship to that token's agent, or
• reject any explicit authorAgentAddress that differs from the token's agent.

Actual Behavior

The route appears to allow explicit body authorAgentAddress to override token-derived identity before passing options to agent finalization.

Validation Needed

• Add route-level tests:
  1. Register two local custodial agents.
  2. Authenticate with agent A token.
  3. Submit finalize/publish request with authorAgentAddress = B.
  4. Verify the request is rejected.

Suggested Fix Direction

In all agent-scoped token routes, if tokenAgentAddress != null, require:

authorAgentAddress absent OR authorAgentAddress == tokenAgentAddress

Apply consistently across KA create/finalize and shared-memory publish paths.

[zsculac]

This was generated by AI during triage.

Handoff: Bind Authorship To Agent Token

Focus

Continue work on GitHub issue #1284: "Agent-scoped token can override authorship to another local custodial agent".

Issue URL: #1284

Current Understanding

This is an API/authorship correctness issue, not an on-chain token theft issue.

An agent-scoped bearer token is supposed to act as one specific local agent. Current daemon routes can still accept an explicit authorAgentAddress in the request body. That body value can override the agent address derived from the token.

Plain-English summary:

Someone using Agent A's token may be able to ask the node to publish/finalize as Agent B, if Agent B is also registered locally.

Code References

• KA finalize/create flow:
  /Users/zvonimir/.codex/worktrees/fe82/dkg/packages/cli/src/daemon/routes/knowledge-assets.ts
resolveFinalizeOptions(...) currently chooses body authorAgentAddress before token-derived tokenAgentAddress.

• Shared-memory publish flow:
  /Users/zvonimir/.codex/worktrees/fe82/dkg/packages/cli/src/daemon/routes/memory.ts
  Body authorAgentAddress currently wins before falling back to token-derived agent address.

• Token resolution:
  Look for agent.resolveAgentByToken(requestToken) in the daemon routes. A defined result means the bearer token is agent-scoped. undefined means node/admin token or no matching agent token.

Latest Verification

Last verified during the audit against origin/main / HEAD at commit 539fa0109.

At that point:

• Issue Agent-scoped token can override authorship to another local custodial agent #1284 was still open.
• The relevant routes still allowed body authorship to override token-derived authorship.
• No equality check was found requiring authorAgentAddress to match the token-scoped agent.

Fresh agent should re-fetch latest origin/main before editing because mainnet-launch fixes have been landing quickly.

Likely Fix Direction

For agent-scoped tokens:

• If authorAgentAddress is omitted, default authorship to the token's agent address.
• If authorAgentAddress is present, require it to equal the token's agent address.
• If it differs, reject the request with a clear 400/403 error.

Open product/security question:

• Should preSignedAuthorAttestation also be rejected when an agent-scoped token is present, or only allowed if the attested address matches the token agent? Decide before implementation.

Node-level/admin tokens should preserve existing behavior if that is intentional: they do not resolve to a token agent and may still be allowed to specify an explicit local author.

What To Validate

• Agent A token with no body author publishes as Agent A.
• Agent A token with authorAgentAddress = Agent A succeeds.
• Agent A token with authorAgentAddress = Agent B fails.
• Node/admin token behavior remains unchanged, if intended.
• Shared-memory publish and KA create/finalize routes behave consistently.
• Existing tests for pre-signed/self-sovereign author flows still pass or are updated according to the product decision.

Suggested Skills

• superpowers:using-superpowers
• superpowers:test-driven-development
• superpowers:verification-before-completion
• tdd

Sensitivity Notes

No secrets, API keys, bearer tokens, or personal data are included in this handoff.