In August 2024, researchers at PromptArmor showed that Slack AI could be made to surface content from private channels the requesting user had no access to. The attacker needed no elevated privileges and never touched the victim. They posted text in a public channel, and the assistant later read that text as instructions while answering someone else’s unrelated question. Slack first called the underlying behavior intended, then investigated the composed scenario and deployed a patch. The lesson is not about Slack. It is that an assistant reading untrusted content on your behalf inherits every boundary your retrieval layer fails to enforce.
Key findings
- The entry point was indirect prompt injection, not the input box. The attacker planted instructions in a public channel. The assistant read them as trusted context while answering a different user’s question. This is OWASP Top 10 for LLM Applications LLM01, and it is ranked first because it cannot be filtered away at the input layer.
- The impact was LLM02 Sensitive Information Disclosure, because private channel content reached a party with no authorization to see it.
- Neither half was severe alone. The chain was. Unscoped retrieval is a medium finding. An assistant that can render outbound links is a medium finding. Composed, they form an exfiltration route.
- Slack’s first answer was that the behavior was by design, and on a component-by-component reading that was defensible. Public channel searchability is documented product behavior. The composition is what changed its meaning.
- A product change four days earlier widened the surface. Slack AI had begun ingesting uploaded documents and connected drive files, which extended the set of places an attacker could plant content.
- The incident is catalogued as MITRE ATLAS case study AML.CS0035, which makes it citable evidence rather than anecdote when you are justifying an AI application test to a board or an auditor.
This post is written by Rathnakara GN, who leads AI and LLM penetration testing at Cybersecify. It analyses a publicly disclosed and remediated incident from the published record. We did not test Slack, and nothing here describes a live weakness. The technique detail is kept at the level a defender needs to recognise the pattern in their own product.
What happened
Slack AI answers questions using content drawn from across a workspace. To be useful it reads broadly: channels the user is in, channels they are not in but which are public, and after a product change in the same month, uploaded documents and connected drive files as well.
PromptArmor’s disclosure showed the consequence of that breadth. An attacker with nothing more than the ability to post in a public channel could place text designed to be read as instruction rather than as content. When another user later asked the assistant an unrelated question, the assistant pulled that planted text into the same context window as legitimate material, followed it, and returned private channel content rendered into a link pointing at infrastructure the attacker controlled.
Slack’s initial position, on 19 August 2024, was that messages in public channels are visible to workspace members whether or not they have joined, and that this is “intended behavior.” Within days, Salesforce confirmed it had investigated the described scenario, deployed a patch, and had no evidence of unauthorized access to customer data.
Both statements are worth holding at once. They are not a contradiction. They are the shape of the problem.
The part that matters: this was a chain
Take the two ingredients separately.
Ingredient one: retrieval that is broader than the requesting user. The assistant could read content the user could not reach on their own. Assessed alone, this reads as a search feature with a documented scope.
Ingredient two: an output surface that can reach outward. The assistant could render markdown links. Assessed alone, this is a formatting capability, and every assistant has one.
Neither would headline a report. Both would land as medium severity in a category-based assessment, each with a sensible one line remediation. A team could close both tickets and feel finished.
Composed, they are something else entirely. Broad retrieval supplies the data. Link rendering supplies the exit. Indirect injection supplies the trigger, and it can be planted by anyone who can write text into any surface the assistant reads. The route exists only when you look at the three together.
This is the single most transferable lesson in the incident, and it generalises far beyond Slack: assistants do not fail at the component level, they fail at the composition level. Testing that evaluates components in isolation is structurally incapable of finding this.
What to test in your own assistant
If your product has an assistant that reads content users can influence, work through these in order. None of this requires knowing anything about Slack’s implementation.
1. Enumerate every retrieval source, then ask who can write to it
List everything the assistant can read: channels, tickets, uploaded files, wiki pages, knowledge base entries, connected drives, email, CRM notes, web pages it browses, and memory carried from earlier sessions.
For each one, answer a single question: can content reach this source from someone other than the person asking the question? Every source where the answer is yes is an injection surface. In most products this list is longer than the team expects, and it grows quietly, because connecting a new data source feels like a product improvement rather than a security change. The Slack incident is a clean example: a change that added document and drive ingestion widened the attack surface without anything looking like a security decision.
2. Confirm the retrieval layer filters by identity, not the prompt
The question is not whether your system prompt tells the model to respect tenant boundaries. The question is whether the retrieval query itself is scoped to the requesting identity before results are ever returned.
A system prompt is an instruction, and instructions can be argued with. A WHERE tenant_id = ? clause cannot. If your isolation lives in the prompt rather than in the query, you have a boundary the model is capable of crossing, and indirect injection is how it gets asked to.
This is the check that most often fails in engagements, and it usually fails the same way: retrieval was built first for usefulness, tenant scoping was added later at the presentation layer, and nobody revisited the retrieval query.
3. Inventory what the assistant is allowed to emit
Retrieved data becomes a breach only when it can leave. Work out what your assistant can put in front of a user or send outward: markdown links, images loaded from arbitrary URLs, outbound HTTP calls, webhooks, emails, file writes.
Anything that can carry attacker-chosen text to an attacker-chosen destination is an exit. Image rendering is the one teams most often miss, because a loaded image is a silent outbound request that needs no click.
4. Test the composition, not the parts
Having mapped inputs, retrieval scope and outputs, the actual test is whether planted content in an untrusted source can cause a privileged retrieval to reach an exit. That is one test spanning three subsystems, and it is the one that finds real routes.
5. Fix by bounding blast radius, not by filtering input
Prompt injection cannot be reliably filtered out with current models, so a defence built on detecting malicious instructions will eventually be bypassed. The durable controls are architectural:
- Scope retrieval to the requesting identity at query time.
- Treat every retrieved document as untrusted data, never as instruction.
- Constrain what the assistant may render, and allowlist outbound destinations.
- Require human confirmation for any high-impact action.
- Log retrieval and rendering, not just API calls, so an incident is detectable from your own telemetry.
Why “intended behavior” is the most useful sentence in this story
Slack’s first assessment was not careless. Each behaviour, examined on its own terms, was working as documented. The gap was that nobody had yet evaluated what those behaviours did together once an assistant sat on top of them.
That is the ordinary failure mode, not an unusual one. Product teams ship an assistant on top of an existing permission model that was designed for humans clicking through a UI, and the assistant then reads with more reach than any single human had, at machine speed, on behalf of whoever asks. The permission model was never wrong. It was answering a question nobody was asking anymore.
If your team is about to connect an assistant to an existing data layer, the question worth asking before launch is not “is our permission model correct.” It is “does our permission model still mean what it meant before something could read all of it at once.”
What this means for an Indian SaaS company
The OWASP categories are jurisdiction neutral. The consequences are not.
An assistant that discloses personal data to an unauthorised party is a personal data breach under the DPDP Act, and it makes no difference that a model rather than a database was the disclosure path. The ceiling is INR 250 crore for failure to take reasonable security safeguards, and INR 200 crore for failure to notify the Data Protection Board and affected Data Principals. Our DPDP breach response playbook covers the notification path.
The harder obligation is timing. CERT-In requires specified incidents to be reported within 6 hours of being noticed. Most teams have logging on their API and none on their assistant’s retrieval and rendering, which means an assistant-mediated disclosure is typically noticed by a customer days later rather than by the team within hours. The gap is detection, not reporting, and it is worth closing before it is tested.
What depth of testing finds this
Being honest about what different levels of assessment surface, because the difference is real work rather than a packaging exercise:
| Depth | What it surfaces here |
|---|---|
| Category coverage | The individual weaknesses. Retrieval broader than the user. An output surface that can render outbound links. Both found, both reported, both real. |
| Systematic verification | Whether the isolation control actually holds when exercised, rather than whether it exists on paper. This is where “the system prompt says to respect tenants” is separated from “the query filters by tenant.” |
| Adversary emulation | The route. Planted content in an untrusted source, driving a privileged retrieval, reaching an exit. The finding that only exists when findings are chained. |
Category coverage finds findings in isolation. Adversary emulation finds the path between them. Real incidents are almost always paths, which is the honest argument for testing at that depth on a product where an assistant reads user-influenced content.
We do not claim that testing prevents any specific incident. What we can say is narrower and more useful: this class of finding is what mapping a retrieval graph and attempting a chained action is designed to surface, and if your product has an assistant reading content that users can write to, that is the test worth asking a vendor for.
How Cybersecify tests this class
Cybersecify is a founder-led penetration testing firm based in Bengaluru serving AI-first and API-first SaaS startups. Rathnakara GN, Co-founder and CHO, holds OSCP and leads AI and LLM engagements.
Our AI application pentest maps the assistant’s retrieval sources, tool graph and rendering surfaces, then tests whether planted content in any writable source can drive a privileged retrieval to an exit. Findings map to the OWASP Top 10 for LLM Applications 2025 codes and to MITRE ATLAS technique IDs, so an engineering lead or auditor can cross reference each issue. Where the question extends to chained exploitation across the wider environment, our red team service exercises the same classes against a live estate.
For the framework itself, see our OWASP Top 10 for LLM Applications reference. For the injection category in depth, see prompt injection 2026 attack patterns, and for the agent-specific extensions, AI agent pentest methodology.
Sources
- PromptArmor, Data Exfiltration from Slack AI via indirect prompt injection (original disclosure)
- The Register, Slack AI can leak private data via prompt injection (includes the Salesforce statement confirming the patch)
- MITRE ATLAS case study AML.CS0035
- OWASP GenAI Security Project, Top 10 for LLM Applications 2025
Where to go from here
If you have an assistant in production or in scoping and want to know whether this class of route exists in it, book a free 30-minute call with Ashok to scope the engagement, or see the pentest plans and pricing. For anything else, contact us.
We work with AI-first and API-first SaaS startups, Seed to Series B.
Frequently asked questions
What was the Slack AI prompt injection vulnerability?
In August 2024, researchers at PromptArmor disclosed that Slack AI could be manipulated into surfacing content from private channels the requesting user had no access to. The mechanism was indirect prompt injection. Slack AI retrieved context from across the workspace, including public channels the user had never joined, so an attacker who could post in any public channel could plant text that the assistant later read as instructions while answering an unrelated question. The assistant then rendered the retrieved private content into an attacker-controlled link. Slack initially responded that public channel searchability was intended behavior, then investigated further and confirmed a patch had been deployed, stating it had no evidence of unauthorized access to customer data. The issue is catalogued by MITRE ATLAS as case study AML.CS0035.
Is this the same as a normal prompt injection attack?
No. Direct prompt injection is a user typing a malicious instruction into the assistant’s input box, which is the version most teams have heard of and partially defended against. This was indirect prompt injection, where the malicious instruction arrives through content the model retrieves and treats as trusted context rather than through the user. The attacker never needed elevated access, never needed to be in the private channel, and never interacted with the victim. They only needed the ability to put text somewhere the assistant would later read. That is why the OWASP Top 10 for LLM Applications ranks prompt injection as LLM01 and why input filtering alone does not close it.
Which OWASP LLM Top 10 categories does this map to?
Two, in sequence. The entry point is LLM01 Prompt Injection, specifically the indirect variant, where retrieved content is treated as instructions. The impact is LLM02 Sensitive Information Disclosure, because the outcome was private channel content reaching a party with no authorization to see it. Reading it as a single category understates it. The finding that matters is the path between the two: a retrieval layer with no tenant or channel scoping sitting behind an assistant that could render outbound links. Either half alone is a medium severity finding. Chained, they are a data exfiltration route.
How do I test whether my own AI assistant has this problem?
Three checks, in order. First, enumerate every retrieval source the assistant can read and ask which of them accept content from someone who is not the requesting user. Uploaded files, tickets, wiki pages, shared channels, and connected drives all qualify. Second, confirm the retrieval layer filters by the requesting identity at query time rather than relying on the model to respect boundaries described in the system prompt. Third, check what the assistant is allowed to emit: if it can render markdown links, images, or make outbound calls, it has a channel for moving retrieved data off-platform. Most teams have logging on their API and none on their assistant’s retrieval and rendering, so the first two checks usually have to be done by reading the architecture rather than the logs.
Why did Slack’s first response say this was intended behavior?
Because in isolation each component behaved as designed. Slack has long documented that messages in public channels are visible to workspace members whether or not they have joined the channel, and searchability across public channels is a product feature rather than a defect. The initial assessment evaluated that single behavior and found it working correctly. What the assessment did not initially account for was the composition: the same searchability, once fed into an assistant that also reads private channels and can render links, becomes a path rather than a feature. Slack subsequently investigated the composed scenario and deployed a patch. This is the most instructive part of the incident for any engineering team, because component-level review is exactly the kind of testing that misses chained findings.
Does an incident like this create obligations under Indian law?
It can. If an assistant discloses personal data to someone not authorized to see it, that is a personal data breach under the DPDP Act regardless of whether a database or a model was the disclosure path. The maximum penalty is INR 250 crore for failure to take reasonable security safeguards and INR 200 crore for failure to notify the Data Protection Board and affected Data Principals. Separately, CERT-In requires specified cyber incidents to be reported within 6 hours of being noticed, and the practical difficulty with assistant-mediated incidents is the noticing rather than the reporting. Teams that log API calls but not assistant retrieval often learn about the disclosure from a customer days later rather than from their own telemetry within hours.
What kind of penetration testing surfaces this class of finding?
Testing that maps the assistant’s retrieval graph and privilege scope, then attempts to drive a privileged action through planted content rather than through the input box. Category-level coverage against the OWASP Top 10 for LLM Applications will find the individual weaknesses: unscoped retrieval, and an output surface that can render outbound links. Finding the route between them requires adversary emulation, where the tester chains findings the way an attacker would rather than reporting each in isolation. That difference in depth is why we scope AI application engagements around tool count, retrieval sources, and rendering surfaces rather than endpoint count.