Newshot Article title: Token's self-developed test Agent breaks all security rules, outlining a feasible path for enterprise Agent protection
Body:
When building AI Agent security for customers, we always emphasize three core principles: configure an independent identity for the Agent, follow least privilege when assigning corresponding access permissions, and establish an operation traceability mechanism independent of human users. When Token implemented security internally, it originally followed these three principles strictly as well. That was until we developed our own Agent, which broke all three rules under its default configuration.
This practice helped us clarify the protection approach for this type of Agent. When a browser-side Agent performs operations within a user's authenticated session, the application can only identify the user's identity; it cannot perceive the Agent's existence or the authorization delegation relationship, nor can it determine the expected permission scope of the task. By building this Agent that broke all security rules, Token clarified how enterprises can achieve control through the identity system during the large-scale application stage of Agents. Relevant industry standards are still being developed, but security teams can implement multiple protective measures right now.
The self-developed test Agent should have triggered security interception, yet it runs within the user's browser session
The Agent we developed is called Rehearsal, and its core positioning is to respond to user questions through actual operations within the Token platform, rather than merely outputting text answers. It can autonomously open pages in browser tabs, set filter conditions, and fill out forms.
From a security perspective, this is a typical UI Agent running within the user's browser, and this deployment model is precisely the source of its practicality. But it also means the Agent runs entirely within the user's session context and has exactly the same access permissions as the user.
More critically, the server side corresponding to the page inherently cannot distinguish between Clicks initiated by the Agent and user operations—there is no field in the session Cookie that identifies the actual operator of the current session.
A self-developed, self-controlled Agent and application allows full-chain protection to be implemented internally
Because Token controls both the Agent itself and the application platform it runs on, we can fill the security gaps one by one from the inside. For example, Rehearsal proactively reports the current actual operator to the platform, so the platform can clearly identify the driving entity of the session.
In the fully controllable self-developed AI Agent scenario, we have summarized multiple actionable best practices:
- During Agent operation, dim and lock the application interface to clearly identify the current controlling entity.
- Record all operations within each session, including operations blocked by security policies.
- Set the Agent's permission scope lower than that of the corresponding user. For Rehearsal, we set its permission on the dashboard to read-only; it must not perform any save operation without user approval, will not automatically fill in sensitive fields, and will not initiate any request that has been blocked by the platform. At the same time, Rehearsal can identify dashboard controls through the page's accessibility labels.
This protection mechanism applies only to the self-developed Agent scenario, because it relies on internal access channels that external Agents simply cannot obtain.
Third-party Agent security requires multi-party collaboration, and existing standards still lack a connecting middle layer
The reason we can configure a clear operating entity, permission scope, and page mapping for Rehearsal is that it is a product we fully developed ourselves. But third-party browser Agents that operate CRMs or cloud consoles do not have these configuration conditions at all. Applications cannot perceive the existence of such Agents, and the Agents cannot identify which field is a sensitive field or which button will trigger a record deletion operation; the entire session carries only the user's identity credentials.
The core idea for solving this problem is to create a separate operating channel for Agents that is independent of human users. The Web ecosystem has already begun building such channels, but the overall approach has not yet formed a systematic, global design.
On the browser side, markers can be added when an Agent is operating, and restriction policies can be enforced accordingly. For example, Chrome's auto-browse feature requires manual user confirmation before triggering high-risk operations such as payments or mass emails; it limits the Agent's access scope to the sites required for the task, and marks pages visited by the Agent in the user's history. Microsoft, meanwhile, supports administrators enabling Agent-driven browsing mode on a per-site basis, automatically pausing Agent operations before the user enters a password or bank card number.
On the application side, applications can encapsulate their own operations as standard tools exposed externally. Google and Microsoft are leading the drafting of WebMCP within a W3C community group, which supports sites exposing operation interfaces that Agents can directly call, while marking each interface as read-only or with a high-risk impact level. This way, Agents do not need to guess the actual function corresponding to a button.
On the Agent side, Agents can sign the requests they initiate. The IETF working group is currently drafting Web Bot Auth, which supports sites in verifying the specific Agent identity that sends a request.
What is currently missing is the middle layer that connects these three parties. Each participant holds information that is not shared with the others, and there is no mechanism to transmit information between them. The browser knows that an Agent is currently operating the session, but neither Chrome nor Edge has defined how to inform the application on the other side of this information. WebMCP tools run within the user session and inherit all of the user's permissions, so they cannot by themselves narrow the Agent's access scope. Web Bot Auth can identify the Agent's identity, but the draft explicitly states that it does not cover delegated authorization scenarios, so it cannot associate the actual user whom the Agent serves.
Ultimately, applications can only obtain fragmented contextual information and cannot form an actionable basis for authorization decisions.
The current pace of Agent adoption far exceeds the pace of standard-setting, and merely adapting features for Agents is far from enough. Every operating channel built for Agents must carry three core pieces of information: the Agent's own identity, a verifiable delegation link between the Agent and the user it serves, and a task scope smaller than the user's permissions. Together, these three pieces of information constitute the minimum context an application needs to make authorization decisions. Without this information, the fast lanes built for Agents will only become fast lanes for privilege abuse.
Security teams can start Agent protection immediately without waiting for industry standards to land
Waiting for standards to fully take shape before starting protection is not advisable. Enterprises need to promptly inventory all Agent-driven browsers, extensions, and the users to whom these tools' borrowed sessions belong. Although enterprises cannot identify who initiated a Click, they can add secondary verification steps such as passkey prompts to explicitly require that Clicks in high-risk scenarios be confirmed by the user in person.
- Inventory all browser Agents, Agent-type extensions, and endpoint Agents that can perform operations through authenticated sessions, and establish a mapping between these tools and the corresponding users and responsible entities.
- Conduct full-chain traceability of the user of each AI Agent, clarifying the user corresponding to each Agent (including other Agents that call it).
- Investigate all identity permissions accessible to each Agent.
- Identify potential attack paths that use Agents to bypass access controls.
- For sensitive operations or irreversible application operations, require explicit user approval or completion of secondary identity verification.
- Require core SaaS vendors to clearly answer: whether their audit logs can distinguish Agent operations from human user operations, and whether they support task-scope-based delegated authorization.
Until browsers and applications implement the connected transmission of the three types of information—Agent identity, user delegation relationship, and task scope—enterprises should treat all Agents that borrow human user sessions as delegated access scenarios, and achieve comprehensive discovery, permission constraints, and operation auditing for such access.
We Built An Agent That Broke All of Our Security Rules. Here's What We Learned.