docs(assistant): the socket IS the assistant, not an unknown caller #986

Merged

lytedev merged 1 commit from propose/socket-is-the-assistant into main

2026-08-12 15:23:52 -05:00

lytedev commented

2026-08-12 15:22:35 -05:00

Owner

Same behaviour, corrected reasoning — a follow-up to #984.

That PR justified the approval gate by an inability ("the socket cannot authenticate its caller"). True, but it invites someone later to remove the gate by adding caller identification. The rule is stronger: the socket is the agent's interface, so a caller on it is the assistant, and the assistant holds no privileged authority — which stays true no matter what the transport learns to prove.

Also states that approval must come from a known admin, and why, and fixes a doc comment #984 misplaced (perform_approved's explanation had been left attached to ask_approval).

Same behaviour, corrected reasoning — a follow-up to #984. That PR justified the approval gate by an *inability* ("the socket cannot authenticate its caller"). True, but it invites someone later to remove the gate by adding caller identification. The rule is stronger: the socket is the agent's interface, so a caller on it **is** the assistant, and the assistant holds no privileged authority — which stays true no matter what the transport learns to prove. Also states that approval must come from a **known admin**, and why, and fixes a doc comment #984 misplaced (`perform_approved`'s explanation had been left attached to `ask_approval`).

lytedev added 1 commit

2026-08-12 15:22:35 -05:00

docs(assistant): the socket IS the assistant, not an unknown caller

/ check-format (push) Successful in 29s

Details

/ build (push) Successful in 7m26s

Details

d1d25f5868

Same behaviour, corrected reasoning. The previous wording said both
callers ask "because the socket cannot authenticate its caller" -- true,
but it justifies the gate by an inability, which invites someone later
to remove it by adding caller identification.

The actual rule is stronger and does not decay: the socket is the
agent's interface, so a caller on it IS the assistant, and the assistant
holds no privileged authority. That stays true no matter what the
transport learns to prove. A person who wants to act rather than ask
uses Matrix, where they have been authenticated.

Says explicitly that approval must come from a KNOWN ADMIN, and why:
an approval any allowed sender could grant would let the agent have its
own request waved through by whoever happened to be in the room.

Also fixes a doc comment this branch misplaced: perform_approved's
explanation had been left attached to ask_approval, so the one function
that runs approved actions was documented as the one that files them.

lytedev merged commit a2f32c97df into main

2026-08-12 15:23:52 -05:00

lytedev deleted branch propose/socket-is-the-assistant

2026-08-12 15:23:53 -05:00