Agentic Browsing Safety: Sessions, Permissions, Ask-First Rules
Maker's note: 기준일 2026-10-03. We're the AZET team. This is a plain-language safety guide to agentic browsing — sessions, permissions, and the actions that should always wait for a human — grounded in what we've actually built in the Azet app (version 0.3). Current as of October 3, 2026.
"Agentic browsing" — an AI agent using a browser on your behalf — is moving from demo to daily tool, and the safety conversation around it is still mostly engineer-only. It shouldn't be. If you're going to hand a program your logins, you deserve to understand the mechanics in plain words. This is that explanation, written by the team building one, with our own design choices as examples and our own limits stated as limits.
What an agent actually holds: your session
The agent doesn't need your password; it needs your session — the cookies and stored state a browser keeps that say "this is a logged-in user." Hand those over and, as far as websites can tell, the agent is you. That is the source of both the convenience and the risk, and it's why the first questions to ask any agentic browser tool are session questions. Does it use separate browser profiles, or does it share the one you browse in? What persists between runs — logins, cookies, history? In the Azet app, browsing runs in per-profile Chromium sessions with their own stored state, so a work context and a personal context never share a cookie jar, and what each session keeps is documented rather than discovered.
Permissions: shrink the blast radius first
The second question is what the agent may touch. A browser tool that can also read and write your filesystem needs a boundary, and "be careful" isn't one. Ours works like this: by default, an agent's file access is confined to that profile's own workspace folder, and attempts to escape it — path tricks, symbolic links — are refused. There is a wider mode, and its name is a warning we chose to keep honest: "full access" sounds absolute but isn't. It widens the scope within the app's own project and still requires both an authenticated grant and an explicit runtime option. No mode we ship amounts to "run any command on this machine."
The ask-first list
Some actions are cheap to undo and some aren't. Our rule is that the second kind always stops for a human. In the Azet app, that's enforced by a desktop confirmation showing the profile, the target, and the complete body of what's about to be sent — matched by a digest, so what you approve is provably what goes out. A value set inside the agent's own code cannot approve anything; only a person at the desktop can.
| Action | Why it waits for you |
|---|---|
| Sending a message, email, or post | Goes out under your identity; can't be unsent |
| A payment or checkout | Money moves; errors are expensive |
| Deleting data | There is no undo |
| Changing account settings or passwords | Can lock you out or weaken security |
| Writing files outside the workspace | Widens the blast radius silently |
Secrets stay secret
A browsing agent will meet your passwords and one-time codes, so the design question is what happens next. Ours: credentials are used for their intended input and never appear in results, logs, or screenshots; the macOS helpers respect the operating system's permission prompts rather than routing around them; and there is deliberately no feature for rummaging through arbitrary password storage. The one-time code that authenticates a step should not become part of that step's transcript.
Every run needs brakes
Unlimited autonomy is a bug in clothing. A run should have a budget (ours accounts model use in credits and can be capped per task), a ceiling on steps, a stop when it starts repeating itself, and status output roughly every sixty seconds so a human can see what's happening. It should also have a genuine stop and steer: you can cancel a session mid-run or replace its remaining plan, and actions whose outcome is unknown are never retried automatically, because "try again and hope" is not an acceptable strategy for side effects.
The honest limits
Three things we don't claim. The app is not a sandbox against malicious local software — another program running as your user is an operating-system problem, not one we solve. The hosted decision service the app can use is currently limited to allow-listed test accounts, not open to everyone. And some approval-gated send paths have been built and gated but not exercised end-to-end against real personal accounts — we say so rather than rounding up. One more line worth restating from our engineering side: text models produce text only in this app; they cannot emit executable browser actions.
FAQ
What is agentic browsing? An AI agent operating a browser on your behalf — opening pages, reading them, filling forms — using a logged-in session rather than your password.
What should an agent never do without asking? Send, pay, post, delete, or change account settings — actions that are irreversible, spend money, or go out under your identity.
How does the Azet app enforce that? Risky actions stop at a desktop confirmation showing the profile, target, and full body of the message, matched by a digest. Code running inside the agent cannot approve them.
Is the Azet app sandboxed? No. It confines file access and never exposes its control interfaces to web content, but it is not a defense against other software running as your user.
The short version
Sessions, permissions, ask-first, secrets, brakes — five checks that fit on an index card and apply to any agentic browser tool, ours included. The assistant being built behind the waitlist at https://azet.io is intended to inherit this same discipline, and these notes are where we'll keep saying so.