Runtime controls for AI agents in Slack and Teams are the mechanisms that evaluate an agent's individual tool calls and actions at the moment they occur, rather than relying on the static OAuth scopes or Microsoft Graph permissions granted once at installation. They require a policy enforcement point between the agent's decision logic and the external tools it calls, permissions scoped to workspace or channel context, and audit logging tied to the originating conversation.
Technical Guide
How to Govern AI Agents in Slack and Microsoft Teams: Runtime Controls
Runtime controls for AI agents in Slack and Teams evaluate an agent's individual tool calls and actions at the moment they occur, rather than relying on the static OAuth scopes or Microsoft Graph permissions granted once at installation. They require a policy enforcement point between the agent's decision logic and the external tools it calls, permissions scoped to workspace or channel context, and audit logging tied to the originating conversation.
How Agents Connect Inside Slack and Teams, and Why It Matters for Control Placement
Runtime controls can only be enforced at points where an agent's requests physically pass through infrastructure an enterprise can observe. In Slack and Teams, that infrastructure looks different from a general-purpose API gateway: agent actions originate from platform-level identity, a workspace bot in Slack or an Entra-registered application in Teams, rather than from an individual end user's credentials. A control point placed after that boundary needs to distinguish the agent's own actions from the humans who triggered them, and to do so within the channel or conversation where the request originated.
Five Runtime Control Pillars for Chat-Embedded Agents
Governing agents at runtime, rather than only at install time, rests on five interconnected controls:
Agent Identity
Distinguish platform-level bot/app identity from the end users who trigger it.
Scoped Permissions
Resolve effective permissions per workspace or channel, not one static grant.
Tool-Call Interception
Evaluate outbound requests against policy before they reach external APIs.
Policy Enforcement
Apply allow, deny, or risk-tiered rules to sensitive action categories.
Audit Logging
Correlate every action to its channel, decision, and outcome for review.
The Runtime Governance Gap in Chat-Embedded Agents
Most enterprises govern AI agents in Slack and Teams the same way they govern any third-party app: a single OAuth consent screen or Microsoft Graph permission grant at install time. That grant describes what an agent is allowed to do in principle, but it says nothing about what any individual tool call or action actually does once the agent is running inside a live conversation. Runtime controls close that gap by evaluating an agent's individual tool calls and actions at the moment they occur, instead of relying solely on the permissions granted once at installation.
Design-Time Permissioning vs Runtime Policy Enforcement
The distinction between these two governance layers is worth making explicit, since teams that have implemented only the first layer often assume their agents are already governed.
| Aspect | Design-time permissioning | Runtime policy enforcement |
|---|---|---|
| Timing | Granted once, at installation (OAuth scopes, Microsoft Graph permissions) | Evaluated at the moment each tool call or action occurs |
| Scope | Static, account-wide grant | Scoped to workspace or channel context |
| Enforcement point | None between decision logic and tool execution | Policy enforcement point between the agent's decision logic and the tools it calls |
| Visibility | No record at the individual action level | Audit log tied to the originating conversation |
Intercepting and Evaluating Tool Calls Before Execution
Runtime enforcement depends on a policy enforcement point that sits between an agent's decision logic and the external tools it calls. Outbound tool-call requests, whether a message-posting action, a file read, or a call to an external API, are evaluated against policy before they reach their destination. Sensitive action categories can be allowed, denied, or subjected to risk-tiered rules, rather than treated identically to low-risk requests.
Governance Considerations for Security Teams
Taken together, the requirements above translate into a short set of considerations security teams should carry into any evaluation of an agent's governance model:
- Permissions should resolve per workspace or channel, rather than as one static, account-wide grant.
- Agent identity, the workspace bot or Entra-registered app, needs to be distinguished from the end users whose messages trigger it, since actions originate from platform-level identity.
- Every enforcement decision and its outcome should be logged and correlated to the originating Slack channel or thread, or the Teams conversation.
- Logs need to be retained long enough, and structured well enough, to support incident response and compliance review without manual reconstruction.
Audit Logging Requirements for Agent Actions
Runtime audit logging for agent actions in Slack and Teams should meet the following requirements:
- Record each tool-call request, the policy decision applied to it, and the resulting execution outcome.
- Correlate every log entry to the originating Slack channel or thread, or the Teams conversation, that triggered the action.
- Capture which identity, workspace-level bot or Entra-registered app, initiated the request, since agent actions originate from platform-level identity rather than an individual end user.
- Retain logs for a defined period sufficient to support incident response and compliance review.
- Structure logs so they can be queried by channel, user, tool category, or policy outcome without manual reconstruction.
Move Beyond Static Permissions for Chat-Embedded Agents
Design-time scopes tell you what an agent can do. Runtime controls tell you what it is actually doing, request by request, inside Slack and Teams.
Explore Runtime Governance