Give every automation connection an owner and an off switch

Start with the connection that must survive a handover

A coordinator authorizes a workflow using their own account. Months later they leave, and a scheduled task still appears healthy until its next attempt to read a customer record fails. The urgent question is not only how to reconnect it. Who approved this access, what can it reach, who is allowed to replace it, and how will the team prove the old grant no longer works?

Make one connection record for each distinct authorization used by an automation, including the source read, destination write and any secret store or callback subscription it depends on. The downloadable matrix turns those questions into an ownership and lifecycle decision. It contains an empty row and a clearly hypothetical example; it is a planning document, not a place to store credentials.

This guide owns access to connected tools over time. The API-integration checklist asks whether a proposed vendor connection can perform the required operations at all. The web-app permission matrix governs actions on records inside an application. The system-of-record guide assigns authority to business values. None of those decisions establishes who will maintain and revoke an automation’s external authorization.

Name the owner and the identity that actually authenticates

Record a business owner who approves the purpose and a technical custodian who can change the connection. Name deputies and the provider-side administrator who can remove a grant if the normal custodian is unavailable. A third-party automation platform may operate the connector, but the organization still needs a person who can account for the authorization and its downstream effects. OWASP’s secrets guidance explicitly calls for purpose, consumers, lifecycle dates and a trouble contact in secret metadata.

Write down whether the connection uses a delegated person’s OAuth consent, an application or service identity, an installation token, or a static API key. These are different lifecycles. A personal grant can be affected by the person’s account and consent; an application identity may outlast staff turnover but needs its own ownership, credentials and review. Microsoft Entra distinguishes managed identities, service principals and user accounts used as service accounts, and recommends limiting credentials to an anticipated use period. Choose only an identity model the actual provider and account plan support.

Avoid a shared human login as a shortcut to continuity. It weakens attribution and makes normal staff changes harder to manage. Where a supported workload identity can perform the job, assess it. Where the vendor requires a person’s delegated consent, document the dependency, obtain appropriate consent, and define the reauthorization path before that person leaves. Keep a private provider reference or secret-manager item ID in the operational register if needed; never put a token, password, recovery code or full authorization URL in this public worksheet.

Translate each workflow step into minimum access

List the operation, the data it touches and the narrowest supported grant. A workflow that reads newly approved requests does not automatically need permission to edit all requests, send mail or administer users. Check both the named API permission or OAuth scope and the resource boundary: which account, project, repository, mailbox, folder or records can the connection reach? Also record who can read or replace its stored secret. Google’s OAuth policy requires the smallest scopes needed for a user-chosen function. GitHub’s app guidance separately describes requested permissions and the repositories selected at installation.

Use the provider’s live permission screen and documentation for the intended account, then run a safe test using synthetic or authorized data. A scope name alone may not tell you the whole effect. For example, GitHub says a user access token is constrained by both the app’s and user’s permissions, while installation-token access depends on the app’s granted permissions. Record the effective behavior and any product-plan or admin-consent limitation; do not infer it from a generic OAuth label.

If the provider offers only a broad grant, write that excess access in the matrix and give the business owner a real decision: accept a documented risk with compensating limits, redesign the step, use a different integration path, or keep the work manual. Do not describe an unsupported narrow scope as if it were enforceable. Re-review permissions when a workflow gains a new action or the provider changes its grant model.

Copy the connection-access matrix

Download the CSV above. Make one row per grant rather than one row per whole workflow. The thirteen headings below cover ownership, authority, exposure, replacement, removal and dated review. The completed rows are illustrative decisions for a fictional repair business; replace them only after checking the real provider’s capabilities. Store a live copy in a restricted operations location because even a secret-free inventory can reveal where access exists.

• Connection and workflow step | Business purpose and data | Provider and identity model | Business owner and deputy | Technical custodian and provider admin | Minimum operations and resource boundary | Grant evidence and excess access | Secret store reference and readers | Rotation trigger and replacement test | Revocation trigger and method | Dependencies, stop rule and proof | Access review date and decision owner | Next review due and change trigger.
• Purpose and boundary: describe the one action this grant performs. Separate read and write grants when the provider permits it; name exactly which resources are included and excluded.
• Grant evidence: note the permission review and a synthetic or authorized allow/deny test. Record the actual review date, decision owner, next review due and earlier change triggers in their own columns. Put unresolved excess access in plain language, with an owner decision.
• Secret reference: record only an opaque internal reference and who may retrieve or change it. Never paste the actual key, token, password, refresh token or recovery material into this CSV.
• Lifecycle: specify what starts routine replacement, what starts emergency removal, the provider-supported action, the dependent jobs to pause and the evidence that the new path works and old path is disabled.

Rotate without silently breaking the job

Rotation means replacing a credential while preserving the authorized connection. Revocation means ending a specific credential or grant. They are related but not interchangeable: changing a value in your secret store does not prove the provider invalidated the previous value. OWASP describes creation, rotation, revocation and expiration as separate secret-lifecycle stages and warns that stopping the consumer does not itself revoke a stolen credential.

For a planned replacement, inventory every consumer, confirm whether the provider permits overlapping credentials, create the replacement through the approved route, store it privately, switch one controlled consumer, and test the required read or write with an authorized test object. Confirm the expected downstream record or action, not just a “connected” badge. Then remove the prior credential at the provider, check that it no longer authenticates where a safe negative test is available, and update the register. If overlap is impossible, plan a pause and a manual fallback before changing the credential. GitHub’s private-key guidance is one concrete example of overlapping keys for a no-downtime rotation; its key behavior is not a promise for other vendors.

Set the replacement trigger from the real credential lifetime, provider guidance and business risk. Do not impose one universal calendar interval on access tokens, refresh tokens, application keys and human passwords. OWASP distinguishes non-human secret rotation from user-password practice; Google’s OAuth guidance says unused tokens should be revoked and removed. If a provider rotates refresh tokens automatically, verify how the connector handles the replacement rather than trying to treat the refresh token as a manually copied static key.

Revoke access at the provider and prove the outcome

Create a short off switch for each grant. Triggers include a retired workflow, a departed grant owner when the authorization is personal, a suspected exposure, a changed provider relationship and a permission that is no longer needed. The stop sequence should identify which scheduled jobs and queued actions must be paused, which grant or key is removed in the provider, which local copies are deleted, who checks the result, and how legitimate work continues. For a suspected exposure, contain it promptly through the provider’s supported revocation path and investigate what the old credential could access.

Provider behavior matters. Google documents that revoking a user’s OAuth grant for a project removes that user’s previously granted scopes and invalidates issued access and refresh tokens for that project’s clients; the effect may take time. GitHub documents separate app-installation and OAuth authorization controls. Before using a broad “revoke all” action, check its blast radius in the actual provider account. A changed staff password, disabled local automation, or deleted secret-manager entry is not, by itself, evidence that the provider grant ended.

Record a timestamped provider-side result, a safe denied-access check where possible, and the status of dependent jobs. Do not log the credential or raw provider response if it contains one. If revocation cannot be confirmed, mark the connection unresolved, keep risky actions paused and escalate to the provider administrator. The automation-failure-recovery guide covers retries and uncertain business actions after a connection fails; this sheet records who can terminate the access and how they know it is terminated.

Hypothetical example: an equipment-repair intake workflow

Imagine an invented repair company connecting an intake system, a scheduling tool and a notification service. No company, integration, permission set or result here describes a Kinetivy client. The CSV has three filled rows showing decisions to verify with the chosen providers. Its “read approved requests” and “create provisional visit” operations are example business needs, not claims about a vendor API.

• Intake read grant: the operations lead owns the purpose, the integration custodian maintains a dedicated supported app identity, and the provider admin can revoke it. The proposed boundary is approved requests in one workspace. The team must verify whether the provider can restrict both read operation and workspace; a broad all-record grant remains an open decision.
• Scheduling write grant: a separate authorization proposes a visit, with no delete or account-admin capability. Before replacing its credential, the team pauses the scheduled job, switches the stored reference, creates a synthetic visit and checks it in scheduling, then removes the old grant. If a safe old-credential denial cannot be tested, the provider-side revocation receipt and administrator review remain explicit evidence limits.
• Notification grant: the business owner approves messages only after an accepted scheduling result. If the notification provider requires a person’s delegated consent, the matrix names that dependency and a reauthorization owner. Retirement pauses queued sends first, revokes the provider grant and checks that no further messages are scheduled. Content, consent and message stop rules belong to the separate lead-follow-up and notification guides.
• If the intake custodian leaves unexpectedly, the provider administrator does not guess at hidden tokens. They inspect the private register, pause dependent work, determine whether the grant is personal or application based, revoke the affected provider access, restore only the approved minimum access through a new owner, and test the complete business result. This is a rehearsal scenario, not an incident report.

Review the connection when its purpose changes

At launch and each material change, ask the business owner to approve the purpose and excess-access decision, and the custodian to demonstrate the authorized operation, denied operation where safely testable, replacement path, provider-side removal path and dependency pause. Revisit when a new workflow step, account plan, provider permission, team owner or data purpose changes. Record the date and next owner review in the restricted register.

A connection inventory is useful only if an operator can act on it. Start with the highest consequence write grant and fill in its owner, exact resource boundary and off switch. Then cover read grants and lower-risk dependencies. The workflow-readiness guide helps decide whether the process should be automated; this guide is the standing agreement for the access the automation uses.