Skill Wiki
Least Privilege
If the role doesn't need to read PII, deny it. If the service doesn't need to write to S3, deny it. If the database account doesn't need DROP, deny it.…
$ prime install @security/principle-least-privilegeProjection
Always in _index.xml · the agent never has to ask for this.
LeastPrivilege [principle] v0.1.0
Every identity — human, service, process, database account, API token — has the minimum set of permissions required for its task, and no more. Privileges are scoped narrowly, granted explicitly, time-bounded where possible, and reviewed regularly. Roles are assigned by need, not by convenience.
If the role doesn't need to read PII, deny it. If the service doesn't need to write to S3, deny it. If the database account doesn't need DROP, deny it. The default answer to 'should this principal have this permission?' is no, and the burden of proof is on yes.
Loaded when retrieval picks the atom as adjacent / supporting.
LeastPrivilege [principle] v0.1.0
Every identity — human, service, process, database account, API token — has the minimum set of permissions required for its task, and no more. Privileges are scoped narrowly, granted explicitly, time-bounded where possible, and reviewed regularly. Roles are assigned by need, not by convenience.
If the role doesn't need to read PII, deny it. If the service doesn't need to write to S3, deny it. If the database account doesn't need DROP, deny it. The default answer to 'should this principal have this permission?' is no, and the burden of proof is on yes.
Applies To
- Database accounts: the application's runtime DB user has SELECT/INSERT/UPDATE on its own schema, no DROP, no access to other schemas.
- Cloud IAM: service accounts have a tight policy bound to specific resources, no wildcards, no
Action: *. - Process privileges: containers run as non-root, with read-only root filesystem, with seccomp/apparmor profiles.
- User roles: separation of duties — admin actions require an admin account; daily work happens under a non-admin account.
- Tokens: scoped to the minimum required API surface; short-lived; revocable.
Loaded when retrieval picks the atom as a focal / direct hit.
LeastPrivilege [principle] v0.1.0
Every identity — human, service, process, database account, API token — has the minimum set of permissions required for its task, and no more. Privileges are scoped narrowly, granted explicitly, time-bounded where possible, and reviewed regularly. Roles are assigned by need, not by convenience.
If the role doesn't need to read PII, deny it. If the service doesn't need to write to S3, deny it. If the database account doesn't need DROP, deny it. The default answer to 'should this principal have this permission?' is no, and the burden of proof is on yes.
Applies To
- Database accounts: the application's runtime DB user has SELECT/INSERT/UPDATE on its own schema, no DROP, no access to other schemas.
- Cloud IAM: service accounts have a tight policy bound to specific resources, no wildcards, no
Action: *. - Process privileges: containers run as non-root, with read-only root filesystem, with seccomp/apparmor profiles.
- User roles: separation of duties — admin actions require an admin account; daily work happens under a non-admin account.
- Tokens: scoped to the minimum required API surface; short-lived; revocable.
Source
prime-system/examples/security-appsec/primes/compiled/@security/principle-least-privilege/atom.yaml