AI Agent Access Control Across Slack, Drive, Notion, and Jira

An AI agent does not need a single "read-only" switch. It needs a task-specific boundary across the identity it uses, the data it can retrieve, the exact tool and input it can run, where the result may travel, and which changes require approval. A connected SaaS account may legitimately see much more than the agent's current job requires.

For a first cross-app test, allow one bounded metadata read in one approved workspace or project. Deny content expansion, cross-service copying, sharing, messaging, edits, and administration until each has a separate reason and approval. The matrix below translates four Aident Loadout Action-catalog reviews into a starting policy. It is not a security certification, a live-account permission test, or a claim that Aident automatically enforces these roles.

If you need to inspect a real integration, set up Aident Loadout and use capability discovery, the current Action schema, and preflight before authorizing one read. A free quote or a connected Vault credential does not grant permission to execute.

What the Four Catalog Reviews Found

The 377 figure sums distinct public Action names within each of four integration snapshots; it does not deduplicate cross-provider concepts, compare equivalent API surfaces, or describe a permanent current catalog. The read/write split is lexical, not a risk score. In all four reviews, the wrapper labeled the observed Actions operationType: write, even for read-sounding names. That conservative platform label is a review gate, not evidence that every provider call mutates data. Read the exact current schema and effective credential before making a policy decision.

The original reviews documented the discovery method, observed counts, representative schemas, and limitations. This article re-analyzes those four dated observations into a cross-app role matrix; it does not claim a fresh execution of 377 Actions or access to customer workspaces.

Start With One Job, Not One Integration

Suppose the job is: prepare a weekly project-status summary from one Jira project, one Notion page, one Drive folder, and one public Slack channel. A single "connected apps allowed" rule is too broad. Write an authorization record for each step:

Grant these in stages. A connection verifier checks authentication, Vault state, discovery, and schemas without running a provider Action. A metadata reader gets one small, named resource list. A content reader can retrieve selected fields from an approved resource after a person chooses it. A summarizer may combine those approved results locally but may not transfer source content to another SaaS app. A reviewed writer receives one exact destination and payload after human approval, then performs a read-back. An administrator is not an extension of the writer role; it remains denied by default.

This is a proposed operating policy, not a description of provider roles or Aident's built-in role controls. Provider OAuth scopes and sharing permissions remain the outer boundary. Client tool exposure, exact input constraints, human approval, and output handling make the job narrower.

Why the Four Boundaries Differ

Slack: conversation access is not posting authority

For a channel finder, list a small number of non-archived public channel names. Do not include message history, files, direct messages, private channels, people, or workspace administration in that role. The Slack scopes reference distinguishes these kinds of access, and Slack's app-permission guidance asks administrators to evaluate both what an app can see and what it can do. Even a read-sounding file Action may change the transfer boundary if it returns a public URL.

Drive: file visibility and sharing are separate decisions

For a folder inventory, constrain the corpus, folder, fields, page size, and shared-drive options of the current files.list contract. A file-name lookup is not approval to download contents, enumerate all accessible drives, list permissions, or change sharing. Google's Drive scope guidance and sharing guide describe distinct authorization and audience consequences. Exporting a document into another service requires its own transfer decision.

Notion: a search can become workspace enumeration

Give a page reader an exact page or database target and only necessary properties. The reviewed search contract documented an empty-query fallback that lists accessible items, while a database property filter could be applied after the wrapper had received the result. Notion's MCP security guidance is useful provider context, but the exact Action and returned fields still need inspection. Do not let a missing page silently broaden the query to the whole workspace.

Jira: a "get" may have a side effect

Give the status reader a named project, bounded JQL or issue IDs, limited fields, and no issue transition, comment, assignment, notification, or attachment change. The reviewed get issue contract allowed update_history, which can alter the authenticated user's Recently viewed list. Conversely, a create-named JQL autocomplete Action retrieved reference metadata. Atlassian's MCP permission guidance supplies the provider-side control context; names alone cannot establish the consequence.

Inspect One Aident Action Before Any Provider Read

Use the installed public CLI. First verify account and Vault status:

aident account auth status
aident vault vault --action status

Search for the narrow job in staging. For example, to find a Slack channel-listing Action:

aident capabilities search \
  --query "list five non-archived public Slack channels read only" \
  --types '["action"]' \
  --scope '{"integrationId":"slack_tools"}' \
  --targetEnv staging

Copy the current exact Action name from the search result, inspect its schema, and preflight only a bounded input:

SLACK_CHANNEL_LIST_ACTION="<PASTE_RETURNED_ACTION_NAME>"
aident capabilities get --name "$SLACK_CHANNEL_LIST_ACTION"
aident capabilities preflight \
  --name "$SLACK_CHANNEL_LIST_ACTION" \
  --input '{"limit":5,"types":"public_channel","exclude_archived":true}'

That input passed a free schema preflight in the single-app Slack review; it was not executed there or for this cross-app analysis. Confirm the live schema, workspace, effective identity, scopes, and consent before executing a provider read. Repeat separately for Drive, Notion, and Jira. Do not copy a Slack input into a different provider Action, assume a catalog label enforces a least-privilege policy, or treat a $0 quote as a safety verdict.

The product bridge is inspection and safe preflight of one exact Action. Teams still need provider-side scope configuration and a reviewed client-side allowlist or approval boundary to enforce the proposed matrix. The risk-versus-spend approval guide explains why cost and consequence are different decisions.

The Decision Checklist

Before each new agent capability, ask:

1. What single user job requires this Action, and who owns the provider account?

2. Which tenant, project, channel, page, folder, or issue can it reach?

3. Do omitted input fields broaden a search, include shared spaces, or change state?

4. Can returned data be downloaded, made public, or copied into another service?

5. Is the proposed write one exact consequence, destination, and payload?

6. How will a reviewer verify the result and detect a second unintended action?

7. When do version, scope, or role changes trigger a fresh review?

If any answer is unknown, stop at discovery and schema inspection. Do not assign a blanket "read-only" label to an integration. The useful unit of authorization is the current Action plus identity, resource, input, audience, and consequence.

Method, Limitations, and Refresh Trigger

The four source articles reviewed Aident Loadout's staging Action catalog on September 12 or 21, 2026. Their counting rules group names by prefixes, deduplicate within each integration, and inspect selected schemas rather than execute every Action. This secondary analysis sums their counts and compares the failure modes they documented. It does not measure attack rates, effective OAuth scopes in customer tenants, prompt-injection resistance, latency, or enforcement quality. Neither a provider's permission model nor Aident's catalog is frozen at publication.

Re-run the matrix when any of the four integration versions, provider APIs, OAuth scopes, Action schemas, wrapper risk metadata, or client policy controls change. Recheck before using a count in a buying or security decision.

The search prompt family includes "AI agent access control," "AI agent permissions management," "AI agent data access control," "least privilege for AI agents," "how to restrict AI agent access," and "MCP server tool permissions." This page owns the cross-app role-design job; the four linked audits own provider-specific execution details. A vendor-platform comparison or a general IAM architecture would require a different canonical and separate evidence.

Put One Bounded Reader Through Preflight

Follow https://aident.ai/SETUP.md

Set up Aident Loadout and inspect one Action

The intended next step is one safe preflight, not blanket authorization. Record the source slug and selected Action, then measure an attributable setup start and first approved integration connection before expanding the role.

Sources

• Slack Action permission audit, catalog snapshot September 21, 2026.

• Google Drive Action permission audit, catalog snapshot September 21, 2026.

• Notion Action permission audit, catalog snapshot September 12, 2026.

• Jira Action permission audit, catalog snapshot September 12, 2026.

• Slack scopes reference and app permissions.

• Google Drive files.list, scope guidance, and sharing guidance.

• Notion MCP security best practices.

• Atlassian MCP server permission configuration.