A source profile is the originating AWS configuration profile whose credentials are used to assume another role. It lets a tool chain trust one primary identity and then derive temporary access into other accounts or environments. This pattern is common in multi-account setups with a central management account.
What a source profile does in cross-account access
A source profile is the originating AWS configuration profile that supplies the credentials used to assume a different role. In practice, it is the trust anchor for a tool chain that starts with one primary AWS identity and then pivots into temporary access elsewhere.
This makes the profile part of the access path, not just a convenience setting. If the source profile is overly broad, stale, or shared too widely, every role assumption built on top of it inherits that weakness.
The pattern is common in centralized management account designs, where operators, automation, and CI/CD systems need to reach multiple accounts without embedding long-lived credentials everywhere. That is why the source profile should be understood as a controlled starting point for delegation, not as a passive configuration record.
How role assumption changes the security model
Source profiles matter because they separate the original credential used to start the session from the temporary credentials issued after the role is assumed. That separation improves containment, but only when the initial profile is tightly governed and the target role is narrowly scoped.
The main security questions are who can use the source profile, what it can assume, and how long the resulting access remains valid. Those decisions determine whether the pattern supports least privilege or quietly becomes a reusable bridge into many environments.
In mature setups, source profiles are paired with short-lived credentials, explicit trust policies, and clear account boundaries. If those controls are weak, the profile can become a single high-value path to multiple downstream resources.
Where source profiles fit in AWS operating patterns
Source profiles are most useful in multi-account estates, central administration setups, and scripted workflows that need controlled access without manual login friction. They are a practical way to let one identity obtain temporary access across accounts while preserving an auditable chain of delegation.
They also help separate human operator credentials from the roles used for day-to-day administration or automation. That separation is valuable because it reduces the need to reuse the same access key or session across every environment.
For this pattern to remain safe, the originating profile should be treated as sensitive access material, with tight control over storage, rotation, and usage context. If it is copied into too many developer machines, build jobs, or shared scripts, it stops being a clean source of delegation and starts becoming a broad exposure point.
NHIMG’s Ultimate Guide to NHIs is useful background for the broader governance issues that surround credentials, temporary access, rotation, and visibility.
One useful signal from that research is that 97% of NHIs carry excessive privileges, which is a reminder that the starting identity behind a source profile should be kept as small as possible.
Common mistakes and practical interpretation
The most common misunderstanding is to treat the source profile as merely a local AWS CLI convenience. In reality, it is the first hop in a trust chain, so its permissions, secret handling, and trust relationships directly shape downstream risk.
Another mistake is assuming that temporary credentials remove the need to protect the source profile carefully. Temporary access lowers exposure duration, but it does not fix a weak origin identity or a permissive assume-role path.
When reviewing this pattern, practitioners should pay close attention to profile naming, storage location, role trust boundaries, and whether the same source profile is reused across unrelated automation paths. Those are often the places where the true access model becomes visible.
Risk and Threat Considerations
Source profiles create concentration risk because compromise of the originating credentials can unlock every role they are allowed to assume. That makes them attractive to attackers who want a single foothold that can expand into multiple accounts, services, or environments.
Failure mechanism: Overbroad trust, long-lived credentials, or insecure storage lets an attacker reuse the source profile as a launch point for privilege expansion and lateral movement through assumed roles.
Impact: A single compromised profile can expose multiple AWS accounts, weaken audit confidence, and enable persistent access that looks like legitimate role assumption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Source profiles govern access paths and role assumption permissions. |
| 5 — Account Management | The source profile depends on lifecycle control of the originating account credential. | |
| Recommendation — Restrict source-profile permissions to the minimum roles needed for the workflow. Inventory and disable unused source-profile credentials and linked accounts promptly. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Source profiles are a direct access-control mechanism for delegated AWS access. |
| PR.AA — Identity Management, Authentication and Access Control | The originating profile authenticates the caller before temporary role access is issued. | |
| Recommendation — Apply least-privilege access policies to the originating profile and its assume-role targets. Authenticate and authorize the source identity before any role assumption is allowed. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Credential and Secret Rotation | Source profiles often rely on long-lived credentials that should be rotated and minimized. |
| Recommendation — Rotate the source credentials regularly and remove any long-lived secrets from the workflow. | ||
Practitioner Guidance
Governance implication: Treat the source profile as a privileged entry point, not as an incidental config file. Its owner, allowed assumptions, and credential source should be explicit, because the profile defines the starting scope for every downstream session it creates.
What to watch for: Reused profiles, static credentials, and broad assume-role permissions are the main warning signs. If one profile feeds many automation paths, review whether its access footprint is larger than the work it actually needs to perform.
