← Commit history

Caller identity: per-call is the documented default (issue #37)

John Lauer ·4ac2e30c22 ·3mo ago ·parent a5c5107
1 file changed +19−10
docs/caller-identity.md+19−10
@@ -20,8 +20,8 @@ Two pieces of information now ride along with every relayed command:  Alongside those, gated commands (the ones that ask your permission) also carry a **reason**: a one-line, plain-language explanation of why the AI wants to do this-particular thing. Identity is set once per conversation. The reason is written fresh for-every single call.+particular thing. Both ride along on each individual command: the identity stays the+same across a conversation, while the reason is written fresh every time.  ## In the Activity Log @@ -63,10 +63,11 @@ extra.  This is worth understanding clearly. -The **thread name is chosen by the AI itself**. Adom Desktop records it and displays it,-but it cannot verify it. It is a label, not a credential. Nothing in the system grants-or denies permission based on a thread name, and you should not treat one as proof of-anything.+The **thread name is chosen by the AI itself**. When you read a name on an approval+prompt or in the Activity Log, that name was written by the AI, not established by Adom+Desktop. Adom Desktop records it and displays it, but it cannot verify it. It is a+label, not a credential. Nothing in the system grants or denies permission based on a+thread name, and you should not treat one as proof of anything.  The **container name is different**. Adom Desktop knows the verified container from the authenticated relay connection, independently of anything the AI claims. When the@@ -103,13 +104,21 @@ middle of using.  Nothing you need to manage, but useful to recognise if you are reading along. -A conversation names itself once at the start of a session, usually by setting an-environment variable, after which the identity is attached to every command-automatically. If it does not, the first relayed command is refused with a message-explaining exactly what to set. Local callers are exempt, because they are already+A conversation names itself on each command it sends, either with a command line flag+(`--ai-thread "chip-fetcher tab 3"`) or by including the name in the command's own+arguments. If it sends nothing, the first relayed command is refused with a message+explaining exactly what to supply. Local callers are exempt, because they are already trusted by how they connect: Hydrogen Desktop, a bridge calling back into Adom Desktop, and the command line tool running on your own machine. +Naming per command is what keeps those names honest. Your twenty tabs typically share+one cloud container and one home directory, so anything set once for the whole+environment (an environment variable, say) is shared by all of them. Every thread would+then claim the same name, and your Activity Log would confidently show the wrong one,+which is worse than showing none at all. There is a narrow exception: a container+running a single agent, such as a scheduled job, can safely set its name once in the+environment.+ The one thing worth doing yourself: if a thread names itself something unhelpful (a random identifier, or just "agent"), tell it what you call that conversation. That name is what you will read on every approval toast it sends you.