For the engagement owner. The relevant attack path often follows a machine identity. Establish what that identity is intended to do, what it can reach and which actions the assessment may demonstrate.
Start with a business-supporting workload
Choose a workload with a clear purpose: process payment events, generate customer reports or deploy a service. Identify its runtime principal, deployment principal and the resources each is intended to access. A host inventory does not capture these relationships, especially when workloads are short-lived or managed by a platform. Document the environment and ownership boundary before choosing test techniques.
The objective is to examine a defined trust relationship, not to collect every credential visible in a cloud account. Agree which identities, resources and operations are in scope and what evidence will establish the relevant permission decision.
Read diagram text
- Purpose
- A defined product or release task
- Principal
- Runtime or deployment identity
- Resource
- The approved operation and target
Distinguish configured permission from demonstrated action
A policy review may indicate that a principal has broad rights. That is useful evidence, but exercising those rights can have side effects and may exceed the test authorisation. Choose a bounded validation method with the owner, such as an operation on a designated canary object. State whether a finding is based on effective-policy analysis, an observed action or both. Avoid implying that every theoretically available operation was attempted.
Record the identity context and resource policy relevant to the result. In layered cloud permission systems, a single policy fragment may not explain the final decision; the evidence needs the conditions that actually applied to the test.
Examine the deployment-to-runtime boundary
Build and deployment systems may issue or retain material that represents a more privileged identity than the running application needs. Identify where that material is stored, who can retrieve it and whether it remains usable outside the intended workflow. Do not validate discovered material against production resources without explicit permission. A canary or owner-assisted observation can often establish the relevant issue with less operational risk.
Our bank CI artefact attack-path guide explains the distinction between exposure, usability and authority. That distinction is equally useful for fintech release pipelines and helps avoid overstating the effect of a secret-shaped string.
Read diagram text
- Policy observation
- Describe effective permission context
- Canary operation
- Demonstrate an authorised bounded action
- Untested capability
- State the inference and limitation
Compare intended and unintended access
Prepare one permitted operation and one prohibited comparison for the selected identity. For example, a report worker may need its own synthetic result store but not another service's canary object. Hold the resource and identity conditions stable enough to interpret the result. Include identity expiry or revocation only where those behaviours are part of the agreed scope and can be observed safely.
A denied comparison is evidence for that case. It does not prove that the entire cloud estate has least privilege. Record the resources, policies and environment version so later reviewers can understand the coverage boundary.
Read diagram text
- Identity context
- Principal, workload and environment
- Policy context
- Relevant conditions and version
- Action context
- Canary result and audit reference
Connect machine access to operational governance
Ask who approves permission changes, rotates or revokes credentials and investigates unexpected use of the workload identity. The pentest may expose a technical path whose treatment needs several teams. Name those responsibilities rather than recommending a broad “IAM review” with no owner. Keep the audit evidence sufficient to connect the controlled action with the principal, workload and canary resource.
When a cloud provider supports a financial entity's advanced exercise, the DORA TLPT third-party coordination guide explains why provider participation and permission boundaries need early attention. A routine cloud pentest remains a separate engagement with its own scope.
Retest the boundary and the workload function
After treatment, repeat the prohibited comparison and confirm that the workload can still perform its legitimate task. Record the deployed policy and workload version. If the fix replaces a credential with another mechanism, validate the resulting authority rather than assuming the new mechanism guarantees narrower permissions. Reconcile temporary test objects and access material at closure.
The report should state what changed, what was observed and what remains outside coverage. That creates a reusable evidence point for future releases and makes permission drift easier to discuss without turning a time-bounded assessment into a claim of continuous assurance.
Read diagram text
- Assign the boundary
- Name the workload and policy owners
- Apply the treatment
- Reduce the unintended authority
- Verify both paths
- Block misuse and preserve the intended task
Primary sources
General information, not a compliance opinion. Confirm legal applicability and testing requirements for your entity and jurisdiction.
This guide and the related sector publications linked above are published by Atlant Security. Technical examples are planning examples, not claims about completed client tests.
