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.
Why This Matters for Security Teams
An AI agent with Slack access is not just a user with a token. It is an autonomous workload that can decide when to read, post, or chain actions into other tools, so the accountability question is really about who approved that execution authority and who retained the ability to constrain it. That is why guidance from OWASP Agentic AI Top 10 and NIST AI Risk Management Framework matters here: both push teams toward governance, traceability, and runtime control rather than assuming static approval is enough.
In practical terms, accountability usually spans the business owner that asked for the integration, the technical owner of the OAuth app or webhook, and the security or governance function that should have defined limits. If the agent can DM users, read channels, search history, or trigger downstream workflows, then the organisation needs proof of the exact permissions granted, the review that authorised them, and the mechanism for revocation. This is also where NHI discipline applies, because Slack tokens, bot secrets, and signing credentials are non-human identities that need explicit ownership and lifecycle control. The NHIMG view is consistent with the broader pattern seen in OWASP NHI Top 10 and the SailPoint research summary showing 80% of organisations have already seen agents act beyond intended scope. In practice, many security teams encounter this only after an agent has already posted, exfiltrated, or delegated access rather than through intentional review.
How It Works in Practice
The cleanest way to think about Slack misuse is through control layers, not blame alone. The team that approved the integration owns the use case. The owner of the OAuth app, bot account, or webhook owns the technical implementation. Governance owns the policy that should have limited scope, verified intent, and required revocation paths. Under current guidance, static RBAC is usually too blunt for agents because their behaviour is goal-driven and can shift mid-task. Instead, security teams are moving toward intent-based authorisation, where the system evaluates what the agent is trying to do at request time, alongside context such as channel sensitivity, message target, and time window.
That is where CSA MAESTRO agentic AI threat modeling framework and OWASP Non-Human Identity Top 10 become operationally useful: they encourage teams to model the agent as a workload identity with specific permissions, not as a human-shaped role. In practice, that means using JIT credentials, short-lived secrets, and explicit approval gates for high-risk actions. If the agent only needs Slack for a task, issue a scoped, ephemeral token, bind it to the workload identity, and revoke it on completion. Runtime policy engines such as OPA or Cedar can enforce whether the agent may post in a given channel, access a thread, or forward content elsewhere.
- Assign a named business owner, technical owner, and security approver for every Slack integration.
- Use workload identity, not shared secrets, to prove which agent is acting.
- Issue JIT credentials with the minimum scope and shortest practical TTL.
- Log granted permissions, runtime decisions, and revocation events for audit and incident response.
These controls tend to break down when long-lived tokens are shared across environments because the agent can keep operating after the original approval context no longer applies.
Common Variations and Edge Cases
Tighter control often increases friction, so organisations have to balance operational speed against containment. That tradeoff is most visible in chat-heavy environments where Slack is used for approvals, incident response, and informal coordination. A bot that only posts alerts is simpler to govern than an agent that can summarise channels, search files, DM employees, and trigger downstream actions in Jira or email. Current guidance suggests the accountability model should change with the agent’s reach: the broader the tool chain, the stronger the need for explicit owners, runtime checks, and revocation evidence.
There is no universal standard for this yet, but the emerging consensus is clear. If an agent can act autonomously, then the organisation should be able to show who authorised the behaviour, what the agent could access, and how quickly those rights can be withdrawn. That principle aligns with the governance expectations in AI LLM hijack breach and the implementation patterns discussed in NIST AI Risk Management Framework. It also fits the reality that agent behaviour is not perfectly predictable, which is why static approval forms alone do not establish true accountability. The right answer is usually shared accountability with clear control ownership, not a single scapegoat after misuse has already occurred.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent misuse is a tool-access and authorisation failure. |
| CSA MAESTRO | MAESTRO models agent risk, identity, and control boundaries. | |
| NIST AI RMF | GOVERN | Accountability for autonomous AI belongs in governance and oversight. |
Document owners, permissions, and revocation paths for each agent integration.
