The Ultimate Guide to Modern Authorization: SpiceDB, AuthZed, and AI-Powered Workflows

Whether you’re totally new to the authorization world, or you’ve already seen our previous role-based access control (RBAC) deep dive, this post will break down everything you need to know about modern, flexible AuthZ. We’ll run through real examples with SpiceDB, schema modeling tips, playground tricks, and even some slick AI/LLM integrations for making permissions easy to learn and reason about. Plus, we’ll show you how centralized authorization platforms like AuthZed are making developer lives easier (so you can focus on building, not debugging spreadsheet access).

Get comfy; you’ll want to bookmark this one. Let’s roll!

Why Stop Building AuthZ by Hand?

Most of us have been there: you land on a new feature, your PM asks for "limited editor access," and suddenly you’re elbow-deep in permissions spaghetti. Every company reinvents authorization, and every developer spends weeks untangling it again and again.

But it doesn’t have to be this way.

"AuthZ, stop building AuthZ. Start building value."

Centralizing authorization means you spend less time patching rules and more time building the actual products your users want. Solutions like SpiceDB (open source) and AuthZed (hosted, scalable) let you define permissions once and enforce them consistently across your app ecosystem. Tie your rules to business logic—not code silos. As your business changes, your model adapts.

Ready to see how this works in practice? Let’s get technical.

Modern Access Control: Playgrounds & Real SpiceDB In-Browser

Before we start coding, let’s play around. One of the easiest (and coolest) ways to wrap your head around modern permissions is the SpiceDB Playground. Hot tip: this isn't some fake emulation—it uses a real, compiled-to-WebAssembly (WASM) version of SpiceDB running right in your browser. That means you can test real access control questions, update schemas, simulate relationships, and get instant answers—all without spinning up servers.

Example workflow in the Playground:

Define your schema (entities, relationships, permissions)
Simulate user-to-resource relationships (e.g., Alice is a writer on doc1)
Test permission checks (e.g., can Alice edit doc1?)
Tweak, refine, delete, repeat

This “TDD for permissions” makes it simple to iterate and get confident before shipping to prod.

Modeling Google Docs Sharing: A Real-World Schema Example

To make this real, let’s model something you probably use daily: Google Docs sharing. The schema below captures the essence of sharing a doc with specific users, viewers, editors, and more.

# Example SpiceDB schema for Docs-style sharingdefinition user {}definition document {relation writer: userrelation reader: user# Permissionspermission edit = writerpermission view = reader + edit}

user and document are your core object types.
A document can have multiple writers and readers.
If you’re a writer: you can edit.
If you’re a reader or a writer: you can view.

This is the starting point for almost any content-sharing app.

Step by Step: What Happens When You Hit “Share”

Let’s break it down like Google Docs does:

User hits “Share” and enters an email.
This triggers a backend write:
“Make Sam a viewer or writer on this doc.”
In SpiceDB, you store a relationship like
document:firstdoc#viewer@user:sam.

Now, all you have to do on access check:

“Does Sam have view permission on this document?”

SpiceDB evaluates the schema—no more hard-coding role trees in your app!

“You don’t necessarily have to figure out why... You just ask, ‘Can they view it?’ and it handles it.”

This is why modern AuthZ unlocks real business agility.

Authorization Logic: Views, Edits, and Comments

Say we want to add comments—because what is a doc without someone making notes?

We can add a commenter relation and a comment permission:

definition document {relation writer: userrelation reader: userrelation commenter: userpermission edit = writerpermission comment = commenter + editpermission view = reader + edit + comment}

Breakdown:

Writers can comment (and edit!)
Readers can only view
You can have users who only comment (not edit)

To represent a user who can comment but not edit or read, assign just the commenter relation.

This kind of fine-grained logic is simple to express—and easy to test—compared to old-school RBAC tables.

Testing Your Permissions: The TDD Playground Approach

Modern permission systems shine when it comes to test-driven development for access control. The Playground lets you:

Enter relationship facts (e.g., “Sam is a commenter on FirstDoc”)
Run test permission checks (e.g., “Can Sam comment on FirstDoc?”)
Visualize evaluation trees—a breakdown of the logic branch-by-branch

Try this:

Add Sam as a commenter:

document:firstdoc#commenter@user:sam

Run permission check:
- comment returns yes
- view returns yes (since commenter implies view)
If you remove Sam as commenter:
- Both check fail

Pro Tip: SpiceDB’s Playground gives you a computation visualization, showing how a permission is resolved step by step. As your model gets more complex, this is a lifesaver for debugging and explaining logic.

UX and Code: Designing for Real-World Checks

In production, you might be using React, Vue, or server-rendered pages. So how do you check permissions without hitting your AuthZ backend dozens of times?

A typical pattern:

Wrap permission checks around specific UI components
If check passes, render the button (e.g., "Add Comment")

Sample React snippet:

{userHasPermission('comment', docId) &&<CommentButton documentId={docId} />}

If you want to avoid multiple round trips (latency or performance-sensitive), SpiceDB also provides bulk check APIs:

// Example (pseudocode): batch permission checksconst permissions = await spicedb.bulkCheck([{ user: 'sam', doc: 'firstdoc', perm: 'view' },{ user: 'sam', doc: 'firstdoc', perm: 'comment' },// ...]);

Typical round-trip times: single to low double-digit milliseconds (!)
You get performance without sacrificing correctness

When to Check

Top-Level Page Loads: bulk check, hydrate your UI once with all permissions
Component Mounts: on-demand checks for deeper interactivity
Keep it simple for most apps—the latency usually isn’t a bottleneck compared to your actual page and data loads

“For most people, they just check as needed, because the access check is so fast it’s not worth the complexity of heavy caching logic.”

Scaling It Up: Performance Tips and Bulk Checks

As you scale, a few key techniques help you keep things smooth:

Bulk Checks Instead of Many Singles Query multiple permissions in one shot—perfect for SPAs or admin dashboards.
Caching & Providers For heavily-trafficked apps, cache permission results for the lifetime of the page or relevant user session.

// Example: PermissionsProvider Context for Reactconst [permissions, setPermissions] = useState(null);useEffect(() => {fetchAllUserPermissions().then(setPermissions);}, [user]);// Use in UI:{permissions.canEditDoc ? <EditButton /> : null}

Materialize for Massive Scale When you need millions of user-permission checks, Materialize pre-computes permissions for extreme performance.

“You could have essentially a million user lookup at the end of one of these queries—and it still takes just milliseconds.”

For most teams, default SpicyDB is more than enough for low-latency checks, even at substantial scale.

Getting Granular: Schema Design and Practical Limits

How detailed should you make your permissions? The answer: as granular as your product and users need, but no more.

Common patterns:

Simple roles (“viewer”, “editor”)—easy for most business logic
User-defined, flexible roles—for SaaS, teams, projects
Resource-bound permissions (“can resolve issue on project X”)

You can get deeply granular—think per-row, per-field, per-action—but don’t overthink it unless your users need that power.

"We provide schema design consultations because sometimes people overcomplicate things... and then they realize, 'Oh, we actually didn't need it that granular,' and simplify back down again."

This consultation-first approach is why platforms like AuthZed offer advice, sample schemas, and best practices tailored to your domain.

Centralized Authorization: Meet AuthZed & Cloud Integration

Eventually you run into the bummer of “silos”—different teams and apps each rolling their own permissions. Want to avoid patching the same rules in microservice after microservice?

Centralized Permission Systems like AuthZed fix that by:

Defining permissions once, enforcing everywhere
Using a simple, flexible configuration language (Zanzibar-inspired)
Scaling globally (latency and throughput)
Keeping access control consistent across all environments

You get:

Central auditing
Unified logs
No more "but service B used a different rule" mistakes

If your developers are tired of rewriting authorization rules every time business logic changes, a centralized platform pays off immediately.

Key features:

Schema language lets you describe permissions flexibly
Strong consistency guarantees across your platform
Scale to millions of users/documents without a hitch

And, when new use cases emerge (AI agents, compliance, analytics), having one engine to rule them all is golden.

AI + Authorization: Vibe Coding with LLMs and MCP

Now for something wild: plugging next-gen LLMs like Claude or GPT directly into your authorization layer. What if you could build a whole server, scaffold schemas, or answer “who can do X?” questions—just by prompting an AI?

Enter MCP (Model Context Protocol)—originally designed by Anthropic (of Claude fame). It’s like a “USB for AI data”—connects external data/services (like SpiceDB) to LLMs. You can ask questions in English and get live, actionable responses, complete with logical explanations.

“I decided I’m not going to edit code by hand. I’m just going to use prompts, let the AI do everything... The outcome was pretty good, but my brain was tired in a different way.”

Here’s a snapshot of what’s possible:

Schema analysis: "Hey AI, explain how this schema works and what every permission does."
Permission checks: "Can user Alice resolve issue #123 in project PiedPiper?"
Indirection tracing: AI walks you through the logic from role assignment to permission.

Example: Prompting for Permission Analysis

Prompt:
"Analyze this schema and explain all objects, relations, and permissions."

AI Response: (paraphrased for clarity)

This schema defines:

Object types: user, document
Relations: writer, reader, commenter
Permissions: edit (writers), comment (commenters or editors), view (readers, commenters, or editors)Here's how each permission is constructed...

Example: Checking and Explaining Permissions

You ask:
“Can user Sam resolve the issue on project PiedPiper?”
The LLM/Claude MCP agent:
- Translates into a SpiceDB permission check
- Calls the API
- Returns result and explains what path it took—across all indirections (“Sam is a developer, which means...”).

And yes, you can see the JSON, the human explanation, or both—whatever fits your workflow.

Compliance, Auditing, and Non-Technical Reporting

Enterprise or security teams often ask:
Who has access to what, and why?

Traditionally, this would mean writing gnarly SQL queries, hiring consultants, or building custom dashboards. But with LLM-MCP bridges, you can literally ask natural language questions:

“Which users have access to project PiedPiper? Notify them if it’s deprecated.”
“List everyone who has view or resolve access on all issues.”

AI does the hard work, traverses roles, dedupes answers, and explains how each user got access—in plain English.

“One of our users built an MCP server for compliance—you can write reports and answer questions about who has access where, with all the role logic handled automatically.”

This lets non-technical stakeholders audit permissions, generate reports, or run regular compliance sweeps without engineering help.

Test Setup and Developer Onboarding, Powered by AI

Setting up robust tests or onboarding a new dev normally means reading through docs, manually generating role assignments, and writing test scaffolding. But imagine this:

You ask:
"Set up a scenario where user Jared has the role 'auditor' for the project PiedPiper."

The AI-powered MCP server does:

Creates the auditor role (if it doesn’t exist)
Assigns Jared to it
Verifies—and returns the API calls and logical trail

No more laborious setup code. This “describe in English, execute in API calls” bridges the gap for onboarding, TDD, and QA scenarios.

“I spent more time in old jobs setting up the right test data than writing the thing I actually wanted to test. Now, it’s just a prompt.”

Wrapping Up: Freedom and Flexibility With Less Hassle

If you remember one thing, let it be this:

“You can have the exact permissions model that supports your product, but not have to be responsible for reinventing it.”

SpiceDB and AuthZed—especially when coupled with code playgrounds, LLM integrations, and centralized patterns—let you build:

Exactly the model your business needs (simple or crazy granular)
Change it easily as your product evolves
Stay safe and compliant as you grow, with a clear audit path

And, for developers: move “permissions maintenance” off your list. You’ll have more time to build the features your users will actually thank you for.

Useful Links & Further Reading

Ready to stop untangling permission spaghetti and start building actual value? Jump into SpiceDB Playground, explore AuthZed, and try AI-powered audit tools—then let us know how it goes.

Stay tuned for more dev snacks at CodingCat.dev, and leave a comment with your wildest AuthZ war stories or requests for the next deep dive!

“You don’t have to build AuthZ over and over: eat your cake, write your app, and let the right tools handle the access control.”

Scaling Permissions with SpiceDB: ReBAC Explained

Listening Options

Sponsors

Authzed