Give the integration one defined job
Before connecting two business tools, write down which identity may use which records, which actions it may perform, and who can remove that access. Grant the smallest supported access that completes the agreed job. Check both an allowed action and an action that must be refused before using real records.
This is called least privilege: access is limited to the work that is needed. Signing in proves an identity; it does not mean that identity should read every customer, change billing or administer the account. OWASP's authorization guidance supports explicit resource/action rules, denial when no rule allows an action, and checks where requests are processed.
This guide helps an owner agree access before a build. The handoff guide covers the wider operating documents. The acceptance guide explains how to record expected and actual test results.
Separate identity, records and actions
Describe the job in one sentence. For example: read ready requests in one intake queue and create a draft task in one team workspace. Then list what the job does not require. This makes it easier to challenge a connector that asks to delete records, manage users or read unrelated workspaces.
Use a stable integration identity where the provider supports one. Record its business owner and its recovery route. Avoid making a long-running workflow depend only on a temporary contractor's personal account. Identity choice, licensing and available permissions vary by provider; confirm them for the actual product before connecting it.
| Part | Record this decision |
|---|---|
| Identity | Which named user, app or service will make the request? Who owns it? |
| Resource boundary | Which account, workspace, queue, folder or record set may it use? |
| Allowed actions | Separate reading, creating drafts, updating, sending, deleting and administration. |
| Duration | When does access expire or need review? Who can stop it? |
| Evidence | Which provider settings and controlled checks demonstrate the boundary? |
“Read only” is an action limit, not automatically a data limit. A connection that cannot edit may still read more records than the task needs. Review the resource boundary as carefully as the action list. Record the actual supported limit rather than a label that sounds reassuring.
Fictional example: intake queue to draft tasks
This example is fictional. A workshop wants ready maintenance requests copied into a draft-task queue for a supervisor. SYN-INTAKE and SYN-DRAFTS are invented resources. The example uses no customer records and connects to no provider.
| Resource | Allow | Must refuse |
|---|---|---|
| SYN-INTAKE / ready requests | Read request ID, equipment reference and a short work summary. | Change the source request, delete it or fetch unrelated queues. |
| SYN-DRAFTS / supervisor queue | Create one draft task with its source request reference. | Dispatch work, send customer messages or modify approved tasks. |
| Account settings | No administration. | Add users, change billing or grant another app access. |
The supervisor's approval is a separate business decision. A successful copy does not authorize dispatch. The destination must enforce the draft boundary; a workflow instruction that says “never send” is not a substitute for a permission control.
Suppose the available connector can create tasks only with workspace-wide edit access. Do not record the proposed matrix as implemented. Record the gap. The owner can choose a smaller dedicated workspace, a suitable restricted endpoint, a manual handoff, or a different supported connection. Any broader access needs a clear decision about the extra records and actions it permits.
Keep the source request reference in each draft. This makes it possible to inspect the copied result without giving the integration permission to rewrite the source. Duplicate prevention is a separate requirement; use the duplicate-action guide when defining retry behavior.
Read what the provider actually grants
An application programming interface, or API, lets software request data or actions from another service. OAuth scopes describe categories of API access. They are not all interchangeable, and an application's requested scope may cover more data than its visible workflow uses.
Google's scope reference lists access descriptions and directs developers to each API method's requirements. Use that reference to compare the intended task with the exact permissions shown in the connection flow. Do not assume a scope limits access to one file unless the relevant documentation and configuration establish that boundary.
GitHub's token documentation gives a concrete provider example: fine-grained tokens can restrict selected repositories and specific permissions, but have feature limits. GitHub also recommends GitHub Apps for long-lived integrations. Check the endpoint requirements and identity model instead of choosing a broad token solely because it works.
When the permissions are broader than the job
Pause the connection and write down the mismatch. A field filter inside a workflow can reduce what it copies. It does not remove the credential's ability to read other allowed fields. Likewise, hiding a delete button does not prove the API refuses deletion. The boundary must be checked at the system that controls access.
Ask the owner to review a concrete alternative with its limits. Do not silently add administrator access to clear an error. Keep the decision record free of token values, passwords and recovery codes. A safe credential reference identifies the stored connection without revealing its secret.
Run eight controlled access checks
These are proposed checks for the fictional agreement. They have not been executed against a client or provider. Use synthetic records in an approved test environment. An untested boundary remains unknown.
- Allowed read: retrieve the agreed fields for one ready SYN-INTAKE request. Confirm the response and identity.
- Allowed draft: create a draft in SYN-DRAFTS. Confirm its draft status and source reference at the destination.
- Other resource: request a synthetic record in an excluded queue. Confirm the provider or authoritative access layer refuses it.
- Forbidden write: attempt a source edit through the controlled test route. Confirm refusal and unchanged source data.
- Forbidden action: test that dispatch and message-sending operations are refused. Do not use real recipients.
- Unrelated identity: check that a different test identity cannot reuse the integration's permitted route.
- Access removed: use the provider's supported revocation process in the test environment. Check subsequent requests and any remaining token lifetime or session behavior.
- Failure handling: simulate refused access. Confirm work is visibly blocked, no success is claimed, and no automatic permission expansion occurs.
Save the expected result, actual result, date, environment and evidence reference for each check. A login success is not evidence that the forbidden actions are blocked. If revocation has a delay or a separate access token remains usable, record that limit and its operating response.
Complete the access worksheet before connection
BUSINESS INTEGRATION ACCESS AGREEMENT One-sentence job: Business owner / technical operator: Provider / environment / integration identity: Allowed accounts, workspaces and record sets: Allowed fields and actions: Forbidden resources and actions: Exact provider permissions / documentation reference: Unsupported limits / alternative / owner decision: Safe stored-connection reference (no secret values): Access expiry / review date / stop-access owner: Revocation route / expected delay / verification: Synthetic test records / approved test environment: Check / expected result / actual result / evidence: Blocked-work message / escalation owner: BEFORE REAL DATA [ ] The agreed read and draft actions work. [ ] Excluded resources and actions are refused. [ ] The destination enforces the draft boundary. [ ] Permission gaps and unknown checks are visible. [ ] The owner knows how to stop access.
Review this agreement when the job changes, the owner changes or the provider requests new permissions. Keep it with the operating handoff. A new action such as sending a message needs a new access decision and completion checks.
Bring the workflow and a redacted access map to a free workflow fit call. ZenOut can scope a business automation around the tools you use, with explicit access limits and visible exception ownership.