Before AI connects apps: make a permission map

Adam Olofsson Hammare
Before AI connects apps: make a permission map

When AI only writes text, the risk is usually limited to the answer in front of you. When the same AI can connect apps, read files, create tasks, steer a browser or work through MCP servers, the better question is: which account is it using, what can it actually do, and who can stop it?

That is why a permission map belongs before the next clever AI connection becomes daily work. Not a large policy document. Just a simple map of apps, accounts, scopes, write access and stop rules. It lets an organization test AI in real workflows without pretending that “connect app” means “ready”.

Why this now matters

Google describes Gemini Spark on macOS working across local files and Google Workspace, and Spark gaining more connected apps such as Google Tasks, Keep, Canva, Dropbox, Instacart, OpenTable and Zillow Rentals. Google also says Spark only has access to files the user gives it permission to use, and that custom MCP support is rolling out for more tailored assistants.

Source: Gemini Spark updates: macOS launch, connected apps and more

Anthropic is moving in the same direction from a more central control angle. Claude apps gateway is a self-hosted control plane for Claude Code where organizations can use corporate login, policy, role-based access, routing, telemetry and spend caps. The point is not only that Claude can do more. It is that access, cost and policy have to be governed where the work happens.

Source: Introducing the Claude apps gateway and Claude apps gateway documentation

Mistral Vibe shows the same pattern in smaller but useful details. In v2.18.3, the release mentions MCP panels, project configuration and a fix so Vibe no longer prompts users to log in for disabled MCP servers. That may sound technical, but for a workflow it means connector state must be visible, local configuration must be understandable and disabled connections should not confuse users.

Source: Mistral Vibe v2.18.3 release

Perplexity has also made Claude Sonnet 5 available for Pro and Max users and selectable as an orchestrator model in Computer. The broader lesson is useful outside Perplexity too: when a model steers a computer workflow, model choice, account and tool access all affect what can happen in practice.

Source: Perplexity on X, June 30 2026

The permission map in one sentence

A permission map is a simple list of which apps AI may use, through which account, with which permission, in which workflow, and who can change or revoke that access.

It matters especially when AI will:

  • read documents, folders, images, spreadsheets or client material
  • create tasks, files, presentations or design assets
  • send messages, book appointments or update records
  • use a browser, a Computer mode or a local agent
  • connect to MCP servers, internal APIs or third-party apps

This is not legal advice. It is a practical working document so responsibility, risk and the stop rule are visible before the workflow touches real work.

Fields to include

Start with ten fields. That is enough for the first level.

  • App or system: Drive, Dropbox, Canva, Jira, browser, local folder, CRM or another service.
  • AI tool or agent: for example Gemini Spark, Claude Code, Perplexity Computer, Vibe or an internal workflow.
  • Account owner: the person or group whose account is being used.
  • Permission scope: read files, search, create, edit, export, send or delete.
  • Write access: yes, no or only after human approval.
  • Data reachable: internal documents, personal data, student data, client files, finance or public material.
  • Test environment: where the workflow can be tested without touching production files.
  • Log or receipt: what is saved after the run: input, source, decision, change, model and timestamp.
  • Revocation owner: who can disable the access the same day if something goes wrong?
  • Stop rule: when should the AI stop and ask a human to take over?

Short and concrete beats complete and vague. A one-page first map is better than a perfect template nobody fills in.

Three ways to use the map

Example 1: AI sorts files in a folder.

Give the agent a test folder, not the whole organization’s Drive. Set the scope to “read and move files in the test folder”. Do not allow deletion. Log which files were moved and why. Only after the rule works several times should you discuss a larger folder.

Example 2: AI creates a Canva draft from internal notes.

The map should show where the notes come from, which account creates the design, whether brand templates are used, who approves before publication and whether the AI may share or export the file. If the source material contains client names, the workflow should stop or anonymize the input.

Example 3: AI searches Dropbox and suggests next steps.

Let the AI read limited folders and propose actions, but require human approval before anything is sent, shared or changed. The revocation owner should be known before the test starts, not after the first incident.

Common mistakes

The first mistake is testing with your own super-account. It feels fast, but it makes the test harder to review. Use a test account or limited workspace when possible.

The second is confusing reading with acting. Letting AI read a folder is one risk level. Letting it write, move, send or delete is another. The map should make that difference obvious.

The third is forgetting revocation. If nobody knows who can disable the connector, rotate the key, remove OAuth approval or stop the agent, the workflow is not ready for everyday use.

A simple first check

Before connecting the next app, answer five questions:

  • Which account does the AI use?
  • Which folders, objects or APIs can it reach?
  • Can it only read, or can it also change something?
  • Where is the log of what it did saved?
  • Who can revoke access before the next run?

If any answer is missing, the next step is not more automation. The next step is filling in the map.

Where Hammer can help

This is a typical Tool Forge problem. The tools already exist, but the workflow needs boundaries: test workspace, read and write levels, approval, logging and a realistic fallback.

If you want to connect AI to Drive, Dropbox, Canva, Jira, browsers or internal files, Hammer can help you build the permission map first. That keeps the first step small: understand what the AI is actually allowed to touch.

FAQ

What is an AI permission map?

A list of which apps AI may access, through which account, with which scope, whether it can write or only read, and who can revoke access.

What is the most common risk when AI connects to apps?

A test account, OAuth approval or connector receives broader access than the workflow actually needs.

How do you start safely?

Use a test workspace, read-only access where enough, a small allowlist, run logs and a documented revocation path before the workflow touches production files.

Do smaller organizations need this?

Yes, especially when AI can reach files, client data, student data or accounts that can write. The map can be simple, but ownership and stop rules must be visible.

The Forge newsletter

Get new articles in your inbox

Pick the topics you care about. No noise, at most one email a week.

Get new articles in your inbox

We follow GDPR. Unsubscribe anytime.