Notifications
Clear all
Topic starter
06/06/2026 1:42 am
TL;DR: Slack-connected AI agents expand the attack surface because webhook URLs, Slack API tokens, and MCP-backed apps can all leak data or be abused if permissions are too broad, according to Aembit. The governance problem is no longer just messaging integration, but controlling NHI trust assumptions across notification, command, and remote-task workflows.
NHIMG editorial — based on content published by Aembit: connecting AI agents to Slack with webhooks, the Slack API, and MCP
Questions worth separating out
Q: How should security teams handle Slack-connected AI agents as identities?
A: Treat every Slack-connected AI agent as an NHI with explicit ownership, scope, and revocation requirements.
Q: Why do Slack webhooks and OAuth tokens increase enterprise risk?
A: They turn a convenience integration into a credential-bearing access path.
Q: What breaks when Slack app permissions are too broad for AI agents?
A: Broad permissions collapse the boundary between notification and workspace access.
Practitioner guidance
- Classify Slack integrations as governed NHIs Assign an owner, a purpose, and a revocation path to every webhook, bot token, and MCP-backed Slack app.
- Minimise Slack app scopes to the exact workflow Grant only the permissions required for the agent’s task, then remove anything that enables broader channel access, DM access, or event handling.
- Protect webhook URLs as high-value secrets Store webhook URLs outside source files, rotate them if exposed, and block their use in untrusted contexts.
What's in the full article
Aembit’s full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Slack app setup for incoming webhooks and OAuth-backed API access.
- Sample Python code for sending task results and formatted Block Kit messages.
- Practical configuration details for Slack scopes such as chat:write and im:write.
- Implementation notes for using an intermediary layer to deliver JIT access to OAuth connections.
👉 Read Aembit’s guide to Slack-connected AI agent notifications and access control →
Slack-connected AI agents: are your access controls keeping up?
Explore further
06/06/2026 2:59 am
Slack-connected AI agents are NHI governance objects, not just messaging integrations. Once an agent can send alerts, read channels, or accept remote tasks, the Slack connection becomes an access-bearing non-human identity. That shifts the problem from app convenience to entitlement control, lifecycle management, and revocation discipline. IAM teams should treat these integrations as governed identities with explicit owners and scope boundaries.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who is accountable when an AI agent misuses Slack access?
A: Accountability sits with the team that approved the integration, the owner of the OAuth app or webhook, and the governance function that failed to constrain access. For regulated environments, the relevant control question is whether the organisation can prove who granted access, what the agent could do, and how quickly it can be revoked.
👉 Read our full editorial: Slack-connected AI agents raise new NHI access control risks
