Our trust principles

An assistant that acts for you is only worth having if you can trust it when you're not watching. These are the seven commitments Nod is built on.

Most assistants ask you to trust the company behind them. Nod's rules are enforced by a server, not by a model's good behaviour. They run where you choose, in code you can read, and they leave a record you can check.

1. Authority comes only from you

Nothing Nod reads can give it permission.

2. The model never sees your secrets

Passwords, codes and card numbers stay out of it.

3. Exact actions, run once

You approve one specific action. It never repeats on its own.

4. You can see everything

Every use, cost and app action is on record.

5. Your computer, your model

Nod runs where you choose, with the provider you choose.

6. Open by default

Open source code. Analytics off until you opt in.

7. Honest about limits

Every control says what it doesn't cover.

Layers, not a single gate

No single check makes an AI assistant safe, so Nod stacks independent ones. The model's judgement is the first layer, never the last.

flowchart LR
  you([Your request]):::accent --> model[Model<br/>plans, asks when unsure]
  model --> trust[Trust check<br/>exact action or step]
  model --> vault[Vault<br/>task, account, website]
  trust --> world[Apps and websites]
  vault --> world
  trust --> record[(Record you can read)]:::accent
  vault --> record

1. Authority comes only from you

Web pages, emails, files and app results are data. Only your messages, the instruction that created a schedule, your standing instructions, your rules and your explicit approvals can authorize an action, and Usage shows the words behind each action they allowed. A rule that says to ask first makes Nod ask even when your request covers the action.

• Reads and drafts run. Anything else needs authority from you: your request, or your yes.
• Your request covers the steps it takes and stops there. "Buy it from that shop" covers the cookie banner, the basket and the order there. "Move my 3pm and tell Lena" covers the event and the email to Lena. Neither covers anything else.
• Asking for help with a problem leaves Nod free to read and prepare. When you haven't chosen the outside commitment, Nod asks before sending, submitting or booking. A short yes can accept a concrete proposal; advice listing possible remedies isn't one.
• When intent must be judged, a separate review sees only your messages, your rules and the action, never the content that suggested it.
• Work Nod starts on its own can only read, draft and do what you told it to do on its own.

How approvals work →

2. The model never sees your secrets

The model picks the account and the fields. The server fills in the value.

• Vault checks the task, the account and the website's exact origin before it uses a saved value.
• The value is typed into the verified field privately, and masked in everything the model sees afterwards.
• Model provider keys never enter the sandbox, the browser or a prompt.

How Vault works →

3. Exact actions, run once

An approval isn't a general "go ahead". It binds one action with its exact arguments.

• Changing a recipient, an amount or a payload needs new authority.
• A saved claim makes sure an approved action can't run twice, even after a double tap or a crash. If Nod tries the same action again for that request, it gets the first result.
• No action is retried automatically. If the outcome is unclear, Nod says so, and you check before anyone tries again.

One use, one result →

4. You can see everything

The full record is for every user, not an enterprise add-on.

• Usage shows what every request cost, every app change, send or deletion that ran, and every use of a saved item, question and held attempt.
• A monthly spending limit stops new work before the next model call. A task checks in with you once its spending since your last message passes the check-in amount you set.

Spending and usage →

5. Your computer, your model

With a local desktop or source install, Nod's server, database, workspace and browser run on your computer. With a self-hosted server, they run on that server, and your web or desktop clients reach the same assistant.

• You bring your own model provider and pay it directly.
• Commands run in a sandbox with no access to your files or keys.

Your data and privacy →

6. Open by default

You shouldn't have to trust a security claim you can't check.

• Nod is open source under the Apache License 2.0, including the trust check, Vault and their tests.
• Usage analytics stay off until you turn on Share usage data, and recordings never show your content.
• Conversation traces stay off until you turn on Share conversation traces, and Nod removes personal details before any leave.
• Feedback reaches its configured recipient only when you send it. A diagnostic report is selected by default, with an exact preview and an option to leave it out. Redaction can miss personal details, so review it first.

Analytics and recordings →

7. Honest about limits

Security that overstates itself is worse than none, because people rely on it.

• The review is a best-effort judge and can be wrong.
• A website receives the values you let Nod submit, and can keep them.
• The Nod server can read saved values while it uses them.

Security model and limits →

Related resources

How Nod comparesNod next to other assistants that act for you.

Security review guideData flows, controls and evidence for security teams.