By Greg Nowak. Updated 20 September 2026.
AI workflow pilots are usually judged by their visible result: Was the summary accurate? Did the CRM record update? Did the message reach the right Slack channel?
Those checks matter, but the more consequential business decision may have happened earlier, when somebody clicked Allow. That action can let an app read documents, inspect conversations or change operational records within the consenting user’s access. An API key pasted into a workflow builder can create a similar exposure without displaying a consent screen.
The answer is not to avoid useful integrations. It is to treat access as part of the pilot design—not as installation housekeeping. A temporary experiment should not leave behind a permanent connection with broad permissions, unclear ownership and no tested way to stop it.
Read the permission request as a business document
A product may be marketed as a meeting assistant, reporting bot or document summariser. That description does not establish what the integration can reach. The requested scopes and credentials do.
Translate each permission into operational language. Can the app post a message, or also read conversation history? Can it open files selected by a user, or search an entire workspace? Can it only retrieve CRM records, or modify and delete them?
Then compare that access with the pilot’s stated job. If a workflow only posts status updates, permission to browse files needs a specific justification. If it summarises documents, email access should not be accepted simply because it may support a future feature.
| Decision | Evidence to record | Sensible pilot boundary |
|---|---|---|
| Who owns it? | Business owner and technical owner | Responsibility survives staff absence or departure |
| What can it reach? | Scopes, endpoints, folders, channels and records | Only data required for the approved task |
| Which identity does it use? | User, bot, service account or API key | Automated work uses a dedicated identity |
| How is impact contained? | Workspace, project, model, rate and spend settings | The boundary matches the pilot, not the organisation |
| How does it stop? | Revocation steps, authorised operator and review date | Shutdown does not depend on the original installer |
Put access decisions in the pilot brief
Add a one-page access record to the normal pilot brief before installation. It should name the business task, connected systems, affected data, requested permissions, credential location, accountable owners, review date and shutdown procedure.
Record the exact scopes rather than keeping only a screenshot of the product name. Permissions may change when an integration is reauthorised or new capabilities are enabled. The record creates a baseline against which an owner can recognise that change.
The approval should also state what is deliberately excluded. Examples include customer mailboxes, production write access, unrestricted file search or the ability to invite users. These exclusions make it easier for an agency, internal team and client to recognise when a promising prototype has become a materially different project.
Use the boundaries your platforms already offer
In Google Workspace, administrators can review configured, accessed and pending apps under API controls. Google exposes requested services and OAuth scopes and supports access states including Trusted, Limited, Specific Google data and Blocked. Its current administrator guidance also notes that app details may take 24–48 hours to appear, so a same-day inventory may not be complete.
For Slack, start with the methods and events the bot genuinely needs, then request the corresponding bot scopes. Avoid a user token when a bot identity can perform the work. Slack’s scope reference describes scopes as permissions for particular actions or data. Since March 2026, developers can also classify non-essential permissions as optional; users may decline them, and the app should continue to provide features that do not require them. That is useful separation, not a reason to request speculative access.
For OpenAI API work, place a meaningful pilot in its own project rather than sharing one personal key across unrelated experiments. A project service account provides a non-human identity restricted to that project. However, OpenAI’s project documentation says its initial key defaults to read-and-write access across the project’s API resources. Review the key immediately and choose Restricted or Read Only permissions when appropriate.
Project model permissions, rate limits and spending controls provide further containment. OpenAI now supports both monitoring-only spend limits and enforceable hard limits. Confirm which behaviour is actually configured: an alert may notify an owner while requests continue, whereas an enforced limit causes requests to fail. Your workflow needs a safe response to either event.
Design and test revocation before approval
“We can remove it later” is not a shutdown plan. Document where the app is blocked, where its token or key is revoked, who can perform each step and what happens to scheduled jobs, webhooks, refresh tokens and queued work.
Test this during the pilot. Revoke a test credential and confirm that the workflow fails safely—without repeated customer messages, endless retries, silent partial updates or a fallback to somebody’s personal account. If the test continues, issue a new credential rather than restoring the old secret to multiple tools.
This is a practical application of the principle in NIST’s Zero Trust Architecture: ownership or location alone should not create implicit trust. A familiar vendor, respected employee or internal bot still needs an explicit purpose, bounded access and periodic review.
Start with the integrations already running
If your organisation already has several pilots, begin with an inventory rather than a redesign. List active OAuth apps, API keys and service accounts alongside their owner, purpose, permissions, affected data, last use, spending boundary and revocation procedure. Remove stale connections and give every remaining one a review date.
This is not just security administration. A visible, repeatable approval path helps operations teams and agencies launch worthwhile experiments faster because the boundaries are agreed before implementation.
If your integrations have grown faster than their ownership model, Greg can help turn them into a practical inventory, cleanup plan and repeatable pilot process. Start with a focused review of one workflow or access layer.
Related on GrN.dk
- Not Every AI Job Needs an Instant Answer: Batch the Backlog
- Your AI Agent Has Shell Access. What Can It Reach?
- Your AI workflow has logs. Can they explain one bad decision?
Need help with this kind of work?
Review an AI workflow with Greg Get in touch with Greg.
