How do you audit who holds the AWS AmazonECSTaskExecutionRolePolicy Managed Policy?

Audit who holds the AWS AmazonECSTaskExecutionRolePolicy Managed Policy by listing every IAM role, user or group attached to it, then tracing where each role is assumed from. Check whether the attachment is still needed, whether the role is limited to ECS task execution, and whether any non-ECS workload has inherited it. Remove unnecessary attachments and review trust policies for scope.

What the managed policy attachment actually tells you

The policy name is only the starting point. A useful audit asks which IAM roles have the policy attached, whether those roles are truly dedicated to ECS task execution, and whether any of them have drifted into broader use by applications or teams that were never meant to inherit that permission set. The real control question is whether the policy still matches the workload boundary it was created for.

For AWS IAM policy and role relationships, the important distinction is between a permission set and the trust path that allows a role to be assumed. AWS IAM Policies and Roles Guide is the most direct reference for tracing attachment, evaluation logic, and role assumption so you can separate intended ECS usage from accidental inheritance.

In practice, this means you should not stop at “who is attached.” You also need to confirm who can assume each role, whether that assumption is coming only from ECS task execution, and whether the attached policy is compensating for a broader trust or permission design problem. If the role is being reused outside ECS, the audit has already exposed a governance issue, not just a permissions inventory issue.

How to trace exposure from attachment to effective use

Start by enumerating every role, and if applicable any users or groups that have permission to manage or assume those roles, then map each one to the workloads that actually use it. Follow the chain from attachment to role assumption to runtime use, because a policy can remain formally attached long after the original ECS service has been retired or repurposed. That is where stale access usually hides.

The broader pattern is workload identity governance, not just policy hygiene. Cloud Workload Identity Guide helps place ECS task execution roles in the wider context of role assumption, temporary credentials, and keyless workload access, which is useful when you need to decide whether a role is still a valid workload control or an inherited shortcut.

You should also inspect the trust policy for each role and compare it to the actual service boundary. For an ECS execution role, the trust relationship should be narrow enough that the role is not casually reusable by unrelated compute, CI/CD, or administrative paths. If a role can be assumed in more than one operational context, the attachment audit should be treated as a candidate privilege review, not a routine housekeeping task.

When the audit shows reuse beyond ECS, the policy may still be valid, but the control objective changes. You now need to decide whether the role should be split, whether the trust policy should be narrowed, or whether the same permission set is being used as a convenience layer for multiple workloads. The later options increase the chance that a policy intended for task execution becomes a general-purpose access path.

What to remove, what to keep, and what to verify next

After you identify every holder, look for three outcomes: a role that no longer exists, a role that still exists but is no longer tied to ECS, or a role that is legitimately used but should be scoped more tightly. The first case calls for removal. The second calls for trust-policy and attachment review. The third calls for confirmation that the role has not accreted unrelated permissions over time.

If you need a second opinion on the governance side of the audit trail, Ultimate Guide to NHIs, Regulatory and Audit Perspectives is a useful anchor for access review and recertification thinking, even when the immediate subject is AWS IAM rather than a broader identity programme. It is especially relevant when the same role ownership, review cadence, or exception handling has to be documented for audit evidence.

Keep the cleanup decision tied to runtime reality. If a role is attached to the policy but no ECS task still depends on it, remove it. If the role is still in use, verify that its trust policy, attachment scope, and downstream assumptions are consistent with the workload that depends on it. A clean attachment list is not enough if the role can still be assumed from an unexpected path.

Risk and Threat Considerations

Over-broad or stale attachments turn a task execution policy into an access persistence mechanism. The risk is not just excess privilege, it is that a role intended for one ECS workload can become reusable by another workload, a human operator, or a compromised deployment path if trust and attachment review are not kept in sync.

Failure mechanism: A policy remains attached after the original ECS use case has changed, and the trust relationship allows the role to be assumed from a wider path than intended. That creates a low-friction privilege boundary that may be inherited by unrelated workloads or abused after compromise.

Impact: An attacker or misconfigured workload can gain the ability to execute with permissions that were supposed to be limited to ECS task execution, increasing blast radius, complicating incident response, and making it harder to prove which workload legitimately used the role.

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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	Roles and attachments must be inventoried and reviewed for continued need.
	IA-5 — Authenticator Management	Role assumption depends on credential and token lifecycle control around the execution path.
	AC-6 — Least Privilege	The policy should remain limited to ECS task execution and not spread to unrelated workloads.
Recommendation — Review accounts and role relationships regularly and remove unnecessary access assignments. Rotate and govern credentials or tokens that enable role assumption. Constrain role permissions to the minimum needed for the ECS execution use case.
CIS Controls v8	CIS-5 — Account Management	This audit is fundamentally about who has access and whether it is still justified.
Recommendation — Inventory, review, and remove unnecessary account and role access.
OWASP Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	An ECS execution role is a non-human identity that can become overprivileged through reuse or drift.
Recommendation — Reduce any role permissions that exceed the workload's actual execution needs.

Practitioner Guidance

What to verify: Confirm the attachment list, the trust policy, and the live ECS services using each role before you approve any retention decision. If one of those three does not match the others, treat the role as suspiciously over-retained until proven otherwise.

Decision rule: If a role is attached to this policy but no current ECS task needs it, remove it immediately. If the role is still needed, keep the policy only when the trust policy and runtime usage are narrowly aligned to that ECS workload and nothing else.

Practitioner takeaway: The audit is complete only when you can explain both why the policy is attached and why the role is still safe to assume in its current trust boundary.