@workos/mcp-docs-server 0.1.0

package/.docs/organized/docs/events/observability/datadog.mdx

@@ -0,0 +1,76 @@
+---
+title: Stream events to Datadog
+description: Stream and analyze WorkOS activity in Datadog.
+originalPath: .tmp-workos-clone/packages/docs/content/events/observability/datadog.mdx
+---
+
+![WorkOS Datadog dashboard showing various metrics and graphs describing authentication events and user activity](https://images.workoscdn.com/images/9ec8c9ce-e087-4967-8b66-9311aaf13902.png?auto=format&fit=clip&q=50)
+
+WorkOS supports real-time streaming of events to Datadog. By analyzing WorkOS activity directly in Datadog, you are able to:
+
+- View trends in user sign-ins, user growth, new SSO connections and more.
+- Debug customer issues related to sign-in, email verification, password resets and more.
+- Generate reports of user activity per customer organization.
+- Set alerts for unexpected activity, such as sudden spike in failed password attempts.
+
+See all of the WorkOS events that stream to Datadog in the [event types](/events) documentation.
+
+---
+
+## Introduction
+
+Setting up real-time streaming of WorkOS events to Datadog only takes a few minutes and can be done in three simple steps.
+
+---
+
+## (1) Create a Datadog API key
+
+First, create a new Datadog API key to give WorkOS permission to send event activity as logs to your Datadog account. While you can use an existing API key, WorkOS recommends creating a new key that will only be used for WorkOS event streaming.
+
+1. Sign in to your [Datadog account](https://app.datadoghq.com/).
+2. Navigate to the [Organization Settings → API Keys](https://app.datadoghq.com/organization-settings/api-keys) page.
+3. Choose the **New Key** button
+4. Enter a name for your new API key.
+5. Choose the **Create Key** button.
+   ![A screenshot showing how to create an API key in the Datadog dashboard.](https://images.workoscdn.com/images/d69f49e9-6e8b-444a-8736-0cc2db98cf72.png?auto=format&fit=clip&q=50)
+
+---
+
+## (2) Configure event streaming in WorkOS
+
+The next step is to configure event streaming in the [WorkOS Dashboard](https://dashboard.workos.com/) using the Datadog API key that was created in the previous step.
+
+1. Sign in to the [WorkOS Dashboard](https://dashboard.workos.com/).
+2. Navigate to the **Events** page.
+3. Choose the **Stream to Datadog** button.
+
+![A screenshot showing how setup streaming events to Datadog in the WorkOS Dashboard.](https://images.workoscdn.com/images/0259f8e3-6fb2-4b3a-819a-f98d128c1c79.png?auto=format&fit=clip&q=50)
+
+4. Enter the Datadog API key.
+5. Select your Datadog region.
+6. Choose the **Save Log Stream Details** button.
+
+![A screenshot showing how to enter a Datadog API key in WorkOS Dashboard.](https://images.workoscdn.com/images/e1d4d7bb-e076-492f-971f-e116ffe2de0e.png?auto=format&fit=clip&q=50)
+
+With event streaming configured, when new events occur, WorkOS will send the events to Datadog with the source `workos`.
+
+---
+
+## (3) Add the WorkOS Datadog dashboard
+
+The final step is to add the WorkOS Datadog dashboard to your Datadog account.
+
+1. Sign in to your [Datadog account](https://app.datadoghq.com/).
+2. Navigate to the [Dashboard List](https://app.datadoghq.com/dashboard/lists) page.
+3. Choose the **+ New Dashboard** button.
+
+![A screenshot showing how to create a new dashboard in Datadog.](https://images.workoscdn.com/images/feee6689-2477-4711-bf0e-10c917cc02f7.png?auto=format&fit=clip&q=50)
+
+4. Enter a dashboard name.
+5. Choose the **New Dashboard** button.
+6. In the new dashboard, choose the **Configure** button.
+7. Download the [WorkOS Datadog dashboard JSON file](/docs/assets/workos-datadog-dashboard.json)
+8. Scroll down in the context menu and choose **Import dashboard JSON**.
+9. Upload the WorkOS Datadog dashboard JSON file downloaded in the previous step.
+
+![A screenshot showing how to import a JSON definition of a Dashboard into Datadog.](https://images.workoscdn.com/images/3dc7f949-67ff-470e-84f1-8a5a8880114d.png?auto=format&fit=clip&q=50)

package/.docs/organized/docs/fga/_navigation.mdx

@@ -0,0 +1,64 @@
+---
+title: Fine-Grained Authorization
+links:
+  - title: Getting Started
+    links:
+      - title: Overview
+        url: /fga
+      - title: Quick Start
+        url: /fga/quick-start
+      - title: Playground
+        url: /fga/playground
+  - title: Key Concepts
+    links:
+      - title: Schema
+        url: /fga/schema
+      - title: Warrants
+        url: /fga/warrants
+      - title: Resources
+        url: /fga/resources
+      - title: Policies
+        url: /fga/policies
+      - title: Query Language
+        url: /fga/query-language
+      - title: Warrant Tokens
+        url: /fga/warrant-tokens
+      - title: Operations & Usage
+        url: /fga/operations-usage
+  - title: Management
+    links:
+      - title: Schema Management
+        url: /fga/schema-management
+      - title: Local Development
+        url: /fga/local-development
+      - title: Identity Provider Sessions
+        url: /fga/identity-provider-sessions
+  - title: Modeling
+    links:
+      - title: Org Roles & Permissions
+        url: /fga/modeling/org-roles-and-permissions
+      - title: Custom Roles
+        url: /fga/modeling/custom-roles
+      - title: Google Docs
+        url: /fga/modeling/shareable-content
+      - title: Entitlements
+        url: /fga/modeling/entitlements
+      - title: User Groups
+        url: /fga/modeling/user-groups
+      - title: Managed Service Provider
+        url: /fga/modeling/managed-service-provider
+      - title: Attribute-Based Access Control
+        url: /fga/modeling/abac
+      - title: Conditional Roles
+        url: /fga/modeling/conditional-roles
+      - title: Policy Context
+        url: /fga/modeling/policy-context
+      - title: Public Access
+        url: /fga/modeling/public-access
+      - title: Superusers
+        url: /fga/modeling/superusers
+      - title: Blocklists
+        url: /fga/modeling/blocklist
+originalPath: .tmp-workos-clone/packages/docs/content/fga/_navigation.mdx
+---
+

package/.docs/organized/docs/fga/identity-provider-sessions.mdx

@@ -0,0 +1,68 @@
+---
+title: Identity Provider Sessions
+description: Learn how to configure FGA to use your identity provider's ID tokens.
+originalPath: .tmp-workos-clone/packages/docs/content/fga/identity-provider-sessions.mdx
+---
+
+## Overview
+
+Fine-Grained Authorization (FGA) is commonly used to enforce detailed authorization on your application's backend. However, it can also be utilized on the frontend to perform access checks directly within your client application. FGA supports the use of ID tokens issued by identity providers, allowing you to make user-specific authorization decisions on the frontend. This not only improves the security of your application but also enables you to present a customized user interface and experience based on the access levels of different users.
+
+## Before getting started
+
+To get the most out of this guide, you’ll need:
+
+- A [WorkOS account](https://dashboard.workos.com/)
+- Your WorkOS [Client ID](/glossary/client-id)
+- The JSON Web Key Set (JWKS) endpoint of your identity provider. ([AuthKit](/reference/user-management/session-tokens/jwks))
+- A schema set up in a FGA environment. If you haven't done so, check out our [Quick Start](/fga/quick-start) to create one.
+
+---
+
+## (1) Configure your JWKS URL
+
+A JWKS URL is an endpoint that contains the set of public keys used to verify any JSON Web Tokens (JWTs) issued by your provider. Currently, FGA only supports JWTs that are signed using the **RS256** signing algorithm.
+
+Common identity provider JWKS URLs:
+
+- **WorkOS User Management**: `https://api.workos.com/sso/jwks/{clientId}`
+- **Auth0**: `https://{yourDomain}/.well-known/jwks.json`
+- **Google/Firebase**: `https://www.googleapis.com/oauth2/v3/certs`
+
+You can set your JWKS URL in the _Configuration_ section of the [FGA Dashboard](https://fga.workos.com/configuration).
+
+![FGA JWKS Configuration](https://images.workoscdn.com/images/35f59a84-d1ad-4c78-8be4-210678a6c161.png?auto=format&fit=clip&q=50)
+
+## (2) Create a context for FGA
+
+Next, let's create a [context](https://react.dev/learn/passing-data-deeply-with-context) for FGA that will allow us to make checks from anywhere in our application.
+
+The FGA context will set and track the user's session token and expose a `check` method that we can access anywhere in our application where we need to make an access check before displaying a UI element or performing an action.
+
+<CodeBlock title="Create FGA context" file="jwks-create-fga-context" />
+<CodeBlock
+  title="Wrap your application with the created provider"
+  file="jwks-wrap-with-provider"
+/>
+
+## (3) Set the session token when a user logs in
+
+Before we begin making access checks in our application, we need to provide a server-generated session token and set it in our FGA context.
+
+<CodeBlock title="Set session token on login" file="jwks-set-session-token" />
+
+## (4) Make check requests from your app
+
+Now that we've created our FGA context and set the session token, we can start making check requests from our client application.
+
+The main difference here from regular check requests is that we don't need to provide a subject in our checks because all checks will be scoped to the user specified by the user ID in the session token.
+
+Let's make a check to see if the user has the `viewer` relation on `report:7` before displaying the report's data.
+
+<CodeBlock title="Make check request" file="jwks-component-check" />
+
+---
+
+## Summary
+
+In this guide, we demonstrated how to perform authorization checks directly in a client application using ID tokens from our identity provider. We created a context to manage the user's session token upon login, which is then used for subsequent access checks. This approach allows us to deliver a secure and personalized experience to users within our application, leveraging FGA for fine-grained access control.

package/.docs/organized/docs/fga/index.mdx

@@ -0,0 +1,60 @@
+---
+title: Fine-Grained Authorization (FGA)
+description: 'Scalable, centralized, fine grained authorization for your application.'
+showNextPage: true
+originalPath: .tmp-workos-clone/packages/docs/content/fga/index.mdx
+---
+
+## Introduction
+
+WorkOS Fine-Grained Authorization (FGA) is a centralized authorization service for customer applications. Teams can use FGA to implement a custom authorization model tailor-made for their application(s), with the ability to integrate elements of role-based access control (RBAC), relationship-based access control (ReBAC), and attribute-based access control (ABAC) as needed.
+
+## Key features
+
+- Fully managed, centralized authorization service (inspired by Google Zanzibar) for managing and enforcing application authorization
+- [Check API](/reference/fga/check) to perform fast access checks from your application (i.e. `Is user:A an editor of document:X?`)
+- [Query API](/reference/fga/query) to quickly lookup which resources users have access to from your application (i.e. `Which documents can user:A edit?`)
+- Central log of all authorization events & operations to make auditing and debugging of your application(s) easy
+- Pre-built templates for common access control patterns like RBAC, multi-tenancy, pricing tiers & feature entitlements, and more
+
+## Common Use Cases
+
+### Role-based access control (RBAC)
+
+One of the most common forms of access control, role-based access control involves 3 main entities: roles, permissions and users. Permissions define _behaviors_ that are grouped together into roles (e.g. admin, owner). Roles are then assigned to users to grant them the ability to perform a group of behaviors. RBAC is common within B2B software and SaaS applications used by enterprises, often being necessary to meet regulatory, compliance, and/or enterprise contract requirements.
+
+### Custom roles
+
+Most applications start by implementing RBAC with a static set of roles. This works well for simple applications used by one customer (single-tenant). However, this model often breaks down in multi-tenant applications (apps used by multiple customers). Different customers might require a different set of roles or a different mapping of roles to permissions. This requirement introduces a new dimension (tenant) on top of existing roles, permissions, and users, requiring a flexible access model to prevent a problem known as _role explosion_.
+
+### Fine-grained access control (FGAC)
+
+Fine-grained access control is a more granular form of access control that is becoming popular in applications today. As opposed to the coarse-grained access control provided by RBAC, which grants access to behaviors across _all resources_, FGAC allows applications to grant users certain behaviors _per resource_.
+
+For example, while a RBAC rule might specify that `[admins] can [edit] [reports]`, a fine grained rule can specify that `[user:1] can [edit] [report:xsd34]`.
+
+### Resource-level RBAC
+
+FGAC can also be used in conjunction with RBAC to enable what we call 'fine-grained RBAC'. This is especially common in SaaS apps and developer tools. For example, let's take a cloud infrastructure multi-tenant SaaS that defines a resource called `customer-application`. A 'customer-application' can have `owners`, `editors` and `viewers`. Now let's say that the users within this SaaS can have multiple 'roles' within their 'tenant' based on their access level. In order to specify an access rule like `all [admins] of [tenant:x] can [edit] [all applications] that belong to [tenant:x]`, we need 'fine-grained RBAC', or the ability to specify resource-level rules by role.
+
+### Collaboration & document sharing
+
+One of the most common use cases for FGAC is to enable access control on user-generated content, similar to Google Docs or Box. With FGAC, you can easily define `owners`, `editors` and `viewers` of your own resources and objects (ex. documents, reports).
+
+### Organization hierarchies
+
+Another common use case for FGAC is to model complex organization hierarchies, often those found within most mid-large scale enterprises. For example, let's say that we'd like to specify a rule within an organization which states that `all [members] of [team:x] can access [report:y87dXfd]`. Furthermore, let's say that membership in `team:x` is driven by org hierarchy and whether a specific person reports to a given manager.
+
+Using a FGA system, we can model the exact org hierarchy as well as easily define rules such as `all [direct reports] of [manager:y] are [members] of [team:x]` and `all [members] of [team:x] can access [report:y87dXfd]` in order to process queries such as `can [user:1] access [report:y87dXfd]` in realtime.
+
+### Regional access control
+
+Similar to enterprise org hierarchies, apps with complex regional hierarchies are a good use case for FGAC. For example, let's say we're building a supply-chain or operations-focused SaaS app where data and functionality is separated by region. We may have `region:east` and `region:west` to distinguish the two core regions with teams and users defined within each region.
+
+Using a FGA system, we can accurately model the regions and easily make queries against it at runtime to ensure that the right users have access to the right data and functionality.
+
+### Pricing tiers & feature entitlements
+
+Although not directly related to security, a common form of access control often used within SaaS is what we call 'pricing tiers & feature entitlements'. Pricing tiers are groups of features within an app, typically assigned based on the end customer's payment tier. Mature SaaS apps often build out their own management and enforcement layer for pricing tiers, in order to support everything from feature overrides and metering to integrations with payment systems.
+
+With a FGAC system, pricing tiers and feature entitlements can be expressed as rules like `[company:x] is on [tier:enterprise]` and `[feature:dashboard] is part of [tier:enterprise]` in order to easily support runtime queries like `can [user:y] which is a member of [company:x] access [feature:dashboard]?`

package/.docs/organized/docs/fga/local-development.mdx

@@ -0,0 +1,155 @@
+---
+title: Local Development
+description: >-
+  Learn how to setup your local development environment with FGA using the FGA
+  Dev Docker image for isolated testing and schema development.
+originalPath: .tmp-workos-clone/packages/docs/content/fga/local-development.mdx
+---
+
+## Overview
+
+When developing with FGA, you can either connect to a managed WorkOS FGA instance or run a local FGA instance using the [`fga-dev` Docker image](https://gallery.ecr.aws/workos/fga-dev). Each option has its own advantages depending on your workflow. This guide will help you choose the best approach and walk you through setting up a local instance if that fits your needs.
+
+### Managed FGA Instance
+
+Best for testing against production-like infrastructure and when you need persistent, shared data.
+
+| Pros                                                           | Cons                                                                |
+| -------------------------------------------------------------- | ------------------------------------------------------------------- |
+| Data persists and is accessible by multiple clients            | Data is shared (multiple consumers can overwrite each other's data) |
+| Uses production infrastructure for performance and reliability | Consumes operation credits                                          |
+
+### Local FGA Instance
+
+Best for isolated development and testing especially when you want to avoid using operation credits or need a clean environment for each run (such as in CI).
+
+| Pros                           | Cons                                       |
+| ------------------------------ | ------------------------------------------ |
+| Isolated test environment      | You must manage setup and teardown of data |
+| Does not use operation credits | Uses local resources and is not scalable   |
+
+The `fga-dev` Docker image provides a fully self-contained FGA environment using SQLite and local caching. This setup is **not intended for production** but is fine for local development, CI, and integration testing. It is less scalable than the managed instance because it cannot handle high concurrency, complex models, or large datasets.
+
+This guide will show you how to use the [`fga-dev` Docker image](https://gallery.ecr.aws/workos/fga-dev) to spin up an isolated FGA instance on your machine.
+
+---
+
+## Prerequisites
+
+To start this guide, you'll need:
+
+- [Docker](https://www.docker.com/get-started) installed on your machine
+- A [WorkOS account](https://dashboard.workos.com/) (for API keys)
+- Your WorkOS [API Key](/glossary/api-key)
+
+---
+
+## Running fga-dev Locally
+
+### Option 1: Using Docker Compose (Recommended)
+
+Create a `docker-compose.yaml`:
+
+```yaml title="docker-compose.yaml"
+version: '3.8'
+
+services:
+  fga-dev:
+    image: public.ecr.aws/workos/fga-dev:latest-arm64
+    user: root # Run as root to avoid permission issues with mounted volumes (non-production only)
+    volumes:
+      - fga-dev-volume:/data:rw,cached # Persist data between runs
+    ports:
+      - '8001:8001'
+    environment:
+      FGA_DEV_PORT: 8001
+      FGA_DEV_AUTH_API_KEY: <your_workos_api_key> # Your staging WorkOS API key to authenticate the dev image
+      FGA_DEV_TEST_API_KEY: test_key # A mock API key to authenticate FGA requests from your application
+
+volumes:
+  fga-dev-volume:
+```
+
+#### Usage
+
+1. **Start the server:**
+
+   ```shell
+   docker compose up -d
+   ```
+
+2. **Configure your app:**
+
+   - Point your application's WorkOS SDK or CLI to the proper host.
+   - Use `test_key` as the API key for FGA requests from your app.
+
+     | Environment                 | API Host                         |
+     | --------------------------- | -------------------------------- |
+     | Local machine               | http://localhost:8001            |
+     | Separate Docker container   | http://host.docker.internal:8001 |
+     | Same Docker Compose network | http://fga-dev:8001              |
+
+> If you’re using the WorkOS SDK, you can set the API Hostname option to point to your local FGA instance. Since each SDK instance supports only one API Host, you may need to create a separate SDK instance specifically for FGA when testing against the local service.
+
+3. **Develop:**
+
+   Apply schemas, create warrants, and test locally. All data persists in the Docker volume.
+
+   See [Schema Management](/fga/schema-management) for how to apply a schema to your local instance and test authorization checks.
+
+4. **Shut down:**
+
+   ```shell
+   docker compose down
+   ```
+
+5. **Clear all data (optional):**
+
+   ```shell
+   docker volume rm fga-dev-volume
+   ```
+
+> Tip: Add a secondary Docker Compose service to seed your local instance with test data on startup.
+
+---
+
+### Option 2: Running a Docker Container
+
+You can also run the `fga-dev` image directly using `docker run` if you prefer not to use Docker Compose.
+
+```shell
+docker run -d \
+  --name fga-dev \
+  -p 8001:8001 \
+  -e FGA_DEV_PORT=8001 \
+  -e FGA_DEV_AUTH_API_KEY=<your_workos_api_key> \
+  -e FGA_DEV_TEST_API_KEY=test_key \
+  -v fga-dev-volume:/data:rw \
+  --user root \
+  public.ecr.aws/workos/fga-dev:latest-arm64
+```
+
+To stop and remove the container:
+
+```shell
+docker stop fga-dev && docker rm fga-dev
+```
+
+To remove the volume and reset all data:
+
+```shell
+docker volume rm fga-dev-volume
+```
+
+---
+
+## Best Practices
+
+Consider the following best practices to ensure a smooth local development experience with FGA:
+
+- **Isolate test data**: Use unique resource IDs to avoid collisions which is especially critical when working with shared or managed instances.
+- **Automate environment setup**: Script the schema and warrant creation on first startup. This makes your development and CI pipelines more reliable and repeatable.
+- **Clean up regularly**: Tear down and reset your environment when needed to avoid stale data and hidden state, which can lead to confusing behavior.
+- **Choose the right environment**: Use a managed instance for shared, persistent testing; use the local fga-dev container for isolated development or CI.
+
+---

package/.docs/organized/docs/fga/modeling/abac.mdx

@@ -0,0 +1,107 @@
+---
+title: Attribute-Based Access Control (ABAC)
+description: >-
+  Learn how to use policies to implement a pure attribute-based access control
+  (ABAC) model in Fine-Grained Authorization (FGA).
+originalPath: .tmp-workos-clone/packages/docs/content/fga/modeling/abac.mdx
+---
+
+> Explore the example from this guide [in the FGA Playground](https://explore.fga.workos.com/playground?example=abac), where you can interact with the schema, warrants, and access checks in real-time!
+
+Attribute-Based Access Control (ABAC) is an authorization model that grants access based on attributes of users, resources, environments, and other contextual factors.
+
+FGA allows you to implement a pure ABAC model, where permissions rely solely on attributes without requiring warrant data. By centralizing authorization policies, FGA eliminates hardcoded access logic, making your system more scalable and maintainable.
+
+> **Note**: Starting with a pure ABAC model can be an effective way to remove hardcoded authorization logic while keeping policies flexible. As your needs evolve, you can seamlessly integrate Relationship-Based Access Control (ReBAC) to support permissions based on user-resource relationships, such as team memberships, delegated roles, or hierarchical access.
+
+## When to Use Pure ABAC?
+
+ABAC is ideal when access rules are complex and depend on multiple dynamic factors such as:
+
+- **Entitlements**: feature access based on plan level.
+- **Feature flags**: enabling experimental features for specific groups.
+- **Domain-specific data**: security constraints based on specific resource data attributes.
+- **Role membership**: access based on user roles or attributes that are not strictly hierarchical.
+- **Temporal data**: granting temporary access based on time-based or location-based policies.
+
+## Schema
+
+```fga
+version 0.3
+
+type user
+
+type organization
+  relation view_financial_records []
+  inherit view_financial_records if
+    // Policies can be combined with inheritance rules
+    all_of
+      policy user_in_organization
+      policy is_finance_manager
+
+  relation view_research_data []
+  inherit view_research_data if
+    all_of
+      policy user_in_organization
+      policy is_assigned_researcher
+      policy is_within_working_hours
+
+type document
+  relation edit []
+  inherit edit if
+    policy edit_document
+
+policy user_in_organization(user_attributes map, organization_id string) {
+  user_attributes.organization_id == organization_id
+}
+
+policy is_finance_manager(user_attributes map) {
+  user_attributes.department == "finance" &&
+  "manager" in user_attributes.roles
+}
+
+policy is_assigned_researcher(user_attributes map, project_id string) {
+  user_attributes.role == "manager" &&
+  project_id in user_attributes.assigned_projects
+}
+
+policy is_within_working_hours(access_time_epoch_seconds integer) {
+    let second_since_midnight = access_time_epoch_seconds % 86400;
+
+    // 9 AM (32400s) to 5 PM (61200s)
+    second_since_midnight >= 32400 && second_since_midnight <= 61200
+}
+
+policy edit_document(user_attributes map, document_attributes map) {
+    let user_is_document_editor = "document_editor" in user_attributes.roles;
+
+    let draft_status = document_attributes.status == "draft";
+
+    let user_can_access_document = document_attributes.organization_id == user_attributes.organization_id;
+
+    user_is_document_editor && draft_status && user_can_access_document
+}
+
+```
+
+## Example
+
+### (1) Apply the schema
+
+Create a file called `schema.txt` containing the schema definition from above. Then use the CLI to apply this schema to your WorkOS FGA environment.
+
+> Note: make sure to select the correct environment with the [CLI](https://github.com/workos/workos-cli?tab=readme-ov-file#usage)
+
+```shell
+workos fga schema apply schema.txt
+```
+
+---
+
+### (2) Check access
+
+With our environment setup, we can check the user's permissions.
+
+<CodeBlock title="Check user permissions" file="abac-check" />
+
+---

package/.docs/organized/docs/fga/modeling/blocklist.mdx

@@ -0,0 +1,84 @@
+---
+title: Blocklists
+description: >-
+  Blocklist users from accessing certain resources based on specific attributes
+  or warrants
+originalPath: .tmp-workos-clone/packages/docs/content/fga/modeling/blocklist.mdx
+---
+
+> Explore the example from this guide [in the FGA Playground](https://explore.fga.workos.com/playground?example=blocklist), where you can interact with the schema, warrants, and access checks in real-time!
+
+A blocklist allows systems to deny access to specific users or sessions based on contextual data or warrants.
+
+## When to Use It?
+
+- A user IP address is associated with suspicious behavior
+- A user is flagged for abuse
+- A user is subject to temporary access restrictions (e.g., after multiple failed login attempts)
+
+This approach combines relationship-based access control (ReBAC) with attribute-based access control (ABAC), giving you fine-grained control without complicating your core permissions model.
+
+## Example Applications
+
+- **Content Moderation**: Block users from viewing or interacting with content based on their IP address.
+- **E-commerce Systems**: Block users from purchasing or viewing products based on behavior patterns.
+- **Banking and Finance**: Deny access based on fraud scores or geolocation mismatches.
+
+## Schema
+
+```fga
+version 0.3
+
+type user
+
+type store
+  relation member [user]
+
+type item
+  relation owner [store]
+  relation blocked [user]
+
+  relation view []
+  inherit view if
+    all_of
+      relation member on owner [store]
+      // Users are blocked either explicitly or with the ip_not_allowed policy
+      none_of
+        relation blocked
+        policy ip_not_allowed
+
+
+policy ip_not_allowed(ip_risk_score integer) {
+  ip_risk_score > 75
+}
+```
+
+## Example
+
+### (1) Apply the schema
+
+Create a file called `schema.txt` containing the schema definition from above. Then use the CLI to apply this schema to your WorkOS FGA environment.
+
+> Note: make sure to select the correct environment with the [CLI](https://github.com/workos/workos-cli?tab=readme-ov-file#usage)
+
+```shell
+workos fga schema apply schema.txt
+```
+
+---
+
+### (2) Create warrants
+
+Create warrants that associate users, stores, and items. Add a blocked user to an item.
+
+<CodeBlock title="Create warrants" file="blocklist-create-warrants" />
+
+---
+
+### (3) Check access
+
+With our environment setup, we can check the user's permission to view items.
+
+<CodeBlock title="Check if a user can view an item" file="blocklist-check" />
+
+---