How do I connect agents to Slack, Jira, and Drive without breaking permissions?

Summary

• Delegate, don't bypass: Agents should act on behalf of the user, not as a privileged bot. Use OAuth flows where the agent obtains permissions delegated from the user, not from a central service account.
• Respect existing permissions: If a user can't access a file or ticket, their agent shouldn't access it either. This requires integrating with the target system's identity layer and querying within the user's permission boundaries.
• Audit every action: Log which agent, on behalf of which user, accessed or modified what in the external system. This trail is essential for compliance and forensics.
• Define scope boundaries: Specify exactly which operations the agent can perform (read vs. write, which channels, which statuses) and for which users. Overly broad permissions introduce risk.

How do I connect agents to Slack, Jira, and Drive without breaking permissions?
Integrating agents with external systems enables new use cases: an agent can post updates to a messaging system, create or close tickets, or retrieve documents. But integration introduces a critical risk: if the agent has blanket permissions, it can access data or perform actions that the user wouldn't be allowed to do. The result is a compliance and security violation.

The permission problem

Many agent integrations are built with a single service account: "The agent has a Slack bot token, a Jira API key, and a Drive service account, and uses those credentials for all operations." This approach is simple but dangerous:

• Permission bypass: The service account's permissions often exceed the user's. An agent acting as the service account can read documents the user can't see.
• Non-repudiation: If an agent posts a message or modifies a ticket, who's responsible? The audit trail shows the service account, not the user who triggered the agent.
• Compliance risk: Regulated organizations can't audit which actual user performed which action through which agent.

The solution: delegate, don't bypass

The correct pattern is user delegation: the agent acts on behalf of the user, using the user's own permissions. This requires:

1. OAuth-based authentication: When a user connects their agent to Slack, Jira, or Drive, they grant the agent permission to act on their behalf. The agent receives a user-scoped access token, not a service-account token.
2. Permission boundaries: The agent is restricted to operations the user actually authorized. If the user doesn't have permission to modify tickets in a certain status or read files in a certain folder, the agent can't either.
3. Auditability: The external system's audit log shows the user's identity, not a generic "agent" or "bot" identity. When someone asks "Who deleted this Jira ticket?", the answer is clear.

Implementation patterns

OAuth delegation flow

When a user connects an agent to an external system:

1. User clicks "Connect to Slack" in the agent setup UI.
2. Agent redirects to Slack's OAuth consent screen.
3. User grants permission: "Allow this agent to post messages, read channels I'm a member of, etc."
4. Slack returns a user-scoped OAuth token to the agent.
5. Agent stores the token securely (encrypted, in a secrets vault).
6. For every operation, agent uses the user's token, not a service account.

This flow works because the user is the one granting permission, and Slack can enforce the user's permissions.

Querying within permission boundaries

When an agent queries the external system, it should be limited to the user's scope:

• Slack: Agent can list only channels the user is a member of, post only to channels the user can access.
• Jira: Agent can read and modify only tickets the user has permission to see and edit (based on project roles, issue permissions, etc.).
• Drive: Agent can access only files and folders shared with the user.

If the external system doesn't support per-operation scoping, the agent must implement filtering. For example, if Jira's API doesn't support filtering by user permissions, the agent must check the user's role in each project before allowing the agent to access that project's tickets.

Audit trail pattern

The external system should record:

• User identity (not the agent name).
• Timestamp.
• Action (e.g., "Created ticket", "Posted message").
• Result (success or error).
• Context (which ticket, which channel, etc.).

This enables questions like: "Show me all actions performed by agents on behalf of John in the last week." The agent layer should also log its own decisions for diagnostic purposes ("User requested this action, it fell within permission boundaries, so I executed it.").

Practical architecture

Component	Responsibility
Agent Framework	Orchestrates user intent, decides which external system actions are needed
OAuth Manager	Handles user login flows, stores and refreshes user-scoped tokens securely
Permission Checker	Before each external action, verifies the user has permission in the target system
API Gateway	Routes requests to the external system using the user's token, logs results
Audit Logger	Records who did what, when, where, and the outcome

Red flags: integrations that break permissions

• Service account credentials (API keys, service accounts) are hardcoded or centrally stored and reused for all users.
• No permission verification before agent actions. The agent just tries the action and fails if unauthorized.
• Audit logs show agent name or service account name, not the actual user.
• No way to revoke an agent's access without removing the service account entirely.
• Agent can perform actions the user can't perform themselves.

FAQs

What if the external system doesn't support OAuth?

Some systems only offer API keys or service accounts. In these cases, use a permission proxy layer: the agent calls a wrapper service that enforces user permissions before forwarding to the external system. This is more complex but necessary for compliance.

Can I use a single user account for all agents?

No. This is permission bypass in disguise. Every user's agents should use that user's credentials and respect that user's permissions.

How do I let agents act on behalf of multiple users?

Each user must grant permission separately. Store each user's OAuth token. When Agent A runs on behalf of User 1, it uses User 1's token. When it runs on behalf of User 2, it uses User 2's token.

What about bots that aren't tied to a specific user?

For system bots (e.g., an agent that posts daily summaries to a shared channel), use a bot account with minimal permissions. Document what that bot can do and for whom. Treat it as a special case, not the default.