Audit, design, and migrate Identity and Access Management — cloud provider IAM (AWS, GCP, Azure), identity providers (Okta, Entra ID / Azure AD, Auth0, Google Workspace), application authorization…

MITAuto-check: notesBackend & APIs

Install Iam Audit

skills CLI
$ npx skills add briiirussell/cybersecurity-skills --skill iam-audit -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install briiirussell/cybersecurity-skills iam-audit --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/briiirussell/cybersecurity-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/iam-audit .claude/skills/iam-audit && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
iam-audit
GitHub stars
413
Token cost
~3.1k tokens
SKILL.md length
1,518 words
Files
1
Skills in repo
25
Repo updated
First seen
Licence
MIT

At a glance

Audit, design, and migrate Identity and Access Management — cloud provider IAM (AWS, GCP, Azure), identity providers (Okta, Entra ID / Azure AD, Auth0, Google Workspace), application authorization…

  • Works in 7 steps: Identity provider is the source of… → People get access via groups, not… → Service accounts are roles. Don't issue… → …
  • The user mentions IAM
  • SKILL.md covers Mode 1 — Audit existing IAM, Mode 2 — Design greenfield IAM, Mode 3 — Migrate / consolidate and Output Format, plus 2 more sections
  • Calls aws, gcloud and az

What it does

Iam Audit is an agent skill from briiirussell/cybersecurity-skills. Audit, design, and migrate Identity and Access Management — cloud provider IAM (AWS, GCP, Azure), identity providers (Okta, Entra ID / Azure AD, Auth0, Google Workspace), application authorization (RBAC, ABAC, ReBAC), and federated identity. Use when the user mentions 'IAM,' 'identity,' 'access management,' 'least privilege,' 'role design,' 'SSO,' 'SAML,' 'OIDC,' 'OAuth,' 'JIT access,' 'just-in-time access,' 'break-glass,' 'service accounts,' 'RBAC,' 'ABAC,' 'privilege creep,' 'role explosion,' 'identity…

Its SKILL.md is about 3.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Backend & APIs, covering Authorization and RBAC, OAuth and OpenID Connect and Authentication. It works with Microsoft Entra ID, Amazon Web Services, Auth0 and Okta. The repository describes itself as: Cybersecurity skills for AI coding agents (Claude Code, Cursor, Codex). The licence is MIT.

When your agent uses it

  • The user mentions IAM
  • Access management
  • Least privilege
  • Just-in-time access

Example prompts

  • “identity,”
  • “access management,”
  • “least privilege,”
  • “/iam-audit”

Requirements

  • Pre-approved tools (allowed-tools): Bash, Read, Write, Grep, Glob, WebSearch

Workflow steps

7 steps, taken from the first numbered list in SKILL.md.

  1. Identity provider is the source of truth. Even for cloud IAM — federate via SAML/OIDC, don't manage users in AWS/GCP/Azure directly.
  2. People get access via groups, not directly. Direct assignments are auditable noise.
  3. Service accounts are roles. Don't issue keys; use workload identity federation (AWS IRSA, GCP Workload Identity, Azure Workload Identity…
  4. Privileged access is JIT, not standing. Default to "no access"; grant for a defined window with audit trail (AWS IAM Identity Center +…
  5. Break-glass is a tested, alarming path. Emergency-access accounts exist but are heavily audited and tested quarterly.
  6. Least privilege is observable, not aspirational. Pull access advisor / unused-access reports monthly; remove what isn't used.
  7. Authorization decisions are logged. Every allow or deny should be traceable for incident response.

What it can do on your machine

Read from SKILL.md and the folder at commit c9ade03. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Bash
    • Read
    • Write
    • Grep
    • Glob
    • WebSearch

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • aws
    • gcloud
    • az

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use aws, gcloud and az, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Iam Audit loads about 3.1k tokens when it runs. Until then it costs about 167 tokens; SKILL.md has 1,518 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~167
When it runs · the whole SKILL.md, loaded when a task matches
~3.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Bash, Read, Write, Grep, Glob, WebSearch

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from briiirussell/cybersecurity-skills at commit c9ade03, republished under its MIT licence (© briiirussell). 1,518 words, ~3,146 tokens.

Download SKILL.mdSave it as .claude/skills/iam-audit/SKILL.md (or your agent's skills folder).
name
iam-audit
description
Audit, design, and migrate Identity and Access Management — cloud provider IAM (AWS, GCP, Azure), identity providers (Okta, Entra ID / Azure AD, Auth0, Google Workspace), application authorization (RBAC, ABAC, ReBAC), and federated identity. Use when the user mentions 'IAM,' 'identity,' 'access management,' 'least privilege,' 'role design,' 'SSO,' 'SAML,' 'OIDC,' 'OAuth,' 'JIT access,' 'just-in-time access,' 'break-glass,' 'service accounts,' 'RBAC,' 'ABAC,' 'privilege creep,' 'role explosion,' 'identity governance,' 'IAM strategy,' 'identity migration,' 'Okta,' 'Entra ID,' 'Azure AD,' 'Auth0,' 'Cognito,' or needs identity consultant-level guidance.
allowed-tools
Bash, Read, Write, Grep, Glob, WebSearch

IAM Audit — Identity & Access Management Review and Design

Cover the identity and access layer end-to-end: audit existing setup, design from scratch, plan migrations, and codify the patterns most teams get wrong. This is the consultant-style skill — not just "what's misconfigured" but "what should this look like."

Three modes — pick the one that matches the engagement:

  • Audit — review what's already deployed, find privilege creep and gaps
  • Design — greenfield IAM for a new project or new identity provider
  • Migrate — consolidate multiple identity providers, federate access, move to SSO

Cross-references: cloud-audit for the cloud-provider audit (broader than IAM), container-audit for K8s RBAC and ServiceAccounts (orchestration-layer identity).

Mode 1 — Audit existing IAM

Cloud provider IAM

AWS:

  • IAM users with console access — should be zero in mature setups (use SSO/Identity Center)
  • IAM users with permanent access keys — every one is a credential rotation problem; replace with role assumption via SSO or IAM Roles Anywhere
  • Permissions boundaries set on every role that can create roles (prevents privilege escalation via iam:CreateRole + iam:AttachRolePolicy)
  • AdministratorAccess policy attachments — flag every one and justify
  • Wildcard Action: "*" or Resource: "*" outside of break-glass roles
  • Cross-account trust policies — Principal: { AWS: "*" } is open to the world; should be specific account IDs with optional aws:PrincipalOrgID condition
  • IMDSv2 enforced — MetadataOptions.HttpTokens: required on every EC2 launch template
  • Service-linked roles audited — they bypass normal restrictions
  • Run: aws accessanalyzer list-findings, aws iam generate-credential-report, aws iam get-account-authorization-details

GCP:

  • roles/owner and roles/editor are too broad — replace with custom roles or fine-grained roles/*Admin
  • Service account keys downloaded (projects.serviceAccounts.keys.create) — should be zero; use Workload Identity Federation
  • Service accounts with iam.serviceAccountTokenCreator on themselves = self-impersonation = privilege escalation
  • Org-level vs project-level bindings — over-scoped bindings at the org level are silent privilege grants to every project
  • allUsers / allAuthenticatedUsers bindings on any sensitive resource
  • Run: gcloud asset analyze-iam-policy, gcloud policy-intelligence query-activity, Recommender API

Azure:

  • Owner and Contributor role assignments at subscription/management-group scope
  • Custom roles with * actions
  • Conditional Access policies cover every sign-in surface (legacy auth, service principals, break-glass accounts excluded with explicit reason)
  • Privileged Identity Management (PIM) used for all Global Admin / Privileged Role Admin / Application Admin roles
  • Service principal credentials (client secrets) — should expire and rotate; check expiration dates
  • Run: az role assignment list --all, Microsoft Graph auditLogs/signIns, Microsoft Entra recommendations
Identity provider

Okta / Entra ID / Auth0 / Google Workspace:

  • MFA enforced for 100% of users — no "MFA optional" cohort
  • Phishing-resistant MFA (FIDO2 / WebAuthn / hardware key) for admins; TOTP is the minimum for everyone
  • Inactive accounts disabled after 30/60/90 days (pick a policy, enforce it)
  • Lifecycle automation — joiner / mover / leaver flows are automated, not ticket-driven
  • Group-based access — users get permissions via group membership, not direct assignment; group membership is the auditable surface
  • Admin separation — privileged admin actions require a separate elevated account, not the day-to-day account
  • App assignments — every SaaS app reviewed quarterly; orphaned apps (no longer used) removed
  • Authentication policies — block legacy protocols (IMAP, POP, SMTP basic auth), enforce device compliance for high-trust apps
  • Session lifetime appropriate to sensitivity (admin: short, end user: longer with refresh)
  • Logs forwarded to SIEM — sign-ins, admin changes, MFA failures
Application authorization
  • Role definitions written down somewhere (not just in code) — docs/roles.md or equivalent
  • "Admin" is not one role — usually 3-5: support, billing, content moderator, platform admin, security responder
  • Per-tenant role isolation — a "tenant admin" of org A cannot read org B even with the same role
  • Permission checks centralized — one can(user, action, resource) function, not scattered if (user.role === "admin") checks throughout
  • ABAC where the access decision depends on resource attributes (record owner, tenant, status) — ReBAC tools (Cerbos, OpenFGA, Oso, SpiceDB) when role explosion threatens
  • Permission checks logged for the audit trail
Common audit findings
  • Role explosion — every new requirement spawned a new role; nobody knows what they all do; nobody dares delete one
  • Permission accretion — engineers got temporary permissions for an incident, permissions were never revoked
  • Shadow admin — a non-admin role can iam:AssumeRole into admin, transitively
  • Stale break-glass — emergency-access accounts haven't been tested in 12+ months; nobody knows if they work
  • MFA bypass via legacy auth — IMAP/POP/SMTP basic auth still works against accounts that "have MFA"
  • Service account sprawl — more service accounts than humans, half are unused, half are over-privileged

Mode 2 — Design greenfield IAM

Principles (the consultant ones, not just OWASP)
  1. Identity provider is the source of truth. Even for cloud IAM — federate via SAML/OIDC, don't manage users in AWS/GCP/Azure directly.
  2. People get access via groups, not directly. Direct assignments are auditable noise.
  3. Service accounts are roles. Don't issue keys; use workload identity federation (AWS IRSA, GCP Workload Identity, Azure Workload Identity, Kubernetes ServiceAccounts → OIDC).
  4. Privileged access is JIT, not standing. Default to "no access"; grant for a defined window with audit trail (AWS IAM Identity Center + permission sets with session duration, Azure PIM, Okta Workflows, Google JIT via context-aware access).
  5. Break-glass is a tested, alarming path. Emergency-access accounts exist but are heavily audited and tested quarterly.
  6. Least privilege is observable, not aspirational. Pull access advisor / unused-access reports monthly; remove what isn't used.
  7. Authorization decisions are logged. Every allow or deny should be traceable for incident response.
Show full SKILL.md (685 more words)Show less
Greenfield checklist (web app + cloud)

For a new project, design these in this order:

  1. Pick the identity provider. Okta or Entra ID for enterprise; Auth0 / Clerk / Stytch / WorkOS for B2B SaaS; Google Workspace for small teams. Don't roll your own.
  2. Define your authorization model. RBAC is the floor. Add ABAC when permissions depend on record attributes. Use a permission service (Cerbos, OpenFGA, Oso) when permissions get complex enough that an if statement in code is no longer readable.
  3. Define your roles before you write code. What roles will exist in your product? Write them in a doc with one sentence per role describing what they can do. Most products are: end user, end user admin (tenant-scoped), support, billing, content moderator, platform admin.
  4. Federate cloud access. AWS IAM Identity Center + your IdP; GCP Workload Identity Federation + your IdP; Azure AD as the source of truth for Azure roles.
  5. Workload identity, not keys. EC2 → IAM Roles; EKS → IRSA / Pod Identity; ECS → task role; Lambda → execution role; GitHub Actions → OIDC federation. No long-lived keys.
  6. Logging from day 1. Cloud trail / audit log to a SIEM-bound bucket; deny *:Delete* and *:Put* on the log bucket from anything but the logging service.
  7. Break-glass account documented and tested. Two-person rule, hardware MFA, used only for "the IdP is down" scenarios, alarms on every login.
Auth flow choices (web/mobile clients)
  • Public clients (browser, mobile) — OAuth 2.0 Authorization Code with PKCE; never implicit flow (deprecated, leaks tokens)
  • Confidential clients (server-to-server) — Client Credentials grant with short-lived access tokens
  • First-party native — your IdP's native SDK (Okta, Auth0, Clerk) handles the storage and refresh nuance
  • Long-lived refresh tokens stored in HttpOnly Secure cookies; never in localStorage (XSS-exfiltratable)
  • Token revocation list — your IdP should support it; if it doesn't, you have a JWT problem (see owasp-audit A07)

Mode 3 — Migrate / consolidate

Common migrations
  • From AWS IAM users → AWS IAM Identity Center (SSO): map users to permission sets via groups; rotate / disable IAM user access keys with a deadline; the long tail is service accounts and CI/CD — convert those to OIDC federation
  • From Active Directory → Entra ID: sync with Entra Connect, then add Conditional Access; the hard part is legacy auth (SMB, NTLM, on-prem LDAP) — those need their own deprecation plan
  • From "Google Workspace as IdP" → dedicated IdP (Okta / Entra): Google handles email but provisioning into 30 SaaS apps starts to drag; the migration is mostly SCIM provisioning + SAML federation; users barely notice
  • From roles/owner everywhere → custom roles (GCP): use Recommender API to suggest least-privilege replacements; cut over one project at a time
Migration playbook (works for all of the above)
  1. Inventory current state. Who has what access where? Spreadsheet is fine. Include service accounts.
  2. Decide the target state. Roles defined, groups defined, IdP chosen, federation pattern picked.
  3. Set up the target in parallel. New IdP / IAM Identity Center / etc. lives alongside the current setup. No cutover yet.
  4. Pilot with a small group. 5-10 people use the new path, find friction, fix it.
  5. Migrate in waves. By team or by app, not big bang. Each wave has a rollback procedure.
  6. Deprecate the old path with a deadline. Set a "by X date, the old IAM users are disabled" — and enforce it. Migrations without deadlines never finish.
  7. Audit-trail the cutover. Document who moved, when, what they had, what they got, who approved.

Output Format

markdown
# IAM [Audit | Design | Migration] Report
## Scope: [accounts / orgs / IdPs covered]
## Date: [date]

### Executive Summary
[2-3 paragraphs — the IAM posture in plain English, top 3 risks, recommended next 90 days]

### Findings / Recommendations
| ID | Severity | Mode | Category | Issue / Recommendation |
|----|----------|------|----------|------------------------|

### Per-finding detail
[as in owasp-audit — file/resource, description, vulnerable config, remediation, verification]

### Roadmap
[Quarterly milestones — what to do this month, next 90 days, next year]

Disposition rule (Fixed / Deferred / Accepted Risk) per owasp-audit.

Boundaries

  • Only audit accounts and identity providers the user has authorization for
  • Read-only operations during audit (no iam:AttachPolicy, no role creation, no user disablement)
  • For migrations: never disable a user without a confirmed rollback path
  • Refuse to help bypass MFA, recover credentials by social engineering, or design backdoor access
  • Privilege escalation chains found during audit are documented as findings, not exploited

References

  • AWS IAM Best Practices
  • GCP IAM Best Practices
  • Microsoft Entra ID — privileged access strategy
  • NIST SP 800-63 (Digital Identity Guidelines)
  • NIST SP 800-207 (Zero Trust Architecture)
  • OWASP Authentication Cheat Sheet
  • OWASP Authorization Cheat Sheet
  • Open Policy Agent / Cedar / Cerbos / OpenFGA documentation
  • AWS Permission Boundary documentation
  • "Just enough access" / JIT access patterns

© briiirussell, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/iam-audit of briiirussell/cybersecurity-skills.

Open the folder on GitHubat commit c9ade03

Compare with similar skills

Iam Audit next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Iam Audit compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Iam Audit this skillbriiirussell/cybersecurity-skills413—~3.1kAutomated safety check: NotesMIT
Managing Cloud Identity With Oktamukul975/Anthropic-Cybersecurity-Skills34k—~3.1kAutomated safety check: PassApache-2.0
Apex Entra App Registrationjonathan-vella/apex217—~1.3kAutomated safety check: PassMIT
Cometchat Securitycometchat/cometchat-skills132—~1.9kAutomated safety check: PassMIT
Entra Permissions Managementvinayaklatthe/microsoft-security-skills175—~1.7kAutomated safety check: PassMIT
Cognitoitsmostafa/aws-agent-skills1.2k1 repos~2.3kAutomated safety check: PassMIT

Similar skills

  • Managing Cloud Identity With Okta

    mukul975/Anthropic-Cybersecurity-Skills

    Implement Okta as a centralized cloud identity provider: configure SSO with AWS, Azure, and GCP, deploy phishing-resistant MFA with Okta FastPass, automate user provisioning/deprovisioning, and…

    34k GitHub stars~3.1k tokensUpdated 1 mo ago
    Backend & APIsAuto-check passed
  • Apex Entra App Registration

    jonathan-vella/apex

    WORKFLOW SKILL — Guides Microsoft Entra ID app registration, OAuth 2.0 authentication, and MSAL integration.

    217 GitHub stars~1.3k tokensUpdated yesterday
    Backend & APIsAuto-check passed
  • Cometchat Security

    cometchat/cometchat-skills

    Enterprise auth & access control for CometChat — SSO/OIDC/SAML via your own IdP, server-minted auth tokens, token revocation & session control, and role-based access (RBAC app-wide roles + group…

    132 GitHub stars~1.9k tokensUpdated 5 days ago
    Backend & APIsAuto-check passed
  • Entra Permissions Management

    vinayaklatthe/microsoft-security-skills

    Guidance for Microsoft Entra Permissions Management (CIEM) — discovers, right-sizes, and monitors permissions across Microsoft Azure, AWS, and Google Cloud.

    175 GitHub stars~1.7k tokensUpdated 3 mo ago
    Backend & APIsAuto-check passed
  • Cognito

    itsmostafa/aws-agent-skills

    AWS Cognito user authentication and authorization service. An agent skill from itsmostafa/aws-agent-skills.

    1.2k GitHub starsUsed in 1 repo~2.3k tokens
    Backend & APIsAuto-check passed
  • Frontmcp Authorities

    agentfront/frontmcp

    A skill your agent uses when implementing authorization and access control for FrontMCP tools, resources, prompts, or skills, deciding who may invoke what.

    146 GitHub stars~7.1k tokensUpdated today
    Backend & APIsAuto-check passed

More from briiirussell/cybersecurity-skills

All 25 skills in this repo
  • AI Risk Management

    briiirussell/cybersecurity-skills

    Apply the NIST AI Risk Management Framework (AI RMF 1.0) and adjacent guidance to AI / ML systems — model lifecycle governance, fairness and bias evaluation, robustness, transparency…

    413 GitHub stars~3.7k tokensUpdated 4 mo ago
    Auto-check: notes
  • API Audit

    briiirussell/cybersecurity-skills

    Audit REST, GraphQL, and RPC APIs against the OWASP API Security Top 10 (2023).

    413 GitHub stars~2.8k tokensUpdated 4 mo ago
    Auto-check: notes
  • Breach Patterns

    briiirussell/cybersecurity-skills

    Learn from public breach disclosures — extract the audit question each one implies and check your own stack.

    413 GitHub stars~3.5k tokensUpdated 4 mo ago
    Auto-check: notes
  • Cloud Audit

    briiirussell/cybersecurity-skills

    Audit cloud infrastructure (AWS, GCP, Azure) for misconfigurations, excessive permissions, and security gaps.

    413 GitHub stars~1.3k tokensUpdated 4 mo ago
    Auto-check: notes
  • Container Audit

    briiirussell/cybersecurity-skills

    Audit container images, Dockerfiles, and Kubernetes manifests for misconfigurations, excessive privileges, exposed secrets, and runtime risks.

    413 GitHub stars~2.5k tokensUpdated 4 mo ago
    Auto-check: notes
  • Crypto Audit

    briiirussell/cybersecurity-skills

    Audit cryptography implementation — algorithm choice, key sizes, KDF parameters, IV/nonce handling, signature verification, randomness, TLS configuration, and key rotation.

    413 GitHub stars~2.8k tokensUpdated 4 mo ago
    Auto-check: notes

Categories

Questions about Iam Audit

What does Iam Audit do?

Audit, design, and migrate Identity and Access Management — cloud provider IAM (AWS, GCP, Azure), identity providers (Okta, Entra ID / Azure AD, Auth0, Google Workspace), application authorization…. Iam Audit is an agent skill from briiirussell/cybersecurity-skills. Audit, design, and migrate Identity and Access Management — cloud provider IAM (AWS, GCP, Azure), identity providers (Okta, Entra ID / Azure AD, Auth0, Google Workspace), application authorization (RBAC, ABAC, ReBAC), and federated identity.

When should I use Iam Audit?

Iam Audit fits situations like: the user mentions IAM; access management; least privilege; just-in-time access.

How do I install Iam Audit in Claude Code?

Run `npx skills add briiirussell/cybersecurity-skills --skill iam-audit -a claude-code`. Or copy the skill folder (skills/iam-audit in briiirussell/cybersecurity-skills) into .claude/skills/iam-audit in your project. Claude Code loads it when a task matches its description.

How do I install Iam Audit in Codex?

Run `npx skills add briiirussell/cybersecurity-skills --skill iam-audit -a codex`. Or copy the skill folder (skills/iam-audit in briiirussell/cybersecurity-skills) into .agents/skills/iam-audit in your project. Codex loads it when a task matches its description.

Can I use Iam Audit in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add briiirussell/cybersecurity-skills --skill iam-audit -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/iam-audit, .gemini/skills/iam-audit, .github/skills/iam-audit and .opencode/skills/iam-audit in your project.

What does Iam Audit need to run?

Going by SKILL.md and its folder, Iam Audit needs the command-line tools its instructions call (aws, gcloud and az). Its frontmatter pre-approves these tools: Bash, Read, Write, Grep, Glob, WebSearch.

Does Iam Audit access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Iam Audit safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Iam Audit use?

Iam Audit is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Iam Audit use?

About 3.1k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Iam Audit?

Skills that share tags, products or a category with Iam Audit: Managing Cloud Identity With Okta (mukul975/Anthropic-Cybersecurity-Skills, 34k stars), Apex Entra App Registration (jonathan-vella/apex, 217 stars), Cometchat Security (cometchat/cometchat-skills, 132 stars) and Entra Permissions Management (vinayaklatthe/microsoft-security-skills, 175 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Iam Audit?

briiirussell (a GitHub user) maintains it in briiirussell/cybersecurity-skills, which has 413 GitHub stars. The repository holds 25 skills in this directory. The repository was last updated on May 27, 2026.

Source: briiirussell/cybersecurity-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.