How Slack AI Could Leak Data With No Clever Attacker Required

OWASP LLM06 — Excessive Agency

Part 3 covered a model that’s corrupted before it ever answers a question. This post covers the opposite case: a model with no flaw at all, that still causes real damage — because it was simply handed more capability than the task in front of it required.

Per the official OWASP entry, an LLM-based system is often granted a degree of agency by its developer — the ability to call functions or interface with other systems through extensions, tools, or plugins to take actions in response to a prompt. Excessive Agency is what happens when unexpected, ambiguous, or manipulated model output leads to damaging actions being taken through that access, regardless of what caused the model to malfunction in the first place — whether that’s a hallucination, a poorly engineered prompt, or a direct or indirect injection attack.

OWASP traces the root cause to one or more of three things: excessive functionality (the tool can do more than the task requires), excessive permissions (the tool’s downstream access is broader than necessary), and excessive autonomy (the system acts on high-impact operations without requiring approval). A useful distinction the document makes explicitly: this is different from Improper Output Handling — Excessive Agency is about what the system is capable of doing, not about failing to scrutinize what the model said.

A real, patched case: Slack AI. In 2024, security firm PromptArmor documented a vulnerability where an attacker with no access to a private Slack channel could still exfiltrate data from it. The attacker posted a malicious instruction in a public channel; Slack AI’s retrieval system pulled that instruction into context when a victim user later asked an unrelated question; the model then complied with the injected instruction and included a link that, when clicked, sent the victim’s private data (in the demonstrated case, an API key) to the attacker. Slack’s own explanation for why the underlying data was reachable at all — “messages posted to public channels can be searched for and viewed by all Members of the Workspace, regardless if they are joined to the channel or not... this is intended behavior” — is the excessive-agency pattern in one sentence: a system built to be broadly helpful ended up broadly exposed, because the retrieval scope was wider than any single interaction actually needed. Slack patched the flaw after responsible disclosure.

The exact example OWASP itself uses is nearly identical in shape: a personal-assistant extension is given mailbox access to summarize incoming email, but the underlying plugin also happens to support sending messages — functionality nobody asked for and nobody needed. An indirect prompt injection in a malicious email then instructs the agent to search the inbox and forward sensitive information to the attacker. OWASP’s own fix for this scenario reads like a checklist: use an extension that can only read mail, authenticate with an OAuth scope limited to read-only, and require a human to manually approve every message before it sends.

Mitigations are almost entirely about narrowing scope, not detecting attacks: minimize which extensions a system has access to at all, minimize what each extension can do, avoid open-ended extensions (a “run any shell command” tool is far more dangerous than a narrowly-scoped “write this specific file” tool), minimize the permissions each extension holds on downstream systems, execute actions in the authenticated user’s own context rather than a shared high-privilege identity, and require human approval before high-impact actions. Nothing on this list is about catching a clever attacker — it’s about making sure that even a fully successful attack has nowhere useful to go.

The Slack AI case worked for a reason with no relation to model quality at all: retrieval scope was wider than any one conversation needed. That’s the throughline of this entire category — the fix isn’t a smarter model, it’s a narrower default.