Introduction

The error saying a trust policy has prohibited field Principal usually means the policy is being attached or edited in the wrong place. In AWS IAM, Principal is valid in role trust policies and some resource-based policies, but it is not valid in identity-based permission policies attached to a user, group, or role.

Know Which Policy Type You Are Editing

This error is mostly about policy type confusion. IAM has two major policy shapes that look similar but serve different purposes.

Identity-based policy:

• attached to a user, group, or role
• answers what actions this identity can perform
• does not include Principal

Trust policy:

• attached to a role
• answers who may assume this role
• does include Principal

If you paste a trust-policy document into an inline permission policy editor, AWS rejects it with the prohibited-field message.

Example of a Valid Trust Policy

A valid trust policy for an EC2 role includes the service principal and the sts:AssumeRole action.

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Principal": {
7        "Service": "ec2.amazonaws.com"
8      },
9      "Action": "sts:AssumeRole"
10    }
11  ]
12}

This belongs in the role's trust relationship, not in the role's permissions policy.

Example of a Permission Policy Without Principal

If the goal is to let the role read objects from S3 after it has already been assumed, the permission policy should look like this instead:

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": "s3:GetObject",
7      "Resource": "arn:aws:s3:::my-bucket/*"
8    }
9  ]
10}

Here there is no Principal, because the principal is already the role the policy is attached to.

Cross-Account Trust Example

For cross-account access, the trust policy names the external account or role as the principal.

1{
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Principal": {
7        "AWS": "arn:aws:iam::111122223333:root"
8      },
9      "Action": "sts:AssumeRole"
10    }
11  ]
12}

That alone is not enough. The caller also needs an identity-based policy granting sts:AssumeRole on the target role ARN.

How to Debug the Error Quickly

When you see this error, check these items in order:

• are you editing the role's trust relationship or a permission policy
• does the document contain Action: sts:AssumeRole
• is the principal type correct for the caller, such as Service, AWS, or Federated
• does the caller also have permission to assume the role

This sequence usually finds the mistake faster than staring at the JSON shape alone.

Resource-Based Policy Contrast

Resource-based policies such as S3 bucket policies are a different category again. They can contain Principal, which is why the same field may be valid in one AWS JSON document and rejected in another. The key question is always what object the policy is attached to and whether that document defines a caller or the permissions of an already-known identity.

Common Pitfalls

• Pasting a trust policy into an inline role permission policy.
• Adding Principal to identity-based policies attached to users or roles.
• Forgetting that cross-account assumption needs both trust and caller-side permission.
• Using the wrong service principal string for the AWS service involved.
• Editing the correct role but the wrong policy tab in the console.

Summary

• 'Principal belongs in trust policies and certain resource-based policies, not in identity-based permission policies.'
• The prohibited-field error usually means the policy type and the JSON content do not match.
• Trust policies answer who may assume the role.
• Permission policies answer what the role may do after assumption.
• When debugging, verify the policy location, principal type, and sts:AssumeRole path together.