Learn how AWS-managed, customer-managed, and inline policies differ — and how policy design can affect permission review, change control, and security risk.

============================================================ INTRODUCTION: TWO IDENTITIES, SIMILAR PERMISSIONS, DIFFERENT MANAGEMENT

Imagine an AWS account with two IAM roles. Both appear to grant the same S3 read permissions. One role receives those permissions through a customer managed policy. The other has an inline policy embedded directly in the role.

At first glance, the effective permissions might look identical. The management model is not.

The managed policy can be attached to multiple identities, and a change to that policy affects every attached identity. The inline policy belongs to one identity and must be changed there. If the role is deleted, its inline policy is deleted with it.

That difference matters to administrators, developers, auditors, and security researchers. Permission review is not only about reading the JSON. It is also about understanding how permissions are stored, reused, changed, and removed.

This article explains three identity-based policy types:

AWS managed policies
Customer managed policies
Inline policies

It also explains how to review them safely without confusing policy type with effective access or vulnerability impact.

============================================================

FIRST, WHAT IS A MANAGED POLICY? ============================================================

A managed policy is a standalone IAM policy object. It has its own Amazon Resource Name (ARN) and can be attached to IAM users, groups, and roles.

There are two types of managed identity-based policies: AWS managed policies and customer managed policies.

An inline policy is different. It is embedded directly into a single IAM identity — an IAM user, group, or role — and maintains a one-to-one relationship with that identity.

A simplified view:

Managed policy:

Customer managed policy |

— — — — -+ — — — — -+ | | IAM role A IAM role B

Inline policies:

IAM role A IAM role B | | Inline policy A Inline policy B

Even if the two inline policies contain identical JSON, they are separate policy documents. They are not one shared policy object.

The policy type tells you how permissions are managed. It does not, by itself, tell you whether those permissions are excessive or exploitable.

============================================================ 2. AWS MANAGED POLICIES

AWS managed policies are created and maintained by AWS. Customers can attach them to supported IAM identities, but cannot directly edit their policy documents.

Examples include AWS-managed policies for common job functions or service access. The exact permissions in a named policy should always be checked in the current AWS Managed Policy Reference rather than assumed from the name alone.

The main benefit is convenience. AWS provides reusable policies for common tasks, and updates made by AWS to an AWS managed policy are applied to the identities using that policy.

That convenience creates a security review consideration: permissions may change over time without an administrator editing each attached identity individually.

For example, a policy designed for broad read-only access may be updated as AWS services and API operations evolve. A researcher reviewing an identity should inspect the policy's current document and its scope, not rely on a memory of what the policy granted last year.

Security questions to ask:

Is this policy broader than the workload requires?
Does it grant access across many services or resources?
Is the identity's job consistent with the policy's purpose?
Have you inspected the current policy document and checked relevant AWS-managed policy change information where available?
Could AWS-managed policy updates affect the identity's permissions in the future?

Do not treat every AWS managed policy as unsafe. The security question is whether the permissions fit the identity's actual purpose and operating context.

============================================================ 3. CUSTOMER MANAGED POLICIES

Customer managed policies are standalone policies created and controlled by the AWS customer. They can be attached to multiple users, groups, and roles, including identities that need a common permission set.

They are useful when a team needs centrally managed permissions tailored to its environment.

For example, an organization might create a policy that permits an application role to read objects from one designated S3 bucket. The same policy could be attached to multiple roles if those roles genuinely require the same access.

A simplified illustrative policy might look like this:

{ "Version": "2012–10–17", "Statement": [ { "Sid": "ReadReportsBucket", "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::example-reports-bucket/reports/*" } ] }

This is an illustrative policy, not a claim about a real AWS account. It grants the listed action on objects matching the resource ARN, subject to the complete authorization context and any applicable restrictions. It does not, by itself, grant permission to list the bucket or access other objects.

A major operational advantage is centralized change management. When a new version of a customer-managed policy becomes the default version, that version governs the identities to which the policy is attached. IAM stores up to five versions of a customer-managed policy, which can support rollback. Versioning is not the same as a complete change-approval or audit process; teams still need to track who changed a policy and why.

Centralization is also a risk multiplier. An overly broad change can affect every identity attached to the policy. Before editing a shared policy, administrators should identify its attached principals and assess the impact of the change.

Security questions to ask:

Which identities use this policy?
Does each identity need every permission it grants?
Are resources and actions scoped as narrowly as practical?
Who can create, edit, attach, detach, or delete the policy?
Is there a review and rollback process for policy changes?

Customer managed does not automatically mean least privilege. It means the customer controls the policy and can tailor it.

============================================================ 4. INLINE POLICIES

Inline policies are embedded directly into a single IAM user, group, or role. They are intended for permissions that have a strict one-to-one relationship with that identity.

For example, a deployment role may need one narrowly scoped permission for a resource unique to that role. An inline policy can keep that permission attached to the identity it was designed for.

Inline policies are not shared policy objects. If two roles contain the same JSON, each role has its own policy document. Updating one does not automatically update the other.

When an IAM identity is deleted, its inline policies are deleted with it. This can help preserve the one-to-one relationship, but it can also make policy discovery and change review harder if the organization has many inline policies.

Security questions to ask:

Why is this permission specific to this identity?
Does a similar inline policy exist on other identities?
Is the policy documented and reviewed?
Could the permission be managed more consistently through a customer managed policy?
Will deleting or replacing the identity remove permissions that another workload still depends on?

Inline policies are not automatically more secure or less secure than managed policies. Their suitability depends on the intended management model, scope, and operational controls.

============================================================ 5. QUICK COMPARISON

Policy type | Who manages it? | Can the customer edit its document? | Reusable across identities? | Key security consideration

AWS managed policy | AWS | No | Yes | AWS updates can change permissions for all attached identities.

Customer managed policy | Customer | Yes | Yes | A change can affect every identity attached to the policy.

Inline policy | Customer | Yes | No; one identity per policy | Permissions are identity-specific, but similar policies can drift across identities.

The usual AWS guidance is to prefer managed policies in most cases. For customer-specific least privilege, customer managed policies often provide the most direct control. Inline policies remain useful when the strict one-to-one relationship is intentional.

This is a design guideline, not a rule that every inline policy is a finding.

============================================================ 6. THE DIFFERENCE BETWEEN POLICY TYPE AND POLICY EFFECT

One common review mistake is to treat the policy's type as the security verdict.

A managed policy can be overly broad. An inline policy can be tightly scoped. A customer managed policy can be written well or badly. None of those conclusions follows from the label alone.

Review the policy document and the identity's purpose. Consider:

Actions: What operations are allowed or denied?
Resources: Which resources are in scope?
Conditions: Under what request context do the statements apply?
Attachments: Which users, groups, or roles receive the policy?
Other controls: What boundaries, organization policies, resource policies, session policies, or explicit denies may affect the request?

Article 8 covered policy evaluation. Keep that model in mind: finding an Allow statement is not enough to conclude that an API operation will succeed. Likewise, seeing a policy attached to a role does not prove that the role can be assumed by a particular principal.

============================================================ 7. HOW A SECURITY RESEARCHER SHOULD ENUMERATE POLICY TYPES

Start by identifying the caller and the authorized scope of the assessment. Do not enumerate or test accounts you do not own or have permission to assess.

For an authorized AWS identity, the following AWS CLI commands can help inspect policy relationships. They require suitable permissions, and calls can return AccessDenied when the caller is not authorized to view the requested information.

Identify the current caller:

aws sts get-caller-identity

List managed policies attached to an IAM role:

aws iam list-attached-role-policies — role-name ExampleRole

List inline policies attached to an IAM role:

aws iam list-role-policies — role-name ExampleRole

Retrieve an inline policy document after identifying its policy name:

aws iam get-role-policy — role-name ExampleRole — policy-name ExampleInlinePolicy

For a customer-managed policy, inspect its metadata and default version, retrieve that version's document, and identify the principals to which the policy is attached. Use the actual policy ARN and version ID returned by the authorized account; the values below are placeholders.

aws iam get-policy — policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy

aws iam get-policy-version — policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy — version-id v1

aws iam list-entities-for-policy — policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy

For the second command, use the default version ID reported by get-policy if you want to inspect the version currently in effect. The commands require suitable permissions, and the examples do not guarantee that a particular caller can retrieve the information.

These commands are examples of authorized inventory operations. They do not bypass IAM, and no output is assumed or fabricated here.

When reviewing the results, record:

The identity name and ARN.
The policy type.
The policy ARN, where applicable.
The policy version and retrieval time, where applicable.
The actions, resources, and conditions in each statement.
The identities affected by a shared managed policy.
Any permissions that appear inconsistent with the identity's purpose.
Any access-denied responses that limit the completeness of the review.

A failed enumeration command is not proof that the target has no policies. It may mean the caller lacks permission to inspect them.

============================================================ 8. WHAT TO LOOK FOR IN A POLICY REVIEW

A useful review focuses on permission scope and management risk rather than policy labels.

Broad actions

Look for wildcard actions or permissions spanning multiple services. A wildcard is not automatically a vulnerability; evaluate what operations it covers and which resources it can affect.

Broad resources

Look for Resource set to "*" or resource ARNs that cover more resources than the workload appears to need. Some AWS actions require a wildcard resource, so context matters.

Shared policy changes

For a customer managed policy, identify all attached principals before recommending a change. A fix for one role could unintentionally break another workload — or an added permission could expand access for several identities.

AWS-managed policy updates

Confirm the policy's current document and understand that AWS may update it. Avoid making claims based only on a remembered version or a policy name.

Inline policy duplication

If multiple identities have nearly identical inline policies, compare them for drift. One role may have gained a permission that others do not have, or a remediation may have been applied to only some identities.

Policy administration permissions

Review who can change policies or attach policies to identities. These capabilities can be security-sensitive, but their consequences depend on the exact permissions, restrictions, and available paths. Do not claim privilege escalation merely because a principal can manage some policy objects.

============================================================ 9. FROM OBSERVATION TO SECURITY FINDING

Use precise language when writing a report.

Finding: An application role has an attached managed policy that includes broad S3 permissions.

Potential weakness: The role may have more S3 access than the application requires.

Validation needed: Determine the actual action/resource scope, applicable restrictions, workload requirements, and whether the permissions can be exercised in the authorized test context.

Demonstrated impact: Report only the data access or change that was actually confirmed and permitted by the assessment scope.

Do not write that the account is compromised just because a role has a broad policy. Do not claim data exposure without evidence that the data was accessible. Do not call an inline policy vulnerable merely because it is inline.

A sound report should include the relevant policy document or statement, the identity receiving the permission, the affected resource scope, the prerequisites, the demonstrated behavior, the impact, and a practical remediation.

============================================================ 10. REMEDIATION AND GOVERNANCE

For AWS-managed policies:

Select policies that match the identity's job and required access.
Review the current policy document instead of relying on its name.
Monitor changes that could alter permissions for attached identities.
Consider a customer managed policy when tighter, workload-specific permissions are needed.

For customer managed policies:

Apply least privilege.
Track which identities are attached to each shared policy.
Review policy changes before deployment.
Use versioning and a rollback process.
Separate permission administration from ordinary workload operation where practical.

For inline policies:

Keep them only where identity-specific coupling is intentional.
Document why the policy is inline.
Review similar policies across identities for drift.
Include inline policies in inventory, audit, and cleanup processes.

For all policy types:

Remove permissions that are no longer needed.
Test policy changes against legitimate workload requirements.
Consider explicit denies, boundaries, organization policies, resource policies, and session constraints as part of the full authorization model.
Avoid changing production permissions without an approved change and rollback plan.

============================================================ 11. COMMON MISCONCEPTIONS

"AWS managed policies are always safe because AWS maintains them."

Incorrect. AWS maintains the policy, but it may still grant more access than a particular workload needs. Updates can also change the permissions of attached identities.

"Customer managed policies are automatically least privilege."

Incorrect. They are customer-controlled and reusable, but their content still needs careful design and review.

"Inline policies are inherently insecure."

Incorrect. They can be appropriate when permissions should be tied to one identity. Their main trade-offs concern reuse, consistency, and management.

"Two identical inline policy documents are one shared policy."

Incorrect. Each inline policy belongs to its own identity.

"A policy attached to a role proves that anyone can assume that role."

Incorrect. The role's trust policy and the caller's authorization context must also be considered.

"A policy with Action set to '*' automatically proves privilege escalation."

Incorrect. You must understand the actions, resource scope, conditions, applicable restrictions, initial access, and demonstrated impact.

============================================================ FINAL TAKEAWAY

Managed and inline policies are different ways to organize identity permissions.

AWS managed policies are maintained by AWS and are convenient for common permission sets. Customer managed policies give an organization reusable, centrally controlled permissions. Inline policies keep a policy tied to one IAM identity.

None of these policy types is automatically safe or unsafe. The right review asks what the policy permits, which identities receive it, how changes propagate, and whether the permissions match the workload's actual needs.

For security researchers, the useful questions are:

What permissions does this document grant?
Which identity receives them?
Is the policy shared or identity-specific?
Who can change it?
What other controls affect authorization?
What can be demonstrated safely, and what impact is actually supported by evidence?

That is how policy review moves from identifying JSON documents to understanding the security consequences of permission design.

============================================================ RESEARCH / TECHNICAL NOTE

This article was checked against current AWS documentation during review. Examples are illustrative. CLI commands are provided for authorized inventory and are not claimed to have been executed in an AWS account for this article.

Primary sources:

AWS IAM — Managed policies and inline policies https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html
AWS IAM — Choose between managed policies and inline policies https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html
AWS IAM — Policies and permissions in IAM https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html
AWS Well-Architected Framework — Permissions management https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html
AWS Security Blog — IAM policy types: How and when to use them https://aws.amazon.com/blogs/security/iam-policy-types-how-and-when-to-use-them/