Your applications declare their permissions in the code that enforces them. Your team grants them without an engineering ticket. Every check runs in your own database.
import { defineCatalog } from "@alfiz/core"; export const catalog = defineCatalog({ namespaces: ["docs"], permissions: { "docs.files.read": { scopes: ["docs.folder", "docs.doc"] }, "docs.files.share": { scopes: ["docs.folder", "docs.doc"] }, "docs.files.delete": { scopes: ["docs.folder"] }, }, scopeTypes: { "docs.folder": { parent: null }, "docs.doc": { parent: "docs.folder" }, },});// A grant on the folder covers every doc inside it.const ok = await alfiz.can( { userId }, "docs.files.share", "docs.doc:123",);Every key is a compile-time type, and alfiz-verify fails the build on a surface you left ungated.
A catalog that lives in a console falls behind every time the application changes. Alfiz keeps permissions in the codebase that actually uses it.
Your permission catalog lives inside the application it governs.
CI publishes the catalog to your provider as a versioned contract.
Your team builds roles from published keys and assigns them to people, groups, or a place in the org chart.
No field here for a permission your code doesn’t enforce.
can() answers there, in-processAlfiz is designed from the ground up to be as easy as possible for Agents to develop secure applications without compromising on development speed.
Agents only need to edit two lines to add a new permission: once at the catalog, once at the call site. Everything else builds on this foundation.
// ...catalog.ts "docs.files.export": { scopes: ["docs.folder"] }, // app/actions/export.tsawait alfiz.requirePermission( { userId }, "docs.files.export", scope,);One search returns the declaration and every gate that depends on it. The same property lets alfiz-verify work without a type-checker.
$ grep -rn "docs.files.share" src/ authz/catalog.ts:14 "docs.files.share": { scopes: [...] }docs/[id]/page.tsx:22 snap.can("docs.files.share", scope)actions/share.ts:9 requirePermission(p, "docs.files.share")components/nav.ts:31 { permission: "docs.files.share" }Agents respond to the immediate task at hand, often losing the bigger picture. alfiz-verify ensures that your agent never forgets to protect new routes.
A surface is not done until all four points hold:
Gated before a row is fetched.
Only items the principal matches are rendered at all.
Gated before any work. The step that gets skipped, so it errors.
Gated at the scope of the thing it acts on.
$ alfiz-verify ✖ [ungated-action] app/actions/export.ts:14 exported server action "exportDocument" contains no gate ✖ [visibility-as-gate] app/actions/share.ts:15 canAny() is a visibility affordance, never a gate ⚠ [unreferenced-leaf] "docs.files.read_history" declared, but referenced by no gate or nav itemInstall two packages, declare a catalog, wire the driver you already have, and call can().