← Explore

@agent-buildprint/rbac-permissions

RBAC Permissions

A guarded Capability Buildprint for adding role-based access control with explicit roles, central permission checks, protected surfaces, and allow/deny proof.

-- views
README.md Raw

RBAC Permissions Capability Buildprint

This Capability Buildprint packages a guarded workflow for adding role-based access control to an existing host app.

It is designed for coding agents. It is not a vague authorization checklist.

What it adds

  • explicit roles
  • explicit permissions
  • deny-by-default permission matrix
  • central authorization helper
  • protected route/action wiring
  • denied and missing-role states
  • fixture/runtime verification requirements

What the host app must already have

  • authenticated user identity
  • at least one route/action/API surface worth protecting
  • a role storage, derivation, or configuration path
  • a local test or fixture path for allow/deny proof

Execution profile

guarded

RBAC touches security boundaries. The applying agent must assess the host, plan the graft, implement through phases, verify allowed and denied access, and write a receipt.

Agent flow

flowchart TD
  A[Read BUILDPRINT.md] --> B[Read capability.yaml]
  B --> C[Check compatibility.md]
  C --> D[Write .buildprint/host-assessment.md]
  D --> E[Write .buildprint/capability-plan.md]
  E --> F[Contract and policy]
  F --> G[Core permission helper]
  G --> H[Host protected wiring]
  H --> I[Denied/setup states]
  I --> J[Verify allow and deny]
  J --> K[Write .buildprint/capability-receipt.md]

Proof levels

flowchart LR
  A[structure] --> B[fixture]
  B --> C[runtime]
  C --> D[production]

Unlike provider integrations, RBAC can usually reach fixture or runtime proof without external keys.

Non-negotiables

  • No source edits before host assessment and capability plan.
  • No privileged default role.
  • No client-only protection.
  • No scattered permission literals.
  • No success claim without denied-path proof.