Least privilege service identities
Prove that the worker cannot delete its source data
Positive tests establish functionality. Deliberate denial tests establish the boundaries that make a service identity useful.
In this article
Prepare safe resources and the real identity path
Create synthetic input and output resources in an isolated test environment. Deploy the workload through the same identity mechanism used in production, with environment-specific scope.
Confirm which principal the runtime is actually using. A local test can accidentally succeed through a developer's broad credentials while the intended service role is never exercised.
Run the normal read-and-write workflow first so later denials are not confused with a broken credential setup.
Attempt a small set of prohibited operations
Try reading outside the approved input scope, deleting the synthetic source and changing an unrelated configuration. Expect explicit denial under the provider's documented behaviour.
Use harmless test targets and avoid destructive experiments on production data. The test's purpose is to verify policy evaluation, not create a realistic incident.
Record the action, resource and decision. A generic failure is insufficient if it occurred because the resource did not exist rather than because access was denied.
Test the trust boundary separately
Attempt to obtain the workload identity from an unintended test caller. A narrow permission policy is still exposed if another service can assume the role without authorisation.
Check relevant environment, repository or service conditions in the chosen federation mechanism. Use the platform's supported tools rather than crafting an ad hoc credential exchange.
Also test that the legitimate deployment continues to obtain credentials after renewal. Temporary access must remain both bounded and operational.
Exercise uncommon recovery paths
Cause a partial output failure and run cleanup or retry. Verify that the required recovery action succeeds without granting unrelated administration permissions.
For a synthetic month-end path, the worker may read an additional approved partition that ordinary daily tests never touch. Include it explicitly in fixtures instead of assuming recent access logs cover the whole job.
Review any failure against the operation matrix and effective policy context. A passing suite demonstrates the intended allow and deny cases for the tested environment, while remaining coverage gaps should stay visible.
Primary sources
AWS: IAM security best practicesAWS: policy generationReferences checked 11 September 2026.