PutRolePermissionsBoundary
PutRolePermissionsBoundary
Event
Sets a managed policy as the permissions boundary for the specified IAM role, replacing any existing boundary association. This is distinct from attaching that policy as a permissions policy.
Security Context
An unauthorized boundary change can enable privilege escalation when it removes restrictions on permissions granted elsewhere. Boundaries do not grant permissions themselves; other applicable controls and explicit denies still matter. Approved boundary maintenance is also normal. The T1548 mapping is contextual to abuse of this elevation control, not proof from the API name alone.
Evaluate resource-based grants separately: within the same account, direct grants to an IAM user ARN or role-session ARN can escape a boundary’s implicit deny. Explicit denies still apply. Do not treat the boundary as an absolute limit on every grant path.
Log Source
AWS CloudTrail management event with eventSource: iam.amazonaws.com and eventName: PutRolePermissionsBoundary. Include IAM global-service events in your collection. Check errorCode and errorMessage; a recorded attempt is not necessarily a completed change, and responseElements: null alone does not establish failure.
Key Fields
| Field | Investigation value |
|---|---|
userIdentity | Caller and session context; compare with the target and approved automation. |
requestParameters.roleName | Target IAM role, interpreted with the account identity. |
requestParameters.permissionsBoundary | New managed-policy ARN; inspect its effective policy version, not just its name. |
eventTime, recipientAccountId, requestID, eventID | Timeline, account, and correlation identifiers. |
sourceIPAddress, userAgent | Supporting context, not proof of identity or malicious intent. |
errorCode, errorMessage | Failed requests must be distinguished from successful changes. |
What to Investigate
- Confirm the outcome and match the caller, target, and timing to an approved change. Review failed attempts separately.
- Recover the previous boundary and its policy document at the event time. Compare it with the replacement policy’s effective version; a different ARN does not establish whether access expanded or contracted.
- Compare effective access before and after the change using the target’s grants, applicable SCPs, session policies, resource policies, and denies. Identify concrete newly allowed actions rather than assuming administrator access.
- Correlate the companion boundary operation and subsequent target activity. Inspect the role trust policy and actual role sessions. This operation does not change who can assume the role or issue credentials.
Sample Event
Synthetic administrative scenario. Hermione applies BoundaryForServiceRoles to OccamyPipelineRole. The name alone does not prove this tightens access or is approved; compare the prior boundary, policy documents, and change record.
This is an illustrative CloudTrail-shaped record. Exact field presence and policy-document serialization have not been verified against a captured event.
{ "eventVersion": "1.09", "userIdentity": { "type": "IAMUser", "principalId": "AIDAHERM10NE000ADM1N", "arn": "arn:aws:iam::555123456789:user/hermione", "accountId": "555123456789", "accessKeyId": "ASIAHERM10NEEXAMPLE1", "userName": "hermione", "sessionContext": { "attributes": { "creationDate": "2026-04-15T13:02:11Z", "mfaAuthenticated": "true" } } }, "eventTime": "2026-04-15T13:24:46Z", "eventSource": "iam.amazonaws.com", "eventName": "PutRolePermissionsBoundary", "awsRegion": "us-east-1", "sourceIPAddress": "198.51.100.42", "userAgent": "aws-cli/2.15.30 Python/3.11.6 Linux/5.15.0-1052-aws exe/x86_64.ubuntu.22 prompt/off command/iam.put-role-permissions-boundary", "requestParameters": { "roleName": "OccamyPipelineRole", "permissionsBoundary": "arn:aws:iam::555123456789:policy/BoundaryForServiceRoles" }, "responseElements": null, "requestID": "90000000-0000-4000-8000-000110010000", "eventID": "90000000-0000-4000-8000-000110010001", "readOnly": false, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "555123456789", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "iam.amazonaws.com" }}Sources
MITRE ATT&CK Mapping
Tactics: Privilege Escalation
- T1548 — Abuse Elevation Control Mechanism — Adversaries may circumvent mechanisms designed to control privilege elevation to gain higher-level permissions. Most modern systems contain native elevation control mechanisms that are intended to limit privileges that a user can perform on a machine. Authorization has to be granted to specific u...