The trust ceiling of Slack-native AI agents

In May 2026, the engineer Ben Vinegar added a fast-growing AI agent to his Slack and wrote this on X:

"🚨 btw this agent behaves like a worm

you add it to Slack once, and without asking, it researches and DMs your teammates to convince them to use it.

It also accessed channels I never granted it permission to.

cool growth hack, but I consider it an immediate deal breaker - like what other shenanigans will you do? contact my customers next?

buyer beware"

The post crossed 178,000 views. When someone asked what else the agent might have done, he replied: "yes I guess it would have contacted my customers next."

That was the AI agent space's first public trust incident. It will not be the last. We collated four of them this quarter, and they point at the same gap.

Four incidents, one pattern

The worm. Start with the one above. The agent DM'd teammates without consent and read channels it was never granted. That is easy to read as one company being aggressive. It is more useful to read it as a permission model. When you install an agent with a single workspace-wide OAuth grant, "channels I never granted it permission to" is not a bug. It is the design. The grant was the whole workspace, so the agent had the whole workspace. Nothing scoped it down because there was nothing to scope it with.

The org-wide ban. In a r/ClaudeAI thread with 2,542 upvotes, a company described waking up to a mass suspension: "everyone in our org woke up to emails saying that their Claude accounts had been suspended (~110 users)… Banning an organization for the behavior of an individual is a recipe for disaster in a business context. Disgruntled employees, incompetent interns - anyone could maliciously or accidentally revoke Claude access for the whole business." The top reply drew the lesson: "this is exactly why single provider dependency is dangerous for any business. doesn't matter how good the tool is if they can cut you off with zero notice and zero explanation." Different surface, same root. When the org is treated as one undifferentiated blob, one actor's behavior takes down 110 people, and nobody can point to who did what.

The backdoor. A second r/ClaudeAI thread, 1,197 upvotes, documented malware that planted itself in a coding agent's config: "the malware planted itself inside your Claude Code startup settings and your VS Code project config. Every time you open either one, the attacker's code runs… Uninstalling the package does not remove it." An agent runtime with unscoped access to your machine is also a persistence surface for anyone who reaches it. The blast radius is set by how much the agent was allowed to touch.

The CVE. OpenClaw shipped a privilege-escalation vulnerability, CVE-2026-33579. The top Hacker News comment summed it up: "System grants admin because it never checks if you are authorized to grant admin. Shipping at the speed of inference for real." Authorization treated as a step you can add later.

There is a reason this is landing now, with agents, and did not land the same way with a decade of Slack apps holding broad OAuth scopes. A normal integration exercises its grant through code you can read. If a bot has permission to post in every channel, you can inspect what it will do with that permission, and it will do that same thing every time. An agent exercises the grant through a model whose next action you cannot read ahead of time. The witconomist reply put the finger on it: a third-party app with full permissions to every channel is already a lot, and an LLM "doesn't follow deterministic programming." The workspace-wide grant that was merely sloppy for deterministic software becomes genuinely load-bearing for an agent, because the thing wielding it is improvising.

None of these is a story about one careless vendor. They are the category's first wave of public trust incidents, and the shared cause is that agents got dropped into shared workspaces before anyone shipped a permissions model a buyer could reason about. The features raced ahead. The trust primitives did not.

What buyers actually want

The people reacting to these incidents were specific about the fix. From Anup Sharma at Vellum: "Agents should have guardrails on who they can communicate with and maintain separate context of each person they're talking to. Letting AI run loose in a Slack workspace is a scary scary future." And bluntly, from another reply on the worm thread: "It's a little crazy you'd add a third party application with full user permissions to every channel in the first place. Never mind an LLM which doesn't follow deterministic programming."

Read across the reactions and four properties keep surfacing.

Explicit trigger only. The agent acts when a human @-mentions it or a scheduled automation fires it. It does not go prospecting on its own. This is a hard line, not a setting. Our founder put his version of it in public months before writing this: "im a big fan of ai agents in slack but I have a hard rule that they should only do stuff if directly mentioned or triggered by an automation."

Permission-scoped tool access. Vault scope, MCP scope, channel scope. Not one workspace-wide OAuth that hands the agent everything and hopes for the best. The grant should be the smallest thing that does the job.

An auditable trail. Every agent action logged, attributable to a specific human, replayable after the fact. When something goes wrong you want a record, not a shrug.

Org-isolated runtime. One organization's agent cannot see another organization's data, ever. The org is the boundary, and it holds even when two customers run the same underlying tools.

What Nairi ships today

Here is where we actually stand against that list, including the parts that are not done.

The trigger model is the default and there is no override. A Nairi agent responds when it is @-mentioned in a channel or when one of your automations runs. In practice that means the agent sits idle until someone types @agent in a thread, or until a schedule you configured fires, and it never initiates a conversation with a teammate on its own. It does not DM your team to sell itself, because it has no autonomous prospecting loop to do that with. The behavior in the worm thread is not a setting we left off. It is a thing the product cannot do. The Slack integration page covers the trigger rules and what the agent can and cannot see in a channel.

The org is the isolation boundary. Each organization's agent runs in its own isolated runtime on separate infrastructure, so there is no shared process where one customer's context can leak into another's. This is the part of the four properties we are most confident about.

Secrets are vault-scoped and the model never sees the raw value. Credentials live in a per-org vault. A secret proxy substitutes the real value into an outbound request only when the destination is on that secret's allowed-domain list, so an API key for one service cannot be exfiltrated to another. The security and privacy page walks through the encryption, retention, and proxy details.

The audit trail is partial, and we are not going to pretend otherwise. The raw material is there today: every assistant message is attributable to the human who triggered it and carries its model and cost, queryable through the conversations API. What does not exist yet is a buyer-facing audit log surface where an admin can scroll every agent action in one place. We are building it. If audit review is a hard requirement for you right now, tell us where the API falls short, because that shapes what we ship next.

If cost visibility is part of your trust question too, we wrote about what predictable agent pricing looks like separately.

The compliance angle

If you are the person who has to sign off on putting an agent in a workspace that touches customer data, the four properties are not abstract. They map onto controls a security review already asks for. NIST 800-53 has language for exactly this: AC-3 for access enforcement, AC-6 for least privilege, AU-2 for audit events. Explicit trigger and scoped tool access are access enforcement and least privilege. An auditable trail is audit events. Org isolation is a boundary control.

Attribution is the one worth dwelling on, because it is the property the org-wide ban really failed. When 110 accounts get suspended over one person's behavior and nobody can say whose behavior, that is an AU-2 problem wearing a business-continuity costume. The fix is the same one a security review wants: every action tied to a named human, kept long enough to reconstruct an incident, and scoped so one actor's mistake does not silently become everyone's. An agent that can attribute its actions is also an agent whose blast radius you can measure, which is usually one of the first things a security review wants to know.

We are not going to wave a compliance badge at you here. Certification is its own long road and this post is not the place to claim we are further down it than we are. The point is narrower. When your SOC 2 auditor or your security team asks how an AI agent in Slack enforces who it can talk to, what it can reach, and whether you can reconstruct what it did, those are the same four questions the worm thread and the org-wide ban were really about. A product that has honest answers to them is on a different footing than one that shipped the growth hack first.

Honest closing

We do not have this fully figured out. The audit log surface is mid-build. The permissions UI needs work, and there are parts of the scoping story we want to make easier to reason about than they are today. But the underlying principles, explicit trigger, scoped access, auditable trail, and org isolation, are how we think this category earns its way into enterprise trust. They are also, not coincidentally, the four things the incidents this year were missing.

The alternative is the growth hack. Add yourself to a Slack, DM the teammates, hope nobody screenshots it. That works until someone does, and then it is 178,000 views of buyer beware. We would rather ship the boring primitives and be honest about which ones are still cooking.