Phantom already knew how to listen, see the browser, and act. The real challenge was turning that local agent into a system that could use connected accounts, delegate safely, and expose authority instead of hiding it.
By Younes Laaroussi
Phantom started as a browser-native agent. You talk, it reacts, and the extension takes care of the visible work: reading the page, clicking, scrolling, opening tabs, and moving through the browser with almost no friction. That part was already compelling. What was missing was a trustworthy answer to a more serious question:
What gives it the right to act for the user outside the tab?
That question changes the architecture immediately. A browser extension can hold state, but it is the wrong place to improvise long-lived authority. As soon as Phantom started reaching into Gmail, Calendar, Docs, Sheets, Tasks, and Linear, “the extension has access” stopped sounding clever and started sounding irresponsible.
The project became more interesting when I stopped treating authorization as a detail. Instead of asking how to cram more power into the local agent, I asked how to split the system so the local part remained fast and intimate while the authority layer became visible, scoped, and reviewable.
That is where Auth0 changed the direction of the product. Phantom did not stop being a local browser companion. It stopped pretending that local execution should also be the source of truth for identity, connected accounts, provider access, and approval.
Runtime split. The extension stays local. The hosted companion and gateway become the authority surface. Auth0 owns connected accounts, delegated access, and approval. Providers stay downstream instead of being smuggled into browser state.
Auth0 turned Phantom into a delegated system instead of a clever extension
The first concrete shift was connected accounts. Provider login should not be a side effect of whatever tab the user happens to have open. With Auth0 Token Vault, Phantom can connect Google and Linear through a proper authority layer, which means the browser extension no longer needs to own raw provider credentials or fake its way through session cookies and copied tokens.
The second shift was visibility. The companion is not there just to look nice. It is the surface that tells the truth about the system: which accounts are connected, which actions are pending, which high-risk operations need approval, and what has already happened. That interface matters because it translates invisible authorization state into something a user can actually inspect.
The third shift was approval. Reads can stay lightweight. Mutating actions should not. Creating calendar events, sending mail, and opening real work in external systems should step up into explicit approval instead of feeling like silent model behavior. Auth0 Guardian gives that moment a real boundary.
The product got better when it became less magical and more legible.
Here’s the core of what changed:
Token Vault
Provider authority moved out of the extension.
Google and Linear now sit behind Auth0’s connected-account flow instead of leaking into the browser runtime as an implementation shortcut.
Companion
The system exposes status instead of hiding it in prompts.
Connected accounts, pending approvals, and delegated action history are all visible in one place, which makes the app easier to trust and easier to demo honestly.
Guardian
High-risk actions gained a real consent boundary.
Approval is no longer a narrative flourish. It is an actual gate in the runtime, tied to the user and reflected in the system’s action state.
The interesting part is not that Phantom can act. It is how those actions travel.
Once the agent asks to do something meaningful, the request moves through a chain that makes sense. The extension initiates the action. The gateway performs provider-specific work. Auth0 sits in the middle as the authority layer. The companion shows the resulting action record. If approval is required, that request becomes visible before the mutating step can finish.
That gives Phantom a much stronger operating model than “the AI did something in my browser.” It becomes possible to say exactly what happened, where it happened, and why the system was allowed to proceed.
Delegated action flow. The browser agent initiates work locally. The hosted gateway handles provider calls. Results return as action records rather than disappearing into conversational state.
Authority lanes. Phantom remains the local interface, but Auth0 becomes the durable authority layer between the agent and downstream providers.
Step-up approval is what makes the product feel responsible
A useful agent should not force the same friction on every action, but it should absolutely create friction when the user’s behalf is being asserted in a consequential way. That is the point where Auth0 stops being a backend convenience and becomes product substance.
The approval loop matters because it is easy to explain:
- The user asks for an action.
- Phantom prepares it.
- Auth0 requests approval.
- The user approves on their own device.
- The action completes.
- The companion records the outcome.
That sequence is a lot less flashy than an unconstrained agent, but it is much closer to something people could actually live with.
Approval loop. The system becomes more trustworthy when the approval step is visible, attributable, and tied to the final action record instead of being treated like invisible middleware.
Why this architecture feels right
What I like most about the final shape is that it keeps both halves of the idea intact. Phantom still feels like a local companion. It speaks, watches, and acts in the browser without turning into a remote dashboard. But the authority behind it is no longer improvised. Identity, connected accounts, delegated access, and approval now live in the right place.
That split is the real product.
Local execution gives the system immediacy. Auth0 gives it discipline. One without the other would either feel weak or unsafe. Together they make a browser agent that can do real work without pretending that permission is somebody else’s problem.
Phantom is still the same spirit at the edge of the browser. The difference is that now it has a visible authority model behind it. That is what turned it from a neat interaction demo into a system I can explain with a straight face.
Top comments (0)