IAM and Least Privilege

Pathrule3 Rules • 1 Memory • 1 Skill

IAM and least privilege require an authorization model that keeps permissions narrow as infrastructure, teams, and workloads change. This bundle defines temporary identities, resource and condition scoping, privilege boundaries, review evidence, and emergency access. Unlike Secrets and Environment Management, it governs what an authenticated principal may do rather than how credential values are stored and rotated.

Suggested path map

Pathrule places each piece on the matching path, so your assistant only sees it where it belongs. This is the scoping you get on import; you can adjust it in your workspace.

/ workspace root

review-iam-access

infra/

iam/

Start policies from an explicit deny-first boundary

Permissions are reduced from observed use

.github/

workflows/

Use temporary workload credentials

terraform/

Separate permission delegation from resource ownership

Rules

Start policies from an explicit deny-first boundary/infra/iamhighstrictIAM grants enumerate required actions, resources, and conditions instead of opening a service namespace.

1	IAM grants enumerate required actions, resources, and conditions instead of opening a service namespace. Broad allow statements make future resources reachable automatically and hide which operation required the privilege. Enforce this boundary in /infra/iam so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- List the exact API actions exercised by the workload and separate read, write, and permission-management capabilities.
4	- Scope resources to stable identifiers and use documented conditions for tenant, environment, region, or source identity where supported.
5	- Keep wildcard resources only where the service API cannot scope them, and document that limitation beside the statement.
6	- Place organization or account guardrails above delegated roles so a local policy cannot grant prohibited capabilities.
7
8	Verification: Run policy validation and an access simulation for one allowed and several forbidden resources; capture any unavoidable wildcard with an owner and review date.

Use temporary workload credentials/.github/workflowshighstrictAutomation assumes a narrowly scoped role at run time and never depends on a stored cloud access key.

1	Automation assumes a narrowly scoped role at run time and never depends on a stored cloud access key. Long-lived credentials copied into CI can be exfiltrated, reused outside the job, and forgotten after the workflow changes. Enforce this boundary in /.github/workflows so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Federate the CI identity to a dedicated role and restrict its trust policy to the repository, branch, environment, and workflow that need it.
4	- Keep session duration no longer than the deployment or maintenance operation requires.
5	- Separate plan, deploy, rollback, and security-audit roles so read-only jobs cannot mutate infrastructure.
6	- Fail closed when federation claims or audience values are missing or unexpected.
7
8	Verification: Inspect issued credentials during a test run, confirm they expire, and prove a fork, unprotected branch, or unrelated workflow cannot assume the role.

Separate permission delegation from resource ownership/terraformhighstrictInfrastructure modules expose narrow role inputs and cannot grant themselves authority outside their owned resources.

1	Infrastructure modules expose narrow role inputs and cannot grant themselves authority outside their owned resources. A reusable module that creates both a resource and broad delegation can escalate every caller and makes ownership impossible to audit. Enforce this boundary in /terraform so invalid work stops before it reaches another subsystem or creates an externally visible side effect.
2
3	- Keep permission boundaries and organization guardrails in a dedicated security-owned module.
4	- Pass role identifiers into application modules instead of letting them discover or create administrator roles.
5	- Require review for trust-policy changes, permission-management actions, and cross-account principals.
6	- Detect public, cross-account, and wildcard grants in the infrastructure plan before apply.
7
8	Verification: Generate a plan containing an intentional escalation and confirm policy checks block it while ordinary resource changes remain deployable.

Memories

Permissions are reduced from observed use/infra/iamLeast privilege is a maintenance loop, not a policy written once during initial deployment.

1	Least privilege is a maintenance loop, not a policy written once during initial deployment. Applications add and remove calls, but permissions usually only grow unless usage evidence feeds a review process.
2
3	Collect action and resource usage for each role without treating lack of recent use as automatic proof that access is unnecessary. Compare observed use to intended capabilities, investigate seasonal and incident-only actions, then remove permissions through a reviewed change. Keep generated-policy tools as input to judgment because they reflect historical behavior, including accidental behavior, rather than desired authority. Keep the decision explicit at /infra/iam; moving it into an incidental caller makes behavior depend on which route happened to execute first.
4
5	See /terraform for the deployment boundary and the IAM review skill for the removal procedure. That related boundary consumes this decision and carries the evidence that proves it still holds.

Skills

review-iam-access/rootReview human and workload roles for unused, broad, cross-account, and emergency permissions.

1	---
2	name: review-iam-access
3	description: Review human and workload roles for unused, broad, cross-account, and emergency permissions.
4	---
5
6	# Review Iam Access
7
8	Run this procedure whenever the governed surface changes or its operational evidence becomes stale.
9
10	1. Inventory principals, trust policies, attached policies, permission boundaries, session duration, and the service owner for each role.
11	2. Compare granted actions and resources with deployment manifests, runbooks, and recent access evidence; flag wildcard or permission-management grants.
12	3. Test the proposed reduction with policy simulation and a non-production workflow, including one expected denial and the rollback path.
13	4. Record removed authority, retained exceptions, owner, expiry, and the next review date; verify emergency access remains usable and audited.
14
15	Record the decision, failed checks, and follow-up owner with the change. A successful run leaves reproducible evidence that another reviewer can inspect without repeating the investigation from memory.

Why this pattern

Agents reach for broad managed policies, wildcard resources, and long-lived keys to make deployments work, then leave the temporary shortcut as permanent access.

Built for Platform and application teams managing cloud identities, automation roles, and cross-account access.

Keeps your assistant from:

Wildcard actions and resources that outlive the task
Long-lived workload credentials copied into deployment settings
Emergency roles with no approval, expiry, or audit evidence

View as markdown

License: Apache-2.0
Version: 1.0.0
Updated: 2026-08-25