Build a permission matrix from the worker's operations

List normal and recovery operations

Write down each external operation the workload performs and the resource involved. Include startup, scheduled work, retry, cleanup and shutdown paths where they require access.

For a synthetic report worker, the matrix might allow reading approved input objects and writing reports under one output prefix. It would not include deleting input or changing bucket policy.

This example is a design record, not deployable IAM syntax. Provider policies require the service's exact action, resource and condition semantics.

{
  "workload": "daily-report-example",
  "operations": [
    { "intent": "read approved input", "scope": "production/report-input" },
    { "intent": "write report output", "scope": "production/reports/daily" }
  ],
  "prohibited": ["delete source data", "change access policy", "deploy code"]
}

Create the workload trust boundary

Configure the platform's supported identity mechanism for the intended service or job. Restrict who may obtain that identity using the relevant trust conditions.

Avoid distributing a shared long-lived credential when a supported temporary mechanism fits the workload. Verify how credentials are refreshed and how the SDK discovers them in the real runtime.

Keep deployment identity separate so the running service cannot update itself merely because CI needs that permission.

Translate the matrix into provider policy

Use exact supported actions and resource forms. Check whether each action supports resource-level constraints and which conditions apply. Document any necessary broader scope rather than hiding it inside a copied managed policy.

Inspect other grants and restrictions that affect the principal. Resource policies and organisation controls can change the effective result beyond the role's own policy file.

Verify with the actual runtime principal

Run representative allowed operations in a controlled environment under the deployed workload identity. Then attempt specific prohibited actions against safe synthetic resources and confirm denial.

Test a rare recovery path and credential renewal as well as startup. Save the principal identity and policy version in the verification evidence without recording credentials.

Promote the reviewed policy with the application change and monitor unexpected denials. Diagnose the missing operation before widening access, so the matrix remains the explanation for each permission.