authz-policy_skill

This skill defines and enforces authorization rules for protected actions, ensuring explicit allows/denies, boundary enforcement, testing, and auditable
  • 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.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational