- Home
- Skills
- Velcrafting
- Codex Skills
- Authz Policy
authz-policy_skill
- Python
1
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill velcrafting/codex-skills --skill authz-policy- SKILL.md2.8 KB
Overview
This skill defines and enforces authorization policy so protected actions are explicitly allowed or denied, consistently enforced at boundaries, tested, and auditable. It focuses strictly on authorization (who may do what) rather than authentication. The goal is deterministic, centralized rules with clear error behavior and coverage by automated tests.
How this skill works
You express rules as explicit policy functions (for example can(actor, action, resource) -> bool) or the convention used in the codebase. The policy module is applied at enforcement boundaries (endpoints, job entry points, command handlers) via middleware, guards, or decorators. Tests verify allow, deny, and edge conditions, and sensitive actions include audit hooks or observability notes.
When to use it
- Protect any action that changes state or accesses sensitive data
- When multiple handlers or services must follow the same authorization decision
- Before shipping new APIs or job entry points that perform protected operations
- When tenant, ownership, or admin-override constraints are required
- When auditability or regulatory traceability is needed
Best practices
- Fail closed by default; deny unless explicitly allowed
- Centralize rules in a single policy module to avoid duplication
- Map deny errors to a shared error taxonomy and keep responses free of sensitive data
- Add tests for allow, deny, and at least one edge case (missing role, wrong tenant)
- Annotate sensitive actions with audit hooks or references to observability procedures
Example use cases
- Granting resource modifications only to owners or tenant admins with a can(actor, 'modify', resource) rule
- Blocking cross-tenant reads by enforcing tenant boundary checks in middleware
- Adding a deny-path test that verifies job handlers cannot be triggered by unauthorized actors
- Implementing an admin-override rule with explicit audit logging for escalation
- Centralizing role checks previously repeated across multiple endpoints into one policy module
FAQ
Model multi-step flows outside primitive can() checks using a state-machine mapper or explicit staged rules; keep the authorization decision explicit for each stage and record decisions for audit.
What if existing checks are inconsistent across handlers?
Consolidate into a single policy module, replace ad-hoc checks with guard middleware, add tests proving deny cannot be bypassed, and treat any tenant leakage as high severity.