Who may talk to it

Your bots are on public networks. Anyone who finds the username can send them a message, so who is allowed to reach an agent is a real setting rather than an afterthought.

The three postures

[security.access] mode, daemon-wide:

pair (default)	An unknown sender is told a short code and dropped. You approve the code and they are remembered, on disk, permanently.
allowlist	Only listed ids get through. Everyone else is dropped in silence — no reply, no error.
open	Anyone. Only sane for a daemon with no chat gateway at all.

The usual path is to set up with pair, then switch to allowlist once the people you want are in. Senders already approved keep talking; everyone else is dropped at the gate.

open is not offered as a choice in the dashboard. It is a posture the daemon warns about, so it is surfaced as a warning when in force rather than presented as an option.

Approving someone

They message the bot and get a code. You approve it:

nouride access                    # who is waiting, and who is already in
nouride access approve <code>
nouride access deny <gateway:sender>
nouride access revoke <gateway:sender>

Or from Agents → your agent → Access in the dashboard.

A code lasts 15 minutes — long enough to forward, short enough not to linger. There is also a cooldown on “I do not know you” replies, so a stranger cannot make the daemon answer every message they send.

This is not the approvals queue

An approval is an agent stopped mid-turn wanting to run a command. Access is a person asking to be let in at all. They live in different places on purpose. The failure that made this explicit: a bot told someone to approve a pairing code, the dashboard’s approval list was empty because that list is for tool calls, and the fifteen-minute code expired while they looked for it.

The switch above the agent cards

In the dashboard the pairing mode is one switch — Accept new senders — and it sits on the Agents index, above the cards, not on any one agent’s page.

[security.access] mode is daemon-wide. A switch inside Nouva’s card would look scoped to Nouva and silently change what every other bot answers, which is how you lock six bots out at once. Each agent’s Access page states which rule is in force and links to where it is changed.

Pending pair requests do stay per agent, because approving one is a decision about a person on that agent’s gateway.

The switch is live: the next inbound message is judged by the new setting, with no restart.

Pre-approving people

allowlist is honoured in every mode, so it is how you let somebody in before they have ever written:

[security.access]
mode = "pair"
allowlist = [
  "123456789",                    # bare id
  "telegram:nouva:123456789",     # fully qualified
]

Reach for the qualified spelling when one daemon runs bots on more than one platform: a Telegram id and a Discord snowflake are both numeric, and a bare id can match on the wrong one.

Per-agent restriction

The daemon-wide rules decide who may reach the agents at all. One agent can be narrower:

.nouride/agents/nouva/config.toml

[security]
sender_allowlist = ["telegram:nouva:123456789"]

Empty inherits the daemon allowlist.

Names, not ids

An agent that knows a chat id knows nothing useful. People ties an id to a name and some notes, and those facts land in the prompt so the agent addresses somebody properly.

nouride people                                        # who the agents know
nouride people set telegram:nouva:123456789 --name "Rina" --note "Gading's wife"
nouride people forget telegram:nouva:123456789

Or the People page in the dashboard, or the agent’s own person_record tool.

In config it is a [[people]] array — one entry per identity, and one person can have several. On WhatsApp in particular the same human shows up under two ids (…@s.whatsapp.net and …@lid), so both get an entry:

[[people]]
id    = "whatsapp:main:628123456789@s.whatsapp.net"
name  = "Rina"
notes = "Rina Mardiana, Gading's wife."

[[people]]
id    = "whatsapp:main:91805060202719@lid"
name  = "Rina"
notes = "Rina Mardiana, Gading's wife."

This survives /new. Facts in [[people]], in an agent’s USER.md and in its MEMORY.md are permanent; the conversation is not. If an agent keeps forgetting who somebody is, the fact belongs in one of those three rather than in the chat.

Empty is a real value

An account with no name set means nobody has said what to call that person, and the agent then uses no name at all rather than falling back to a login handle. This is the fix for a real bug: setup used to ask “what should the agent call you”, wrote the answer into a file every agent read for every conversation, and greeted the second person to message the bot by the first person’s name.

Dashboard accounts are separate

Who may sign in to the dashboard is a different question from who may message a bot. Accounts and roles live under Users, admin-only, and a person cannot change their own role or delete their own account — demoting the last admin from their own browser would lock the instance out of account management.