n8n has released Nod, a standalone personal agent designed to run on a user's computer rather than inside the core n8n product. Its browser architecture is central to the product: Nod works in its own private virtual machine and Chromium-based browser container, separating agent activity from a person's everyday browser sessions. That design is intended to let Nod carry out browser-driven work while placing saved credentials, payment cards, and other secrets under on-device Vault controls.
According to n8n's official Nod announcement, the agent has its own computer and browser. The practical distinction matters for anyone considering browser automation. Nod does not simply take over the browser already open on an employee's desktop. It uses a separate environment with its own saved profiles and controlled access to sites, credentials, and actions.
Nod is therefore not just a chat interface that can browse. It is an agent environment built to interact with websites and applications after users grant the relevant permissions. The available documentation presents that separation as a safety boundary for work that may require access to accounts, sensitive data, or payment details.
How Nod separates browser activity and credentials
Nod's browser runs in a container separate from its workspace, and each browser session uses a saved profile. This means activity in Nod is isolated from the user's personal browser, including its existing sessions. A user can allow Nod to use a saved browser session for a specific site, but the agent does not inherit the session state of Chrome, Safari, or another browser used personally.
| Area | Nod browser environment | User's personal browser |
|---|---|---|
| Browser context | Chromium-based browser in a separate container | Separate from Nod's browser container |
| Signed-in access | Can use approved saved browser sessions | Its existing sessions are not inherited by Nod |
| Saved profiles | Each Nod session uses a saved profile | Not used as Nod's session source |
| Credential handling | Vault verifies and privately fills approved credentials | Personal browser credentials are not the stated Nod mechanism |
The Vault is the other major component of this model. It can store logins and cards on the device and determine how Nod may use them. When Nod needs to sign in, the Vault verifies the relevant account against the target site and fills the credentials privately. The model does not receive the password, code, or card details.
That distinction is important because browser automation can otherwise create an uncomfortable trade-off: an assistant may need access to an account to complete a task, while the account owner does not want to expose the underlying secret to the AI system. Nod's documented design aims to separate the ability to use an approved credential from the ability to view it.
Nod also supports saved browser sessions. For permitted sites, this can allow the agent to reuse a signed-in session in its own browser environment. It is a more deliberate path than copying the cookies or session state from a person's regular browser, and it gives users a clearer boundary around where the agent is authenticated.
What this changes for browser-based automation
For teams, the value is not merely a second browser. Browser tasks often remain manual because important business tools live behind a login, do not offer a suitable API, or require a sequence of page interactions. An agent that can operate in a separate browser context may be useful for repetitive, permissioned work across web applications while avoiding direct dependence on a worker's everyday browsing profile.
The architecture also creates a clearer operational distinction between a user's normal web activity and agent work. If an organization uses Nod for approved tasks, saved sessions and credentials can be scoped to the agent environment rather than being implicitly drawn from a personal browser. That can make it easier to decide which accounts and actions the agent should be allowed to use.
Nod's documentation describes a controlled, model-facing view of browser observations. Webpage content is subject to trust checks, while actions are governed by user approvals. In other words, the agent may inspect information presented on a page, but that does not make every instruction on that page trustworthy or every possible action automatically permitted.
This is particularly relevant to prompt injection, where untrusted content on a webpage attempts to influence an AI system's behavior. Nod's policy treats web content as untrusted and constrains actions through trust checks and confirmation requirements. The approach does not remove the need for users to review permissions, but it establishes safeguards around what page content can cause the agent to do.
Cookie banners are not documented as automatic handling
The originating description suggested Nod can automatically handle cookie banners or dialogs that cover a button. The current official materials support a narrower conclusion. Nod can inspect what appears in its browser environment, but the documented trust model emphasizes explicit user confirmation and checks before actions. The documentation does not establish a feature that automatically accepts cookie banners, dismisses dialogs, or grants permissions without user input.
That is a meaningful difference for implementation planning. A browser agent may be able to identify a banner or prompt that blocks a workflow, but businesses should not assume it will silently consent to tracking, accept terms, or bypass a permission request. Those choices can carry legal, commercial, or security consequences, so Nod's confirmation-oriented design is consistent with keeping the user in control.
Scalevise CTA: Browser agents can reduce repetitive web work, but the useful deployment question is which tasks, accounts, and approvals should be connected first. Scalevise helps businesses turn promising agent capabilities into controlled workflows that save time without exposing sensitive processes. Our team can assess where browser-based work fits alongside APIs, existing tools, and human review, then build a practical rollout plan through AI workflow automation services. Discuss an AI automation project with Scalevise.
Frequently Asked Questions
What is n8n Nod?
Nod is a standalone personal agent released by n8n that runs on a user's computer. It operates in its own private virtual machine and uses its own browser rather than the user's regular browser.
Does Nod use my existing personal browser sessions?
No. Nod does not inherit sessions from a user's personal browser. It can use saved browser sessions for allowed sites in its own browser environment.
Can Nod see passwords, verification codes, or payment cards stored in Vault?
Nod's documentation says Vault keeps saved logins, codes, and cards on the device and does not reveal them to the model. Vault verifies and privately fills approved credentials when needed.
Does Nod automatically accept cookie banners or website permissions?
Current official documentation does not establish automatic cookie-banner acceptance or permission granting. It describes trust checks and explicit user confirmations for actions involving untrusted page content.
Conclusion
Nod's defining feature is not simply browser access. It is a separated agent environment that combines an isolated Chromium browser, saved profiles, Vault-controlled credentials, and user-governed actions. For browser-based automation, that creates a more deliberate way to authorize work across sites while keeping personal browser sessions and sensitive secrets outside the model's view.
Top comments (0)