Before handing deployment to an overseas team: permissions and OIDC responsibility boundaries

THE TAKEAWAYS

What to take away

Review repository and cloud permissions separately.
Hand over OIDC trust conditions and responsibility for changes.
Verify permission and rejection, and identify the contact for exceptions.

EDITORIAL PRACTICE

Separate the ability to run from readiness to delegate

This article treats application testing and production resource changes as separate responsibilities. The following is an editorial design proposal, not a reported company deployment or a safety guarantee.

Start with an operation list rather than a key inventory. List source checkout, artifact creation, deployment to validation, deployment to production and emergency suspension, identifying the actor and permitted targets for each. Avoid abbreviations understood only by the domestic team, and share how to identify the target environment. “Administrator access is faster” does not explain why that access is necessary.

Sources:

FROM PRIMARY SOURCES

Do not confuse GitHub permissions with cloud permissions

GitHub explains that an action may access the token through its context without explicitly receiving it, and recommends limiting GITHUB_TOKEN to the minimum necessary permissions. [1]

On that basis, we recommend two review layers: repository reads and writes, followed by cloud resource operations. Restricting the first does not remove broad permissions in the second. The review record should separately explain why a testing job does not need production operations and why a deployment job does not need unrelated resources. A request for additional permissions can include the failed operation and its necessary target, rather than treating broad access as the default remedy.

Sources: [1]

FROM PRIMARY SOURCES

OIDC reduces secret handoffs; it does not replace approval

GitHub OIDC obtains short-lived credentials for a job after trust has been established with a cloud provider. The provider compares token claims against configured conditions. [2]

What must be handed over is therefore the meaning of the trust conditions and responsibility for changing them, rather than a long-lived secret. Our proposal is a single-page account of which execution path in which repository can reach which environment. Successful authentication is not the same as permission to make a production change. Recheck configuration syntax in the adopted cloud provider's official documentation instead of copying an example from a different environment. Short-lived credentials still permit mistakes within their scope if acquisition conditions or operation permissions are broad.

Sources: [2]

EDITORIAL PRACTICE

Add rejection tests to success tests

Acceptance planning should verify not only deployment to validation through an approved path, but also rejection of out-of-scope execution. A hypothetical example is testing an unexpected environment selection or an unauthorized operation against safe validation resources only. This does not mean destructive production testing or unauthorized permission expansion. Agree on testing authority and impact first.

Record the workflow version, target environment, expected permission or rejection, and actual result. Token contents and secrets are unnecessary. “Access failed” alone does not distinguish an intended control from a configuration error. The reviewer should inspect the reason and explain that execution stopped at the intended boundary. Evidence that both time zones can read supports a design less dependent on verbal overnight approval.

Sources:

EDITORIAL PRACTICE

Track permission changes alongside team changes

After launch, initial settings will change. Decide who rechecks trust conditions when an environment is added, a repository moves or a team member changes. Our proposal groups the reason, approver, scope and review date, giving exception permissions an expiry or removal condition. Include removal of unnecessary access in completion criteria rather than recording additions alone.

During an incident, distinguish who suspends new deployments from who checks cloud permissions. The handoff criterion is not whether the overseas team can do everything alone. It is whether necessary work is possible, out-of-scope work stops, and the team knows whom to consult about exceptions. A practical first step is to articulate and verify these boundaries in one validation environment before proceeding to production handoff.

Sources:

WITH OPERUN.

Delegate everyday AI management.

For example, during handoff, the domestic owner can explain the execution identity while the overseas owner explains the target resources, then compare their understanding. Hold disputed items before execution. Rather than assuming that showing a configuration establishes understanding, ask each owner to describe their responsibility for routine and exceptional operations. This can reveal responsibility gaps that a procedure alone does not expose. The cover is an AI-generated image of fictional people and a workspace.

Discuss your product and AI work

Primary sources

Sources checked on 2 November 2026. The workflows and checklists are editorial proposals.