AI Agent Permissions for One Slack Agent Shared by a Team

AI agent permissions are the rules that decide what an agent may read, change and send, and on whose authority it does so. They are simple to reason about when one person runs one agent with their own accounts. They get much harder when a single agent serves a whole company from Slack, takes requests from anyone, reads whatever anyone posts and remembers what it learns. This article uses a real launch of that kind to show where the risks sit and which controls have to live outside the model.

The launch is the Every Agent, announced by the media company Every on October 6, 2026. Dan Shipper, Every’s cofounder and CEO, describes it there as “a single agent the whole company shares, built with Claude Managed Agents”, Anthropic’s hosted agent platform. The same day, Anthropic’s Claude channel published an interview with two members of the Every team about how they built it. Asked about identity, one of them summed up the design goal:

“Let’s try and make it act as close to a human as it can within Slack.” - one of the two Every guests

For usability, that is the right instinct. For security, it is where the questions start: a human coworker carries one identity and one set of access rights, while a shared agent carries many of them at once.

A shared agent has two identities, and each permission belongs to one of them

The Every team describes a split model. Inside the Slack conversation, the agent is its own participant, with its own name and its own memory. When it reaches into a connected tool to fetch a document or look something up, it mostly works with the access of the person who asked. Every’s product page puts the same rule in writing: the agent “uses each person’s own access”, and “provider access is authorized against the acting user and workspace”.

That split already has a name in identity standards. RFC 8693, the OAuth 2.0 Token Exchange specification published in January 2020, separates impersonation, where one party “is given all the rights” of another, from delegation, where the acting party “still has its own identity separate from” the person it serves. The specification defines an act claim so that a single token can carry both names: the user whose rights apply, and the agent doing the work.

The distinction matters for the logs even more than for the access check. If the agent impersonates Alice, a record that Alice exported a spreadsheet at 2 a.m. cannot tell an investigator whether Alice did it or the agent did it for her. Every says that permission changes and provider activity “produce metadata-only audit trails”. The page does not say whether those trails name both parties, and that is the first question worth asking any vendor of a team agent.

Delegation keeps the agent’s identity beside the user’s, so the log can say who acted. Source: RFC 8693.

The confused deputy returns when someone else wrote the instructions

Acting with the requester’s rights solves one problem and reopens an older one. In 1988, Norm Hardy described the confused deputy. A compiler at the timesharing company Tymshare was allowed to write files in its own system directory, where the billing file also lived. A user who knew the billing file’s name gave it as the destination for the compiler’s debugging output, and the compiler overwrote the billing records. The compiler was not malicious. It used its own authority on behalf of someone who did not have it.

A shared Slack agent is a deputy by design. Alice asks it to summarize a thread. The thread holds a message from Bob, and Bob’s message contains instructions. The agent now holds Alice’s access while reading Bob’s words, and a language model has no reliable way to tell a request apart from the text it was asked to process. Alice’s rights set the ceiling, but Bob is the one steering.

This is not hypothetical. In August 2024, the security firm PromptArmor showed that Slack AI could leak data from private channels. An attacker posted a message in a public channel where the attacker was the only member. When a victim later asked Slack AI for an API key kept in their private channel, the assistant pulled both messages into the same context, followed the attacker’s instructions and rendered a “reauthenticate” link with the key embedded in its address. One click sent the key to the attacker’s server. Slack’s first response, according to PromptArmor, was that this was intended behavior, since public messages can be searched by every member of the workspace.

The victim’s access was never exceeded; the attacker supplied the instructions. Steps as reported by PromptArmor in August 2024.

The case maps onto the shared-agent model exactly. The victim’s permissions were respected from start to finish, and nothing was read that the victim could not read. The leak came from whose instructions were followed, not from whose access was used.

A Slack agent combines the lethal trifecta by default

Simon Willison gave this class of risk a compact test in June 2025 and called it the lethal trifecta. An agent that has access to private data, exposure to untrusted content and a way to communicate externally can be tricked into sending the first to an attacker. His advice is to avoid the combination entirely, because filters that catch most injection attempts still miss often enough to matter. In web application security, he points out, stopping 95% of attacks is a failing grade.

A company agent in Slack starts with all three legs. Private data arrives with every connected drive, inbox and repository. Untrusted content is every message and shared file the agent reads, including those from colleagues, guests in shared channels and forwarded emails. External communication is the agent’s core job: posting replies, rendering links, sending email, opening pull requests. Removing any one leg removes most of the product, which is why the controls have to narrow each leg instead of cutting it off.

Shared memory is a permission problem, not only a feature

Two of the stories told in the interview are presented as small delights, and both read differently with permissions in mind. During the annual benefits enrollment, the agent knew every plan and each employee’s personal situation, and helped each person pick. In another story, an executive asked the agent to remember a beer owed to a colleague, and the agent brought the debt up later, in a different conversation where it judged the reminder relevant.

The second story is charming because the information is harmless. The mechanism, though, is the one that would carry a medical detail from a benefits thread into a team channel: something written to memory in one context, then retrieved in another by a model deciding what is relevant. Every’s launch post and product page, as consulted on October 17, 2026, do not say how memory is partitioned between users.

Anthropic’s memory documentation for Managed Agents is explicit about the risk. Memory stores attach with read and write access by default, and the page warns that a successful prompt injection can write malicious content into a store, which later sessions then read as trusted memory. The same page recommends focused stores, one per user and one for shared domain knowledge, with read-only access for reference material. That is the right default for a team agent.

AI agent permissions have to be enforced outside the model

The Every team was candid about the hard part. Coworkers ask the agent for things in gray zones, where a person would simply know that sharing a given report is harmless, and that kind of judgment is difficult to write into agent logic. The OWASP project’s answer, in its 2025 entry on Excessive Agency (LLM06), is to stop asking the model to make that call at all:

“Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.” - OWASP Top 10 for LLM Applications 2025

OWASP traces excessive agency to three root causes: excessive functionality, excessive permissions and excessive autonomy. Its mitigations include running extensions in the user’s context with the minimum scope the task needs, and requiring human approval for high-impact actions. Every’s product page lists controls of that kind: permissions set by admins per user and per group, connections limited to the teammates an owner picks, and an option to require approval “before anything sends, spends, or ships”.

The platform underneath helps, but it does not draw the boundary on its own. Managed Agents keeps per-user credentials in vaults that are attached session by session, so one agent definition can serve many people with their own tokens. The same page warns that vaults are scoped to the workspace: any API key with workspace access can reference any vault when it opens a session. The code that maps a Slack user to a vault is therefore the real security boundary, and it belongs to the team building the agent, not to the platform.

Before giving a team agent the keys, check these seven controls

These checks follow from the sources above and apply to any team agent, bought or built.

• Per-user credentials, never a shared service account. An agent holding the union of everyone’s rights is the confused deputy at its worst.
• Both identities in every log entry. The record should show who asked and that the agent acted, the way the act claim of RFC 8693 does inside a token.
• Personal memory by default. Shared memory should be curated by a person, and mounted read-only for sessions that have no reason to write to it.
• Approval for anything that leaves the workspace. Sending, spending and publishing are the external-communication leg of the trifecta.
• Narrow outbound paths. A Managed Agents credential can be limited to a list of hosts, and an environment can limit which domains the agent reaches at all.
• Every message treated as untrusted, colleagues included. The Slack AI attack needed nothing more than a public post.
• Retention known in advance. Anthropic’s overview states that Managed Agents is not currently eligible for Zero Data Retention or HIPAA BAA coverage, a limit Every also mentions in its article on the shared agent. Benefits questions are precisely the kind of data that makes this matter.

Shared agents spread skills faster, and permissions decide whether that is safe

The case for one shared agent is strong, in my reading. Every reports that its earlier personal agents were hard to maintain and that people learned most by watching someone else’s agent at work, while a shared agent improves from everyone’s corrections in public threads. That is an argument about how skills spread through a company, and it holds up.

The security story the interview tells is mostly about isolation primitives: sandboxes, sessions, scoped memory and per-user credentials. Those primitives are necessary, but they are not a permission model. The permission model is the set of decisions a builder makes about which credentials each session receives, which memory it may write, which actions wait for a person and which messages it treats as instructions. None of those decisions shows up in a demo, and all of them decide whether a shared agent is a colleague or a deputy that anyone in the workspace can borrow.