AI coworkers in Slack need their own identity

MintMCP runs 40 to 50 AI agents in Slack. They have names (Max does sales, Leo marketing, Peter procurement), people message them like coworkers, and none of them borrows a human's login. Each agent is its own principal, with its own identity, its own allow list of tools and an audit trail at the gateway.

That's from The Context ft MintMCP, the Agentic AI Foundation's livestream, where Jiquan Ngiam, MintMCP's co-founder and CEO, showed how his team works with agents. My own agent fleet talk ends on the part a home setup gets to skip: monitoring, traceability, identity management. This talk is that part.

Identity is the step from tool to teammate

JQ (that's what he goes by) maps AI adoption in four levels. The steps between them are the interesting part:

Level 2 is where most of us are. You connect Claude Cowork or a similar tool to the CRM and ask for a forecast deck. It finishes hours of work, but it's single player.

Level 3 is an agent you don't open like an app. It sits in Slack or Teams, maybe with its own account and email address, and you message it the way you'd message a colleague. That's where agent identity, access control and agent-to-agent messages start to matter. Level 4 is the software factory I wrote about last month.

From single player to multiplayer

When I run Claude Code or Codex in a terminal, nobody else sees the session. Nobody can nudge it or pick up where it stopped. JQ calls that single-player AI.

In a Slack thread, several humans and several agents work in the same place, everyone sees what's happening, and anyone can step in. People adopt agents faster when they watch them work, and agents get a place to work with each other.

One number surprised me. On MintMCP's gateway, which handles over two million MCP and agent calls a day, the 20 most-installed connectors are everyday work tools: Google, Slack, Notion, Figma, HubSpot. Engineers came first, but non-engineers now save the most time. At Modern Treasury, agents save technical account managers hours per case.

A Slack thread is a sandbox

The live demo was simple. He asked Leo, the marketing agent, which AAIF events they had been to and which were coming up. Leo opened a thread, ran bash and search, read Slack through the Slack MCP server, and streamed every step into the thread. Its answer included the livestream we were watching.

Here's the setup as he described it:

My favourite example is from engineering. Dan is a coding agent on Claude, Sam is one on Codex. A human asks Dan for a change to their LLM gateway. Dan reads the codebase, proposes a plan and waits for an OK. He builds a first version and messages Sam, and the two review each other in the channel until they agree. Then Dan pings the human, the human reviews and merges, and the bot wakes up once more to ask whether the docs need an update.

My coding agent, Spark, already gets a model from another family to review its pull requests. The difference is where it happens: their whole back-and-forth sits in a channel where people can watch and step in.

The others he showed: Peter chases security reviews, missing documents and trial tenants across deals in flight, and pings people about what's still open. JQ said he's no longer sure whether he pings the bots or they ping him. Minty answers customers in their shared channels; after a long thread about SSO, one customer wrote "you were perfect, no human needed, I'm all set."

Their first agent, Max, went live in February. They went from one agent to five fast, then to 20. Now every new hire creates an agent in their first week.

Every agent is its own principal

Without an identity layer, an agent holds a human's credentials. A sales agent acts as JQ in the CRM, on LinkedIn and in Gmail, and you lose control, the audit log and any record of who did what. His example: you ask it to clean up the CRM, and it reads "clean up" as "delete everything".

So each agent at MintMCP gets:

• its own identity and its own scope, with an allow list of what it can do
• explicit credentials on every tool call: a service account, or a delegated credential acting for a user, with the delegation chain recorded
• OAuth handled at the gateway, refresh included, because a background agent can't stop to click through a login screen

Permissions get decided at runtime

This is the part I hadn't thought through. Should the agent read the data as itself, or as the person who asked? It depends on the system. An assistant reading calendars should use the asker's credentials. An agent watching DevOps monitoring should use a service account.

An OAuth grant is a static token, and that's easy to reason about. In a channel, the right permissions depend on the grant, who sent the message, who else will see the reply, and what the task is. JQ calls this the shift from static to dynamic permissions.

About 99% of MintMCP's controls are still deterministic. His rule: what you can make deterministic, make deterministic. The hard case is a thread with person A, who can see some data, and person B, who can't. If A says "go get it", that's probably fine, the same as if both were in a meeting room. They're trying a bit of AI for that call, with two conditions: everyone in the thread sees that access was granted, and A gets an undo button.

Lock the tools down at the gateway

OAuth scopes are often too wide, so an agent inherits everything its user can do, including sending email and deleting records. MintMCP's answer sits at the MCP gateway, and it's deterministic:

• risky tools are denied outright, like deleting records or sending email
• agents never hold the final keys, only temporary access through the gateway
• the gateway logs every call, so you can go back and see which agent did what
• tools are bundled by role, not by server: engineers get read and write on Jira and read-only Intercom, a marketing agent gets less
• data is scoped too: Google Drive, but only these 10 folders

Two details I liked. The GitHub MCP server's fork-repository tool is one of the first tools their customers turn off. And customers in finance and healthcare run their existing DLP on every MCP call, which adds 100 to 200 ms.

I learned the deterministic part the hard way. In August I denied my finance app's MCP tools to most of my agents with a pattern in my gateway config. A month later I tested it: the pattern matched nothing, and an agent that was supposed to be locked out was offered all 13 tools, write tools included. The tool names used a different separator than I'd assumed. Now I check a deny rule by asking the agent to list its tools.

The 6 a.m. message nobody asked for

The best story came in the Q&A. At 6 a.m., Max posted in the deals channel that one deal had been assigned to two reps. JQ started debugging the deal, then stopped: why did the agent wake up and post that at all?

It took the audit log to find out. A colleague had asked their own agent something, that agent delegated to Max, and Max escalated to the whole channel. Without the delegation chain, nobody would have known.

That's the next phase he sees: who can create, message and update an agent, who orchestrates them all, and, in his words, what the HR equivalent for agents is.

Memory needs access control too

Darren Shepherd, one of the hosts, pushed back. You can't tag every sentence with a data classification, and as models get smarter, maybe AI should make more of these calls. We trust humans, he said, because of the process around them, not because they're reliable.

JQ's answer was a second dimension: memory. When his personal agent talks to Darren, it shouldn't share JQ's finances. So memory gets silos (one per person, per team, per company, per customer), and the agent sees different silos depending on who it's talking to. Same persistent ID card at the door, different books it's allowed to read. He called that one very much R&D.

Where my own fleet sits

My agents each have their own Telegram thread. By JQ's map that's level 2: one human and one agent per thread, nobody else watching. Telegram doesn't even deliver one bot's messages to another bot, so my agents can't talk to each other there.

Today I gave two of them Slack accounts: Nova, my generalist, and Spark, my coder. They live in a workspace just for agents, each with its own Slack app, because one app is one bot user. That's the first piece of identity. Next I want Nova to open a channel for a coding job and bring Spark in, the way Dan brings in Sam.

The catch: Slack's free plan allows 10 apps per workspace, and I have 17 agents. Delegated credentials, runtime permissions and memory silos are all still ahead of me.

The talk is 40 minutes, and the Q&A about permissions is the best part. MintMCP also wrote up how to build an AI coworker in Slack. And if you've solved the person A, person B thread, I'd love to hear how.

Plain text: ai-coworkers-slack-agent-identity.md · Atom feed · All notes