imtiazrayhan Audit permission scope without changing access. Produce evidence and a staged reduction plan; do not revoke credentials or edit policy unless the user explicitly expands the task.
Workflow
- Inventory principals and credentials. Find application service accounts, cloud roles, database users, CI tokens, deploy identities, human groups, third-party apps, agents, MCP servers, and long-lived keys. Record owner, environment, authentication method, and expiry.
- Map granted capability. Expand inherited roles, groups, wildcards, resource patterns, trust policies, and delegation. Include actions, resources, conditions, environments, and whether the identity may grant access onward.
- Map required behavior. Trace code, workflows, infrastructure, queries, tool declarations, and documented operations. Use audit logs when supplied, but treat absence of observed use as evidence to investigate—not proof that a disaster-recovery permission is unnecessary.
- Classify each grant. Mark
required,unused,excess scope,temporary, orunverified. Explain the exact resource and action difference between current and required access. - Prioritize blast radius. Raise wildcard write/admin access, cross-tenant or cross-environment scope, secret and identity management, policy mutation, production data export, and unbounded agent tools above harmless read-only excess.
- Design the target role. Prefer task-specific actions, named resources, environment separation, short-lived credentials, explicit conditions, and separate break-glass access with logging and expiry.
- Plan a safe rollout. Create the reduced role alongside the old one, test known workflows, canary it, monitor denials, and define rollback. Remove the old role only after the observation window.
- Identify governance gaps. Flag ownerless identities, unused long-lived keys, roles with no review date, shared credentials, missing audit logs, and exceptions without expiry.
[!WARNING] Do not remove a permission solely because it was absent from a short log window. Rare maintenance, recovery, and failover paths need explicit owners and tests before removal.
Output
Return:
- a principal-to-permission inventory with owners and environments
- findings ordered by blast radius, each showing current versus required scope
- a proposed least-privilege role or policy diff
- a staged test, canary, monitoring, and rollback plan
- time-bounded exceptions for rare required access
- governance gaps and the next review date