Account Takeover via Valid Permissions: A Proof of Concept

A proof-of-concept demonstrates that AI agents with valid individual permissions can execute account takeover through a sequence attack, where per-call checks fail to detect the malicious composition. The researcher's reproduction script shows that tracking prior action classes, such as IDENTITY_MUTATION followed by CREDENTIAL_RECOVERY, can block the attack even when each step is individually allowed.

Account Takeover via Valid Permissions: A Proof of Concept I've been testing this "sequence attack" logic with my team. We found that most deployment patterns rely on per-call checks: "Does the agent have the update email permission? Yes. Does it have send password reset ? Yes." The result is a successful account takeover despite 100% green checks. If you want to see this in action without the fluff, you can run this reproduction script. It uses only the Python standard library—no network calls, no API keys, just pure logic. git clone https://github.com/keniel13-ui/sequence-attack-repro cd sequence-attack-repro && python3 repro.py The Failure of Step-Only RBAC In a real-world AI workflow, an agent might handle a support ticket. If the ticket says "change my email to email protected /cdn-cgi/l/email-protection and reset my password," a basic system sees: read ticket - ALLOWED read customer - ALLOWED update contact email - ALLOWED send password reset - ALLOWED Everything is within the agent's role, yet the account is gone. Prompt injection classifiers might catch some of this, but the core issue is architectural. Solving for Composition The real challenge is when the caller is verified and the purpose is legitimate e.g., account recovery . In these cases, the agent should be able to read data and change identity details. The security failure happens at the composition level. The goal is to move from "Is this tool allowed?" to "Is this sequence of tools allowed?" In the provided repo, the system blocks the final step not because the tool is forbidden, but because of the prior action classes . Here is how the system logs the block when it detects a sequence attack: { "tool": "send password reset", "args": { "id": "cust 77" }, "action class": "CREDENTIAL RECOVERY", "grant": { "principal": "caller claiming cust 77", "purpose": "account recovery", "verified via": "callback verified" }, "facts in chain": , "prior action classes": "READ", "IDENTITY MUTATION" , "decision": { "allow": false, "rule": "R4 SEQUENCE" }, "why": "credential recovery after an identity mutation in the same session composes to account takeover. Every step was allowed. The sequence was the attack.", "chain sha256": "726f65973fb027640049120971a43ca68300197d56ab2d74d5ca94a977d907a7" } By tracking prior action classes , the gate recognizes that IDENTITY MUTATION followed by CREDENTIAL RECOVERY is a high-risk pattern, regardless of whether the individual permissions are green. This is a much more robust approach for any production LLM agent deployment. Next Bare-Metal Kubernetes: My $200 Scrap Hardware Build → /en/threads/3395/