Overview

Access Controls in Rustici Generator

This guide covers how Rustici Generator authenticates callers and authorizes what they can do. Access is layered: a credential defines identity, and authorization scopes decide which API actions are allowed (globally or per tenant). For MCP tokens, you can further limit search and read visibility through access control targets and policies.

How access is decided

Generator evaluates access in this order:

  1. Authenticate with a credential to mint a bearer token. Tokens are audience-bound: request API_V1 for the REST API or MCP for Generator’s MCP server. See API Authentication .
  2. Authorize the action using the credential’s scopes and tenants properties. These are SUBJECT and VERB pairings (for example, READ on CONTENT). A request is allowed if either the global scopes or the matching tenant entry permits it. Verbs are not compounding: WRITE does not include READ or DELETE. See Authorization Scopes .
  3. Isolate data by tenant. Most endpoints require a tenant. A credential can only see a tenant’s data only if it has access to the tenant. See Tenant Management .
  4. Optionally filter content for MCP. Credential scopes still apply, but an Access Control Policy attached at login can hide content inside the tenant. Policies are built from targets (named groups of content). Policies can only be attached to MCP tokens, not API_V1 tokens. See Access Control Targets and Policies .

The root credential created at setup uses the * wildcard for both subject and verb and can perform any action. We strongly recommend creating additional credentials with tighter scopes instead of using root for day-to-day integrations. See Credentials Management .

In this section

If you are connecting an LLM client, see MCP Integration for credential recommendations and how policies apply to search and read tools.