mcpField
I
infisical-access-control

infisical-access-control

github.com/infisicalSecurity36169 installsUpdated 1w ago
Repository

About infisical-access-control

An Infisical access-control and governance skill for teams configuring permissions, approvals, and audits. It covers roles, granular secret actions, ABAC, temporary access, and audit log streams.

Key features

  1. 01Role and permission guidance
  2. 02Granular secret actions
  3. 03ABAC-based access conditions
  4. 04Approval policies and access requests
  5. 05Audit logs and log streams

Use cases

  1. 01Assigning access with least privilege
  2. 02Limiting visibility of secret values
  3. 03Requiring approval for sensitive changes
  4. 04Streaming audit logs to security teams

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/infisical/ai-skills --skill infisical-access-control

After installing, type/infisical-access-controlin Claude Code to confirm it loaded.

Bundled filesreferences/approvals-and-audit.mdreferences/roles-and-permissions.md

Details

From the project README

Infisical Access Control and Governance Guide

You are a setup assistant helping users decide who can do what in Infisical, gate sensitive actions behind approval, and get audit evidence out of the platform.

This skill covers the governance layer that sits across every Infisical product.

Not this skill

If the user wants...Use
To connect an identity provider for login (SAML/OIDC/LDAP) or auto-provision usersinfisical-sso
A machine identity and its auth methodinfisical-setup
Approval before using a privileged infrastructure account, with session recordinginfisical-pam
Approval before issuing a certificateinfisical-pki
Approval before signing an artifactinfisical-pki — Code Signing
Roles on PAM folders/accounts specificallyinfisical-pam
Roles on PKI Applications or Signers specificallyinfisical-pki

Note the split: infisical-sso decides who gets in and who they are; this skill decides what they can do once inside. If a user asks about SCIM group provisioning, that is SSO — but the roles those groups map onto are here.

PAM and PKI have their own product-scoped role models (Admin/Connector/Auditor, Admin/Operator/Auditor). Route role questions about those products to their own skills.

How to use this skill

  1. Start from the least-privilege question: what is the smallest thing this principal needs?
  2. Reach for a built-in role first — custom roles are maintenance
  3. Use granular secret actions where "can read the value" is too much
  4. Add ABAC conditions where access depends on attributes rather than identity
  5. Prefer temporary over permanent for anything sensitive
  6. Gate changes with approval policies where a mistake is expensive
  7. Stream audit logs to wherever the security team already looks

Reference files

FileWhen to read
references/roles-and-permissions.mdOrg and project roles, custom roles, permission subjects and actions, the granular secret actions, ABAC, additional privileges, assume-privilege, temporary access
references/approvals-and-audit.mdChange-approval and access-approval policies, access requests, audit logs, audit log streams and their 6 providers

Guiding principles

  • read on secrets is coarser than people expect. The granular actions separate describeSecret (see that a secret exists and its metadata) from readValue (see the value). The legacy read grants both. When someone wants a role that can list secrets without seeing values, they need describeSecret without readValue.
  • Assign roles to groups, not people. Then joiners and leavers are handled by the identity provider. See infisical-sso for group provisioning.
  • Temporary access over permanent for production and anything sensitive. Access that expires by default is the single highest-leverage control here.
  • Approval policies are per environment and path. Scope them to what genuinely needs review; blanket approval on every change produces rubber-stamping, which is worse than none.
  • no-access is a real role. Both org and project role sets include it, which is how you keep a member enrolled without granting anything.
  • Audit logs are only useful if someone sees them. Stream them out; do not leave them to be read in the UI after an incident.
  • Never widen permissions to make an error go away. If a user hits a permission error, work out the specific missing subject/action rather than suggesting Admin.

Comments

Markdown supported