Why your agent RBAC is broken (and how to stop webchat from getting exec)

Last week, we saw a pattern that should make every team shipping AI agents a little nervous: A low-privilege webchat identity asked a backend agent to do something “just this once,” and somehow that request ended up running with elevated exec permissions . No jailbreak. No exotic zero-day. Just a boring, familiar auth bug: the system checked who executed the action, not who originally asked for it. That’s how RBAC bypass happens in agent systems. If your architecture has: a user or webchat-facing agent, an orchestration layer, and a privileged execution worker, …then you need to think about identity propagation , not just auth at the edge. The bug in one sentence A webchat session with limited permissions triggers a workflow, and somewhere in the handoff, the original caller identity gets replaced by a more privileged service identity. The exec layer sees: “request comes from orchestrator-service” instead of: “request originated from webchat-user, delegated through orchestrator-service