Workload Identity Still Needs a Narrow Trust Policy

Review who can assume a cloud deployment role, not just whether credentials are short-lived. Separate token identity, workflow protections and resource permissions,...

Short-lived credentials answer only part of the question

Replacing a stored cloud access key with workload identity can reduce dependence on a long-lived secret. It does not decide which job should receive access or what that access permits. A trust policy that accepts an overly broad workload set can issue temporary credentials to the wrong job. Review the accepted identity, the workflow that produces it and the role's resource permissions as separate boundaries. The improvement is a controlled access path, not simply a shorter credential lifetime.

Consider a hypothetical organization with one repository and separate beta and production deployments. It wants production access only for an approved release job. The identity provider issues valid tokens to several jobs in that repository. If the cloud role accepts every token from the repository, the production boundary is broader than the business rule. This example is a proposed review scenario, not a description of Ampity's current hosting configuration or an instruction to modify your account.

Ask three questions: which token identity may assume the role, which workflow execution can obtain that identity, and which resources the resulting session can affect. A correct answer to one does not repair a missing answer to another. Store the expected answers with the deployment record so future changes can be reviewed against the actual intended boundary.

Establish the subject and audience your workload actually emits

Do not copy a sample subject string and assume it describes your repository. GitHub's current AWS OIDC guide notes that subject formats can include immutable owner and repository IDs, depending on repository creation and opt-in state. Environment-based jobs also use an environment-specific subject. Confirm the format the controlled job actually uses before writing an exact condition. Do not paste a full token into a public issue or broadly accessible build log. See GitHub's AWS OIDC configuration guidance.

Identify the expected audience as well as the subject. The audience describes the intended token recipient; it is not a replacement for narrowing the workload identity. Keep provider registration and role conditions aligned with the supported integration. If the organization uses custom subject configuration or a reusable workflow, document the emitted identity and the conditions the cloud provider can enforce. An assumption that a claim exists is not evidence that it is evaluated.

The proposed review record should contain the provider, intended audience, accepted subject shape and reason that each accepted pattern is necessary. Use controlled evidence with sensitive material removed. Distinguish a pattern designed for one environment from a pattern accepting all repository activity. A wildcard may be intentional, but it expands the question from whether this release is approved to whether every matching workflow is entitled to the role. That requires a different review.

Separate role assumption from actions on resources

AWS's OIDC role guidance describes the role trust relationship and recommends restricting the GitHub subject to the intended organization and repository. The trust relationship establishes who can assume the role. The permissions granted through that role still need their own review. See AWS's OIDC role guidance.

For the illustrative deployment, write down the artifacts the job can upload, the services it can change and the resources it must not access. A beta job should not gain production authority just because both jobs use the same action. Conversely, a narrowly accepted production job can still have excessive resource permissions. Temporary credentials with a broad administrative policy remain broad administrative credentials during the session. Their expiry does not undo a configuration change or recover a secret the job already read.

Avoid describing a token-request permission as resource-write authority. GitHub's guide explains that id-token: write permits requesting an OIDC token; cloud access depends on the subsequent exchange and role configuration. The useful review therefore follows the entire path instead of checking one YAML line. Record the role selected, account and environment, relevant resource scope and how the job's identity is correlated with resulting activity. A green authentication step does not prove that the deployment affected the intended target.

Environment protection belongs to the identity contract

An environment name is not automatically evidence of human release approval. Examine which jobs can reference it and the applicable protection rules. In the hypothetical design, the production subject identifies an environment, while release eligibility is constrained by the deployment process. If those process controls are removed, the same subject condition can remain unchanged while the practical permission boundary becomes weaker. Include the workflow controls in the review record, not merely the cloud policy document.

Keep access-token acquisition close to the job that needs it. A general build job should not request production deployment credentials when it only compiles and tests. Restrict which untrusted inputs and executable steps can run in the credentialed job. A dependency installation, arbitrary script or changed action can use the job's authority while credentials are available. This is a proposed design concern to investigate in the actual workflow, not a claim that every third-party action is unsafe.

Changes to workflow triggers, environment rules, reusable workflow references and job permissions deserve review alongside role-policy changes. A cloud policy diff alone may miss a changed execution path. The owner should be able to explain what prevents an unintended branch or job from obtaining the accepted identity, and demonstrate the relevant denied case. If the answer relies on a convention people can ignore, it is weaker than an enforced rule and should be recorded that way.

Build an allow-and-deny matrix before broadening patterns

Positive tests show that a selected job can authenticate. Negative tests show whether nearby unintended identities are rejected. Use an isolated role and harmless target where practical; the test should not obtain or exercise production authority merely to prove a boundary. Decide what constitutes denial and retain the observed result. A configuration syntax check is useful but cannot replace exercising the actual exchange under controlled conditions.

| Proposed identity case | Intended decision | Evidence to retain | | --- | --- | --- | | Approved deployment job with expected identity | Allow the test role | Issuer, subject shape, audience and resulting role | | Same repository, unintended branch or execution context | Deny when outside the rule | Actual identity and rejected exchange | | Beta environment requesting the production-scoped role | Deny | Environment distinction and rejected exchange | | Different repository with a valid provider token | Deny | Repository distinction and rejected exchange | | Correct workload identity, unintended resource action | Deny that action | Selected role and rejected harmless operation |

The last row is a permissions test, not a token-trust test. Keep it separate in the result so a denial from one layer does not conceal a permissive rule at another. If a token exchange fails for an unrelated setup error, it does not establish that the intended trust condition worked. Identify the reason and repeat the correct test. Do not count every failure as proof of security.

Failure conditions include a trusted job doing the wrong work

A narrowly identified job can still execute an unintended script, deploy to the wrong account or use an overly broad policy. Trust restrictions reduce the accepted workload set; they do not establish the correctness of the work performed by that set. Use release artifact identity, reviewed executable steps and target-account checks appropriate to the workflow. Limitations should remain visible: a successful allow-and-deny matrix covers the selected cases, not every possible compromise or provider behavior.

An identity migration can also fail operationally. The accepted subject may change after repository or environment configuration changes. A permissions update may break deployment while authentication still succeeds. A fallback that quietly restores a static key can create two active access paths without an owner. Define a controlled reversal procedure and inventory any temporary fallback credentials. Reversal should not broaden the workload accepted by the production role just to make the pipeline green.

Existing sessions and completed actions need separate treatment when access is withdrawn. Do not assume that changing a trust condition reverses prior effects. Determine which sessions or operations may already exist and use the provider's documented controls for the actual case. Preserve the correlation needed to investigate deployment activity. Avoid a generic promise of instant revocation across all cloud platforms and session types. A withdrawal plan should name what is blocked, what remains possible and which evidence closes the uncertainty.

Review evidence should survive the next workflow change

Keep the identity and permission contract near the deployment configuration with an accountable owner. Include the expected subject format, accepted audience, relevant environment controls, role scope and the allow-and-deny results. Record why any broader pattern is needed. When the workflow changes, compare the emitted identity and execution path against that contract. A comment saying OIDC enabled is not enough for an engineer who needs to decide whether a new trigger is safe.

Monitor useful mismatches rather than merely count successful token exchanges. Suggested observations include a deployment using an unexpected role, a role assumed outside the intended release path or an action against an unintended resource. These are proposed review signals, not claims that the organization already collects them. Build the observation path before depending on the alert. Keep identifiers and timestamps sufficient to correlate the run, while avoiding exposure of tokens or credentials in evidence stores.

The next action is to review one role and one workflow together. Observe the expected identity in a controlled run, define the resource scope and execute the proposed matrix against an isolated target. If the negative cases are not rejected for the intended reason, correct the rule before extending the migration. Use the AI software supply-chain paper for the separate question of what executable artifact the job may run, and bring the identity contract to a cloud security review. The outcome is an explainable deployment boundary, not a badge that says passwordless.