Use Case: Cloud
Dangerous IAM policy changes
A new IAM policy version added Action: '*' and Resource: '*'. The policy is attached to a developer role used by 23 engineers. ManySignal calculated the permission delta and opened a P1 alert in 90 seconds.
The star wildcard that grants everything
IAM policy changes are the control plane events with the highest potential blast radius. A single policy change that attaches an overly-permissive policy to a frequently-used role can effectively grant administrative access to dozens of engineers, automated systems, and CI/CD pipelines simultaneously. The change takes seconds. Detecting and reverting it without impacting ongoing deployments requires both speed and context.
ManySignal doesn't just alert on the change — it calculates the effective permission delta, identifies all identities affected by the policy attachment, checks whether any of those identities have already used the new permissions, and provides a targeted remediation path that minimizes operational disruption.
rule: dangerous_iam_policy_change
type: cloud_audit + policy_analysis
sources:
- aws_cloudtrail (CreatePolicyVersion, AttachRolePolicy, PutRolePolicy)
- azure_monitor (roleAssignments, policyAssignments)
- gcp_admin_activity (setIamPolicy)
trigger:
- condition: |
policy.statement.action == "*"
OR policy.statement.resource == "*"
OR policy.statement.action.includes("iam:PassRole")
AND policy.statement.principal.aws != [specific_account_id]
enrichments:
- iam_simulator: effective_permissions_delta
- affected_identities: all_roles_using_policy
- recent_usage: api_calls_using_new_permissions
- iac_attribution: terraform_plan_diff
mitre: T1098.003 (Account Manipulation: Additional Cloud Credentials)MITRE ATT&CK mapping
IAM policy change FAQ
What IAM policy patterns trigger high-severity alerts?
Wildcard action grants (Action: '*'), wildcard resource grants (Resource: '*'), PassRole grants to broad principals, iam:CreateAccessKey attached to non-provisioning roles, and any policy that removes the Condition block from an existing policy that had one. These patterns indicate either a misconfiguration or a deliberate privilege escalation attempt.
Does ManySignal understand the effective permissions of complex policy combinations?
Yes. ManySignal uses the AWS IAM Policy Simulator API to calculate effective permissions for any identity after a policy change. This provides the actual permission delta — what the identity can now do that it couldn't before — rather than just showing the raw policy document change.
How does ManySignal handle policy changes made by Terraform or AWS CDK?
Changes made by known IaC service accounts with linked pipeline run IDs are labeled as IaC-attributed and given a lower base risk score. The effective permission delta is still calculated and surfaced — even IaC changes can introduce dangerous permissions accidentally. The key difference is the actor attribution changes the investigation workflow.
Can ManySignal alert on GCP IAM and Azure RBAC policy changes as well?
Yes. GCP IAM policy changes are monitored via GCP Admin Activity logs (setIamPolicy events). Azure RBAC assignments and policy definitions are monitored via Azure Monitor and Entra ID audit logs. All three cloud providers are normalized into the same dangerous IAM change event model.
Know the effective permission impact of every IAM policy change
Policy analysis, delta calculation, and affected identity mapping — before the change is exploited.