FINDING DIRECTIONAutonomous agents can act independently, but their authority comes from accounts and credentials someone chose to give them.
I was editing this article for Finding Direction in Substack. The dashboard loaded, the draft was there, and the rest of the site worked. The editor said I was offline. Its controls were disabled, and nothing I changed could be saved.
Substack’s status page showed that its writer tools were operational. I reloaded the page and reopened the draft. The editor remained offline. When I disabled the browser extension I use with Codex, the connection returned and the blocks disappeared.
I cannot say whether Substack intentionally rejected the extension, Chrome restricted it, or the extension interfered with the editor. I only know what changed. The editor worked again in the same account and browser immediately after I disabled the extension.
That access was the interesting part. As I develop with Codex, the browser plugin lets me automate some of the tedious work. Codex can browser-test with me and examine the same screen I see when I encounter an error. It can inspect what rendered and help trace the problem back to the code. I installed it for that shared development workflow. The browser session may include access beyond the development task I gave it.
The Authority in a Session
Signing in establishes your identity and what you are allowed to do. Authenticated sessions carry access to private information, account settings, and actions that can affect other people.
A browser agent working inside an authenticated session does not need a separate account with each service. It operates through the authority the browser already has. If the agent fills a field, changes a setting, or submits a form, the service may record the action as mine because my session authorized it.
“Browser access” sounds like a single permission. In practice, it may include the ability to read private information, enter text, upload files, modify settings, publish work, or delete it. The interface gives the user an account. The extension gives the agent a way to operate it.
Access Can Be the Point
That same browser access can serve a very different purpose. People with disabilities already use keyboards, speech recognition, word prediction, and other alternatives to pointing and typing. The Web Accessibility Initiative documents these as ordinary ways people interact with digital products.
Current assistive tools often require the person to translate a goal into a series of interface commands. Apple’s Voice Control, for example, lets someone label the items on a screen and speak commands such as Tap 14 or Show grid. An agent can work at the level of intent. A person could ask it to find a claim, explain what information is missing, move through the form, and enter a response in their own words.
That help matters for someone who has difficulty pointing, typing, reading a dense screen, remembering a sequence of steps, or moving through an interface that changes from page to page. “Finish it yourself” may not be a practical fallback when the agent reaches a blocked control.
Products still need accessible interfaces. Agents provide another way through them for people who navigate, communicate, or process information differently. The challenge is giving the agent enough authority to complete the requested task without quietly granting access to everything else in the account.
Where Authority Comes From
Other autonomous agents use a different arrangement. OpenClaw, for example, can maintain authentication profiles for individual agents using API keys, static tokens, or OAuth credentials. Its multi-agent routing can also separate agents by channel and account. A Discord deployment may give each agent its own bot account. Other integrations may connect an agent to a person’s existing account through OAuth.
A dedicated account gives the agent a distinct identity. Its activity can be logged separately, its permissions can be limited, and the account can be disabled without locking out the person who created it. Those are meaningful improvements over sharing a browser session.
The authority still comes from somewhere else. A person or organization creates the bot, grants access, supplies credentials, funds its usage, and decides which tools it can reach. The account identifies the agent. Its owner determines the authority attached to it.
Delegated credentials can make access more explicit. A service can issue a token that allows an agent to read a calendar without editing it, access one repository instead of every repository, or work for an hour instead of indefinitely. This is closer to what an agent needs: a defined assignment rather than possession of an entire identity.
Approval Is Easy to Spend
The usual compromise is to give an agent broad access and ask for confirmation before consequential actions. That keeps a person involved, but repeated prompts do not guarantee careful review.
Anthropic found that users approved roughly 93% of permission prompts in one of its agent workflows. As the prompts accumulated, people paid less attention to each one. The company began moving safer actions into contained environments instead of asking the user to approve every step. Its account of that work describes permission fatigue as a practical limit on human supervision.
Each approval interrupts the task the user is trying to complete. After the 10th expected request, the button starts to feel like part of the workflow. The person remains in the loop, but the loop has trained them to continue.
Permission Is Part of the Product
In my years working in UX design, permissions were often treated as a screen the user had to get through before reaching the product. Agents make permission part of the product itself. Access determines what the agent can observe, what it can change, and whose name appears on the result.
The agent should receive only the access required for the task. An agent browser-testing an application may need to open a local preview, inspect the rendered page, read a console error, or take a screenshot. It does not need production customer data, billing settings, or deployment credentials. Deploying a change may be relevant, but it carries a different consequence from reporting a broken component.
Those actions should not arrive as one bundle. The person granting access should be able to see the difference between reading, editing, submitting, publishing, and deleting. Access should expire when the task ends. The activity should remain visible, and the person should be able to revoke it without rebuilding the account around it.
OpenAI describes a similar approach for coding agents: low-risk work stays inside clear technical boundaries, while higher-risk actions remain explicit and observable. Its internal deployment guidance treats access, approvals, and telemetry as parts of the same design problem.
The Last Step
Codex helped me build and test my personal site, paulbout.in, where this article lives. It could inspect the local preview, compare the rendered page with the source, and help diagnose errors on the screen. After disabling the extension, I returned to this draft and prepared the newsletter release myself.
The agent helped me reach the last step. I pressed Publish.