AI Agent State Lab: Tamper the Saved Role to Reach Admin Code

This article describes a security lab demonstrating how AI agents that persist state in client-side storage can be exploited by tampering with privilege fields. StateBot stores its role as a JSON blob in browser storage and trusts the role field on reload without verification, allowing an attacker to change 'user' to 'admin' and unlock protected functionality. The lab illustrates a classic broken-access-control vulnerability reappearing in modern agent architectures.

• StateBot's stateless trust mechanismStateBot persists {role: 'user'} in client storage, reloads it on every request, and branches its behavior based on the role value. The role field determines whether the agent takes a normal path or unlocks an admin-only get_secret_config path. Critically, the blob is neither signed nor re-verified after reload, so an edited role field is immediately trusted.
• Attack requires three simple stepsAn attacker locates the persisted JSON state in client storage, edits the role field from 'user' to 'admin', and then triggers a request so the tampered state reloads. When the agent branches on the now-admin role, it executes the get_secret_config path and returns the secret configuration, completing the exploit.
• Client-held state is inherently attacker-controlledThe core vulnerability stems from storing authoritative privilege information where the user can edit it. Any field that controls behavior or access decisions must either remain on the server or be cryptographically signed and verified on every load. Selective signing of only certain fields leaves unprotected fields like role editable.
• Connection to Excessive Agency in LLMsThe article identifies this as enabling Excessive Agency (LLM06), a vulnerability where users flip an agent's privileges by tampering with reloaded state. As LLM agents increasingly use portable, client-side memory designs, this classic broken-access-control pattern re-emerges in new contexts.
• Defense requires server-side authorityThe recommended defense keeps authoritative state on the server, keyed to an authenticated session, ensuring the client cannot unilaterally change its own privileges. If state must travel with the client, the entire blob must be signed and verified on load—not just selected fields—and privileges must be derived from the server-side session, never from reloaded state.
• Historical pattern in modern architectureThe article notes this is a long-standing broken-access-control pattern that echoes classic insecure-deserialization and mass-assignment bugs, now reappearing as portable agent memory and state designs become more common. Developers building agent architectures must recognize that storing state on the client reintroduces this well-known vulnerability.

Bottom line: Any AI agent or application that persists state to the client and acts on privilege fields from that state is trusting the user to enforce their own restrictions. Authoritative privilege information must remain server-side and verified on every use, or the entire state blob must be cryptographically signed and validated before the agent acts on it.