---
name: credential-holder-boundary-one-actor-per-identity
description: "A service credential is an IDENTITY, not a datum — one holder acts as it; hand the owning agent the question instead of reading their token, even when the OS cannot enforce the line."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: ed225bde-9717-4f78-b719-b8fe8ac4f16c
  modified: 2026-08-21T23:02:52.972Z
---

Flynn's boundary, 2026-08-21, stated when I proposed reading the alchemy Hub bot token
(daemon.toml) to run two read-only Discord GETs myself: the bot is alchemy's identity on
the board — anything holding the token can post, edit, and delete as Alchemy Hub in every
Project channel. Same OS user, so nothing enforces the line; it is a line about who ACTS
as the Hub, kept so there is ONE holder of the credential instead of two.

**Why:** my plan was read-only and technically safe, and still wrong-shaped — the moment a
second agent holds the credential, provenance of every act under that identity is split,
and "read-only this time" is a property of the plan, not of the holding. The audit trail
argument mirrors CONTEXT.md's redemption-authority rule (never record a machine's act as a
person's): acts should be attributable to their actor.

**How to apply:** when an instrument requires another agent's service credential, hand
that agent the QUESTION and take the number back as their measurement — the data reaches
you the same either way, and the credential keeps one holder. Ask for paths/ids, never
tokens; and if you find yourself locating a peer's credential file, that is the moment to
stop and route the question instead. Works both directions: state the boundary plainly
when a peer reaches for yours, as flynn did — boundary, not suspicion.

Related: [[relay-is-not-the-gaters-word]] (the sender-side refusal face) ·
[[dont-solo-across-role-lines]] · [[no-diagnostics-in-identity-blast-radius]].