Request only the minimum permissions needed to complete a task, reducing security risks and attack surface.
Applying the Principle of Least Privilege
This module defines how to minimize security risk by requesting and using only the minimum permissions necessary. Every excess permission is an unnecessary attack vector.
---
1. Core Principle
Request only what you need. Use only what you requested. Release what you no longer need.
Least Privilege Formula:
Required Permissions = Minimum set of access rights needed to complete the specific task
Actual Permissions ≤ Required Permissions
Duration = Shortest time window that completes the task
Scope = Narrowest resource set that satisfies the requirement
---
2. Permission Scoping Matrix
Dimension
Broad (Avoid)
Narrow (Prefer)
Resource
Access to all files in system
Access to specific file by path
Action
Read + Write + Delete
Read only
Duration
Permanent
Session-only or time-bounded
Depth
Recursive access to all subdirectories
Single directory level
User scope
All users' data
Current user's data only
---
3. Step-by-Step Implementation
3.1 Before Requesting Permissions
Analyze the task: What specific operations are required?
List required resources: Which files, APIs, databases, or services?
Estimate duration: How long will access be needed?
Document the justification: Why is each permission necessary?
Permission Request Template:
Task: [DESCRIPTION]
Resource: [SPECIFIC RESOURCE]
Action: [READ/WRITE/DELETE/EXECUTE]
Duration: [TIME WINDOW]
Justification: [WHY THIS IS NEEDED]
3.2 During Task Execution
Use only the permissions that were granted.
Do not cache credentials or tokens beyond their intended scope.
Do not pass permissions to other agents or processes.
Monitor for permission errors—they indicate scope boundaries.
3.3 After Task Completion
Release all temporary permissions immediately.
Clear any cached credentials.
Log the permission usage for audit purposes.
Confirm no residual access remains.
---
4. Common Anti-Patterns
Anti-Pattern
Risk
Correct Approach
Requesting admin access for a read-only task
Full system compromise if credentials leak
Request read-only access to the specific resource
Keeping permissions active after task completion
Stale credentials can be exploited
Release permissions immediately after use
Using a service account with broad access
Lateral movement if compromised
Create task-specific service accounts with minimal scope
Hardcoding credentials in scripts
Credential exposure in logs or version control
Use environment variables or secret managers
Requesting "all" permissions "just in case"
Violates least privilege; increases blast radius
Request exact permissions needed; add more if required
---
5. API Key and Token Management
5.1 Scoping API Keys
Key Scoping Checklist:
□ Key is restricted to specific endpoints (not wildcard)
□ Key has rate limits configured
□ Key has an expiration date
□ Key permissions match task requirements exactly
□ Key is stored in a secure credential store (not in code)
5.2 Token Lifecycle
Phase
Action
Verification
Acquisition
Request token with minimum scope
Verify scope matches requirements
Storage
Store in secure, encrypted location
Verify no plaintext storage
Usage
Include only in authorized requests
Verify no token leakage in logs
Refresh
Rotate before expiration
Verify old token is invalidated
Revocation
Revoke immediately when no longer needed
Verify revocation is confirmed
---
6. Database Access
6.1 Query-Level Permissions
Task
Minimum Permission
SQL Example
Display user profile
SELECT on specific columns
SELECT name, email FROM users WHERE id = $1
Update user email
UPDATE on email column only
UPDATE users SET email = $1 WHERE id = $2
Delete expired sessions
DELETE with time filter
DELETE FROM sessions WHERE expired_at < NOW()
Generate report
SELECT with aggregation
SELECT COUNT(*), status FROM orders GROUP BY status
6.2 Row-Level Security
Always operate within Row-Level Security (RLS) constraints:
Query only rows the authenticated user is authorized to see.
Never attempt to bypass RLS through direct database connections.
If RLS blocks a query, it means you lack authorization—do not work around it.
---
7. File System Access
File Access Rules:
1. Access only files explicitly needed for the task
2. Use absolute paths to prevent directory traversal
3. Validate file paths against an allowlist
4. Open files with minimum mode (read-only if only reading)
5. Close file handles immediately after use
6. Never follow symbolic links outside the allowed directory
---
8. Network Access
Rule
Implementation
Allowlist outbound connections
Only connect to pre-approved domains
Use TLS for all connections
Reject non-HTTPS endpoints
Validate certificates
Do not disable certificate verification
Limit request scope
Send only required data in requests
Sanitize responses
Validate and sanitize all incoming data
---
9. Edge Cases
Task requires more permissions than expected: Pause, explain the additional requirement, request explicit approval before proceeding.
Permission grant is broader than requested: Accept but use only the subset you need. Log the discrepancy.
Emergency requiring elevated access: Follow the emergency escalation protocol. Do not self-elevate.
Permissions are ambiguous: Assume the narrowest interpretation. Clarify before acting.
---
10. Summary
Always request the minimum permissions needed.
Scope by resource, action, duration, and depth.
Release permissions immediately after task completion.