We Built An Agent That Broke All of Our Security Rules. Here's What We Learned.

We tell customers three things about securing AI agents: they need their own identities, access that fits the job they’re given, and traceability that’s separate from any human’s.

Then, we built an agent that broke all three by default, and this helped us think through how such agents should be defended.

You need to start discovering agentic browsers and extensions as soon as possible, including the users whose sessions they borrow.

Until browsers and applications can carry agent identity, human delegation, and task scope together, companies should treat every agent using a human session as delegated access that must be discovered, constrained, and audited.

When a browser agent acts inside a user’s authenticated session, the application may see the user but not the agent, the delegation, or the task’s intended scope.

From a security perspective, it’s a typical UI agent that runs in the user’s browser.

Standards are coming, but there are steps security teams can take today, and because Token owns both the agent and the app it runs, we can close each gap from the inside.

By creating an agent that breaks all the security rules, Token learned how companies should be using identity to gain control, especially as agent use scales.

Its job is to answer questions inside the Token platform by doing rather than telling.

And while you can’t tell who clicked, you can choose which clicks need a person by adding a step-up check such as a passkey prompt.

We learned that there are multiple best practices that you can apply when you control the AI agent itself: This works for our own agent, but only because it relies on access that no outside agent has.

The browser can mark when its agent is driving and restrict itself accordingly.