Claude Skill

access-and-identity

Designs and audits who can reach what — authentication, authorization models, privileged access, service credentials, and joiner-mover-leaver process. Use this to design a permissions model, run an access review, reduce standing privilege, handle offboarding, set up SSO or MFA, m

LLM Mart · 0 points · 17 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download cbrock84-headcount-plugins_security_skills_access-and-identity-98d1c17.zip · 3 KB
Part of cbrock84/headcount — 160 skills

Install

skills CLI npx skills add https://github.com/cbrock84/headcount/tree/main/plugins/security/skills/access-and-identity
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install cbrock84-headcount@llmmart
Git git clone https://github.com/cbrock84/headcount.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole cbrock84/headcount collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Access and identity

Access accumulates. People change roles and keep the old permissions, services get broad credentials because narrow ones were inconvenient, and contractors' accounts outlive their contracts. Left alone, entitlement always grows and never shrinks.

Principles that actually hold

  • Least privilege, and it must be practical. A model so restrictive that people share accounts to get work done is worse than a looser one they follow.
  • Role-based, not person-based. Grants attached to individuals are ungovernable at any scale.
  • Time-bound elevation over standing privilege. Nobody should hold administrative access continuously because they occasionally need it. Elevation on request, with a reason, expiring automatically.
  • Separate duties where the consequence is severe. The person who requests a payment does not approve it; the person who writes the deploy does not solely authorize the production change.

Authentication

Single sign-on wherever possible — the value is not convenience, it is that offboarding becomes one action rather than forty. Every system outside SSO is a system someone will still have access to after they leave.

Multi-factor everywhere it is available, and phishing-resistant factors for administrative access. SMS is better than nothing and is the weakest option worth deploying.

Joiner, mover, leaver

Mover is the one everyone gets wrong. Joining and leaving are events with a process; changing role usually adds permissions and removes none, which is how a long-tenured employee ends up with access to everything.

Make role change a revoke-and-regrant rather than an addition. It is the single highest-value change most organizations can make to their access posture.

Offboarding needs to be same-day, cover everything including systems outside SSO, and be verified rather than assumed. Keep a list of what exists to be revoked — the fastest way to find the shadow systems is to try to offboard someone thoroughly.

Service and machine credentials

Usually more numerous and less governed than human ones. Each needs a named human owner, a scope limited to its actual use, a rotation path, and an expiry.

Prefer short-lived, automatically issued credentials over long-lived keys. A key that never expires will eventually appear in a repository, a log, or a support ticket.

Access reviews

Periodic, by system, with the reviewer being the person accountable for the data rather than IT. Reviewers who cannot say why someone needs access should remove it — the burden belongs on retention, not removal.

Review dormant accounts as a separate pass. An account nobody has used in six months is either unnecessary or belongs to someone who left.

Diagnosing sprawl

Look for: permissions granted to individuals rather than roles, roles nobody can define, standing administrative access, accounts whose owner has left, service credentials with no owner, and systems outside SSO. Each is a specific fix, and the list is nearly always the same list.

Sources

references/sources.md in this skill lists the outside authorities that settle the questions here — what each one is authoritative for, and what you may do with it. Check them before answering on anything they cover, and cite what you used. Most are free to read and not free to reproduce; the use note on each is binding.

Tooling

Identity providers: Okta, Microsoft Entra ID, Google Workspace, JumpCloud, and similar.

Privileged access and secrets: CyberArk, HashiCorp Vault, 1Password, Doppler, and similar.

Access reviews and provisioning: Okta Identity Governance, Entra ID Governance, Lumos, ConductorOne, and similar. Worth buying at the point a manual quarterly review stops finishing rather than the point it gets tedious.

Never

  • Grant standing access where time-bound access would do the same job.
  • Leave an account active while an offboarding ticket works its way through. Cut access first, reconcile after.
  • Share a credential between people. If two people can use it, no log tells you which one did.
  • Approve your own access request, or review a group you belong to.
Files (headcount)
  • references
    • sources.md 1.3 KB
      # Sources — `security:access-and-identity`
      
      <!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
      
      Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
      
      ## NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems
      
      NIST · US · public domain (US government) — quote freely
      
      <https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final>
      
      Machine-readable: <https://github.com/usnistgov/oscal-content>
      
      **Authoritative for:** The control catalog US federal systems are assessed against, and the control vocabulary FedRAMP and many private frameworks inherit.
      
      ## NIST SP 800-63: Digital Identity Guidelines
      
      NIST · US · public domain (US government) — quote freely
      
      <https://csrc.nist.gov/pubs/sp/800/63/4/final>
      
      Machine-readable: <https://pages.nist.gov/800-63-4/>
      
      **Authoritative for:** What each identity, authenticator and federation assurance level requires — and, notably, that forced periodic password rotation and composition rules are not among them.
      
      ---
      
      Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.
      
  • SKILL.md 4.5 KB
    ---
    name: access-and-identity
    description: Designs and audits who can reach what — authentication, authorization models, privileged access, service credentials, and joiner-mover-leaver process. Use this to design a permissions model, run an access review, reduce standing privilege, handle offboarding, set up SSO or MFA, manage service and machine credentials, or diagnose why permissions have sprawled.
    ---
    
    # Access and identity
    
    Access accumulates. People change roles and keep the old permissions, services get broad credentials
    because narrow ones were inconvenient, and contractors' accounts outlive their contracts. Left alone,
    entitlement always grows and never shrinks.
    
    ## Principles that actually hold
    
    - **Least privilege, and it must be practical.** A model so restrictive that people share accounts
      to get work done is worse than a looser one they follow.
    - **Role-based, not person-based.** Grants attached to individuals are ungovernable at any scale.
    - **Time-bound elevation over standing privilege.** Nobody should hold administrative access
      continuously because they occasionally need it. Elevation on request, with a reason, expiring
      automatically.
    - **Separate duties where the consequence is severe.** The person who requests a payment does not
      approve it; the person who writes the deploy does not solely authorize the production change.
    
    ## Authentication
    
    Single sign-on wherever possible — the value is not convenience, it is that offboarding becomes one
    action rather than forty. Every system outside SSO is a system someone will still have access to
    after they leave.
    
    Multi-factor everywhere it is available, and phishing-resistant factors for administrative access.
    SMS is better than nothing and is the weakest option worth deploying.
    
    ## Joiner, mover, leaver
    
    **Mover is the one everyone gets wrong.** Joining and leaving are events with a process; changing
    role usually adds permissions and removes none, which is how a long-tenured employee ends up with
    access to everything.
    
    Make role change a revoke-and-regrant rather than an addition. It is the single highest-value change
    most organizations can make to their access posture.
    
    Offboarding needs to be same-day, cover everything including systems outside SSO, and be verified
    rather than assumed. Keep a list of what exists to be revoked — the fastest way to find the shadow
    systems is to try to offboard someone thoroughly.
    
    ## Service and machine credentials
    
    Usually more numerous and less governed than human ones. Each needs a named human owner, a scope
    limited to its actual use, a rotation path, and an expiry.
    
    Prefer short-lived, automatically issued credentials over long-lived keys. A key that never expires
    will eventually appear in a repository, a log, or a support ticket.
    
    ## Access reviews
    
    Periodic, by system, with the reviewer being the person accountable for the data rather than IT.
    Reviewers who cannot say why someone needs access should remove it — the burden belongs on
    retention, not removal.
    
    Review dormant accounts as a separate pass. An account nobody has used in six months is either
    unnecessary or belongs to someone who left.
    
    ## Diagnosing sprawl
    
    Look for: permissions granted to individuals rather than roles, roles nobody can define, standing
    administrative access, accounts whose owner has left, service credentials with no owner, and systems
    outside SSO. Each is a specific fix, and the list is nearly always the same list.
    
    ## Sources
    
    `references/sources.md` in this skill lists the outside authorities that settle the questions
    here — what each one is authoritative for, and what you may do with it. Check them before
    answering on anything they cover, and cite what you used. Most are free to read and not free
    to reproduce; the use note on each is binding.
    
    ## Tooling
    
    Identity providers: Okta, Microsoft Entra ID, Google Workspace, JumpCloud, and similar.
    
    Privileged access and secrets: CyberArk, HashiCorp Vault, 1Password, Doppler, and similar.
    
    Access reviews and provisioning: Okta Identity Governance, Entra ID Governance, Lumos,
    ConductorOne, and similar. Worth buying at the point a manual quarterly review stops
    finishing rather than the point it gets tedious.
    
    ## Never
    
    - Grant standing access where time-bound access would do the same job.
    - Leave an account active while an offboarding ticket works its way through. Cut access first, reconcile after.
    - Share a credential between people. If two people can use it, no log tells you which one did.
    - Approve your own access request, or review a group you belong to.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related