Authentication & scopes

Every call into Fabric is authenticated and pinned to an immutable scope. There are two ways an agent can authenticate, and the scope model is the same for both.

Two credential types

API keys (fab_sk_…)

Project-scoped keys you generate in Simple Mode. Best for headless agents, config-file MCP clients, CI, and scripts.

• Format fab_sk_…, sent as Authorization: Bearer fab_sk_….
• SHA-256 hashed at rest — Fabric never stores the raw secret; it is shown once at creation.
• Project-scoped and revocable; rotate with Regenerate.

OAuth 2.1

For interactive clients that support remote MCP authorization (such as Claude.ai). When your client connects, discovery and consent happen automatically.

• PKCE S256 mandatory, single-use authorization codes, rotating refresh tokens.
• Dynamic Client Registration (DCR) — clients register themselves.
• Consent pins the token to organization → department → project plus the specific tool grants you approve.
• Discovery endpoints: /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource.

Point a remote-MCP client (e.g. Claude.ai) at the Fabric MCP URL and OAuth discovery + DCR happen automatically — you don’t configure them by hand.

Scope: how isolation is enforced

Fabric resolves an immutable organization → department → project scope on every request. No request can widen its own scope. Your credential is pinned to a single workspace (project), and:

• the project_id is injected server-side — a client cannot rebind it;
• retrieval data is physically isolated per project, not merely filtered;
• a department can tighten but never loosen inherited grants.

This is why cross-tenant reads are impossible even if a client misbehaves.

Tool grants

Each tool requires a grant:

Grant	Allows
fabric:query.read	query-context
fabric:ontology.write	create-ontology, save-context
fabric:docs.read	docs

With OAuth, grants are part of the consent you approve. With an API key, the key carries read access to its workspace’s context.

Defense in depth on reads

Read queries pass a Cypher guard before execution: comments and string literals are stripped, write clauses (CREATE/MERGE/SET/DELETE/…) are denied, procedure calls are restricted, a mandatory project_id filter is bound server-side, and LIMIT/timeout are clamped. As a final layer the executor runs against a read-only role. The result: an agent cannot write through a read tool or escape its project scope.

What you get back

Every response carries a lifecycle_id. Use it to inspect the call’s trace, policy decision, approval (if any), and audit entry. See Governance & audit.