infisical-access-control
Skill36 starsChanged 3 months agoMITView on GitHub
Guide for Infisical access control and governance — org and project roles, custom roles with subject/action permissions, granular secret permissions that separate describing a secret from reading its value, attribute-based access control (ABAC) driven by user metadata and machine identity attributes, additional privileges, assume-privilege, temporary (time-bound) access, access requests, change-approval and access-approval policies, and audit logs including streaming to Splunk, Datadog, Azure, Cribl, Sumo Logic, or a custom webhook. Use this skill when someone asks about: Infisical roles and permissions, custom roles, least privilege for secrets, letting someone see a secret exists without reading it, ABAC, temporary access, approval workflows for secret changes, access requests, audit logs, or streaming audit events to a SIEM. For what a principal can do once inside. Not for connecting an identity provider for login or SCIM (infisical-sso), nor for machine identity auth methods (infisical-setup).
In this repository17 other files it gives its agents.
- AGENTS.mdAGENTS.md
- infisical-agentSkill
- infisical-apiSkill
- infisical-app-connectionsSkill
- infisical-dynamic-secretsSkill
- infisical-gatewaySkill
- infisical-kmsSkill
- infisical-kubernetes-operatorSkill
- infisical-pamSkill
- infisical-pkiSkill
- infisical-secret-rotationSkill
- infisical-secret-scanningSkill
- infisical-secret-syncsSkill
- infisical-self-hostSkill
- infisical-setupSkill
- infisical-ssoSkill
- infisical-terraformSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 56
Never widen permissions to make an error go away: If a user hits a permission error, work out the specific missing subject/action rather …
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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 users | infisical-sso |
| A machine identity and its auth method | infisical-setup |
| Approval before using a privileged infrastructure account, with session recording | infisical-pam |
| Approval before issuing a certificate | infisical-pki |
| Approval before signing an artifact | infisical-pki — Code Signing |
| Roles on PAM folders/accounts specifically | infisical-pam |
| Roles on PKI Applications or Signers specifically | infisical-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
- Start from the least-privilege question: what is the smallest thing this principal needs?
- Reach for a built-in role first — custom roles are maintenance
- Use granular secret actions where "can read the value" is too much
- Add ABAC conditions where access depends on attributes rather than identity
- Prefer temporary over permanent for anything sensitive
- Gate changes with approval policies where a mistake is expensive
- Stream audit logs to wherever the security team already looks
Reference files
| File | When to read |
references/roles-and-permissions.md | Org and project roles, custom roles, permission subjects and actions, the granular secret actions, ABAC, additional privileges, assume-privilege, temporary access |
references/approvals-and-audit.md | Change-approval and access-approval policies, access requests, audit logs, audit log streams and their 6 providers |
Guiding principles
readon secrets is coarser than people expect. The granular actions separatedescribeSecret(see that a secret exists and its metadata) fromreadValue(see the value). The legacyreadgrants both. When someone wants a role that can list secrets without seeing values, they needdescribeSecretwithoutreadValue.- Assign roles to groups, not people. Then joiners and leavers are handled by the identity provider. See
infisical-ssofor 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-accessis 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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.