Approvals and the trust check

Before nod runs an action in a connected app, or a step in its browser that could send, submit or change something, the nod server asks one checker whether you asked for it. For work you request, reads and drafts run by default unless your instructions forbid the action or require confirmation first. Anything else runs only when your words ask for it. Otherwise nod asks you.

Your request covers its steps

Ask for an outcome and nod takes the steps it needs, in the apps, accounts and websites you named, up to the order, booking or message you asked for. You aren't asked about each step on the way.

You say	Runs without asking	Waits for you
"Buy the Voice Preview Edition from Dílna Novák"	Cookie banner, add to basket, delivery choice, the shop's terms, the order	Paying by card, with your security code. A subscription, a new account, a message to the shop, another shop
"Book a table for two at Tasca tonight at 8"	Picking the time, entering your name, confirming the booking	A deposit paid by card, another restaurant
"Move my 3pm with Lena to Thursday and tell her"	Moving that event, emailing Lena the new time	Emailing anyone else, changing or cancelling another meeting

Nothing past the outcome is covered: another website or recipient, a subscription or another purchase, a new account, publishing, deleting something you didn't name, changing your account or its settings, or sending your details for anything the job doesn't need. When nod proposes a plan and you say yes, your yes covers each step of that plan.

The same checker decides when nod changes its own schedules, notification settings or spending limits, forgets a note, or turns memory on, off or clears it. A scheduled run is checked against the instruction that created it and its scheduled time, and background work against your standing instruction. Saving a note has its own rules: see Memory.

Work nod starts on its own, such as on a new email or a check of an app without events, runs only once you've told nod what to watch for. It has only your standing instruction behind it. So the checker lets it read and draft and do what that instruction asks. nod asks you about everything else. nod doesn't keep a list of approved people: a send you confirmed earlier doesn't approve a later one by itself.

What the checker sees

The checker is your selected model at its fastest setting. It checks every app action, reads included, and answers one question: run it, or ask you? Looking up which app tools exist reads no account data, so it runs without a check. With a local model, the checker is that model, and smaller models decide less reliably.

Reading your reply to a confirmation can use a decision model instead. See Decision checks.

It sees	It never sees
For main chat, your last five messages from the past day and the source request	Tool results, web pages, emails or files
The nod message your latest one answered, not as proof of what you saw or approved	Anything nod read while working
A scheduled run's instruction and run time, instead of your messages	Task cards you tapped on your first chat, even when they started a schedule
The action and its arguments as nod sends them	Other people's words as yours
For background work, your standing instruction, instead of your messages
How a schedule or memory note nod would change stands now

For a saved task, the checker sees your recent chat messages as they stood when the task started (the same ones the chat's check saw then, never later chat messages), the request that led to it with your answers to nod's questions, and recent owner messages addressed to that task. It does not use messages addressed only to another task. The nod message your latest one answered is the one you replied to, or else the latest nod message in that channel before you wrote, from the last 24 hours; a task's checker sees it only when it is that task's own message, so a yes nod passes on to a task never answers a question that task didn't ask. The main chat also excludes task-only messages and task action proposals from its recent authority. Shared memory, files, task briefs and other task reports do not grant permission. An approval remains bound to the exact action and turn. A reply continues the session that asked. A correction to a task closes its old waiting turn, so its old pending action cannot execute from a later approval reply.

Only your words carry authority. A web page or email can't argue for an action, because the checker never reads it.

What runs directly

Limits in your task request, a schedule's instructions or your standing instruction override these defaults, including for reads and drafts.

Kind of work	Reads and drafts	Anything else
A conversation with you	Run	Run if your request covers it
A scheduled run	Run	Run if the schedule's instruction asks for it
Background work nod starts, such as on new email	Run	Run if your standing instruction asks for it

flowchart TD
  action[App action] --> check{{Checker: allowed without<br/>your confirmation?}}
  check -- yes --> run[Run it]:::go
  check -- no --> ask[Ask you]:::accent

If the checker can't answer, nod requires confirmation. If the model can't write or check that confirmation, the action stays blocked. nod sends the complete request and never cuts it to fit a model limit. A request that exceeds the decision service's limit fails the check. A failed check does not switch to another model or service.

Browser steps

On websites, the same checker decides each step that could send, submit or change something: a click, a key press, choosing an option, ticking a box, a drag, a file upload, accepting a page dialog, or a script that changes the page. Opening a page, reading it, typing into a field without pressing Enter (including single characters pressed into a text field), and read-only scripts skip the checker. Typing skips it even on a page that saves as you type. A download from a link just follows its address. A download from a button is a click, so the checker decides it too.

The checker sees the website, the page address, the control as the page labels it, where a drag drops, any dialog text or file name, and what nod typed or chose on that page. When a click on a submit button or its label, or Enter in a form field, would send a form, it also sees the method and address the browser would send it with, read from the exact element the click lands on. That shows where a vaguely labelled button really sends, as far as the address says what it does; the checker is also told that the page's scripts may handle the form instead. When the browser can't read the form, the checker is told it's unknown. A control that acts through page scripts without a form, such as a list that sends itself when you choose an option, shows no form, so the checker judges it by its label. It never sees the page's text. Following links, searching, filtering, opening or closing a popup, any choice on a cookie banner, adding to a cart, and moving through a form before its final step count as reading, so they run without asking you unless your instructions say to ask first. Cookie choices stay in nod's own browser, never yours, and nod picks the option that shares least. Submitting a form's final step, sending, posting, ordering, paying, booking, deleting, and changing your account or a setting that saves at once count as acting, and run only when your words ask for them or for an outcome they're part of. A control without a label runs only while nod is getting something done on that website for you, such as buying or booking there, and only when even the worst it could do stays within that. For a question or a lookup, nod asks.

When the checker asks, the question names what the page shows, such as the amount and payee: the question writer and its fact check read the page's visible text, which the checker itself never sees. Your yes approves that one step. nod runs it once, only while the browser is still on the same page, the control is still there and it still sends the same form. If the page moved on, nothing runs and nod looks again. A subagent can't ask you, so it hands the step back to the main task.

Standing instructions

Tell nod what to do on its own when something arrives, and background work does it without asking. For example: "Whenever Ana sends an invoice, forward it to accounting@acme.com."

nod offers. When you act on something background work brought you, such as asking nod to reply, and it will come up again, nod offers once to do it without asking next time.
It sits with what nod watches for. nod keeps it next to what you've said is worth interrupting you for. When nod changes it for you, the same checker sees what you set before, so nod asks before it adds anything you didn't ask for.
The checker sees only the instruction and the action. It never sees the email or update that started the work. An action that matches the instruction runs. Anything else, such as a forward to a different address, asks you. It never covers a change to nod's own schedules, settings, limits or memory.
See, change or stop it in Trust → Activity, or tell nod, for example "stop forwarding Ana's invoices". The next action is checked against what you set.

The confirmation

The same selected model writes the question from a frozen copy of the complete action, its arguments and account details. It explains what will happen and why nod is asking, preserving the material facts in your conversation language. It names the website, account and recipient as the action does, not by what you called them, and adds nothing from the conversation, such as that it repeats an earlier attempt. So a lookalike site can't hide behind the name you used. There are no language-specific confirmation templates or yes/no word lists.

Before showing it, a separate fact check by your selected model compares the question with those frozen facts without seeing the conversation. The writer and the fact check receive a sanitized copy of the request, with secret-keyed values and private links redacted. When sanitizing hides a value, both calls are told which fields are hidden, by name and never by value, and the question has to say that part of the action is not shown; a question that presents such an action as complete is rejected. A requested value cannot fill in a missing action argument, and current account or target details cannot replace a proposed change. An unsupported claim, an invalid response or an unavailable model leaves the action blocked. These model calls add time and cost; the factual check is also a best-effort judgment.

Your recent messages and explicitly stated remembered preferences guide presentation only. An explicit output-language request applies to that output, and a short reply keeps the established conversation language. Quoted material, account names, region and time zone don't select the language. After a reset, your new messages and any remembered preference guide it again.

Generating a question doesn't approve anything. The server checks the task again after generation, then saves the question and exact arguments together. Stop, cancellation, invalid model output or an unavailable model can't produce a late approval. The model never chooses the account or changes the saved arguments while writing the question.

Your reply answers the newest question you'd seen, not one that arrived after it.
A later status message in the same reply channel blocks a bare yes. A status in another channel does not block it. On web, a message that arrived after your displayed view does not replace the question you saw. Reply directly to the question to select it.
A separate check reads only your reply, never the question or the action, and decides whether it says yes, no or something else. It uses a decision model when one applies, otherwise your selected model. Any wording or language works, such as "sure, go ahead" or "dale". If it can't read your reply, the question stays open.
A yes with a change or condition, a question, an attachment or anything else closes the question without running the action. If you reply directly to a question from background work, that work continues with your message, so you can tell it what to change. Otherwise the task that asked ends and nod treats your message as a new request. A reply to a question that was already answered or whose task has ended is an ordinary message.
A yes runs that exact saved action once, on the account shown. A different recipient or payload needs a new question. If the action can no longer run or it fails, the task continues with the reason and doesn't run it again. If nod tries the same action again for that request, it gets the first result, or a refusal while your answer is pending, after a no, or while the outcome is uncertain.
Schedule edits and cancellations apply only to the reviewed version and need a fresh review if the schedule changes.
Within one task, including any subagents it starts, nod asks one question at a time. While it waits for your answer, app actions that task started after the question don't run, and nod can try them again after you answer. Separate tasks, such as two scheduled runs, can each wait on their own question.

sequenceDiagram
  actor You
  participant nod
  participant Server
  participant App as Slack
  You->>nod: Tell the team the report is ready
  nod->>Server: Post in the team channel
  Server->>Server: Checker: not clearly asked
  Server-->>You: Slack: send message? Account, fields, why
  You->>Server: yes
  Server->>App: Run the saved action once
  App-->>nod: Result, marked as data

Where this is enforced

Part	Source
Trust check and checker	`src/server/trust.ts`
Confirmation text	`src/server/communication.ts`
Confirmations, run once	`src/server/approvals.ts`
Browser steps	`src/runtime/tools.ts` and `src/providers/agent-browser/index.ts`