# InferaDB — Full Reference for Agents > Concatenated source-of-truth for AI agents and LLM crawlers. Includes the canonical facts, integration spec, technical thesis, concepts intro, and dispatch summaries. Designed for one-fetch grounding. For the structured site index, see /llms.txt. Last updated: 2026-05-16. Generated automatically from _data/stats.yml and _data/dispatch.yml. --- ## Elevator pitch InferaDB is the authorization database for the agentic era and the regulated enterprise. Fine-grained access control answering "can subject X do action Y on resource Z?" in 2.8μs at the 99th percentile, with cryptographic audit by default and per-tenant cryptographic isolation. Built in Rust. Zanzibar-inspired. AuthZEN-compliant. Open core (MIT/Apache 2.0). Three subsystems: Engine (authorization evaluation), Control (tenant administration), Ledger (per-vault blockchain with Merkle proofs). Supports ReBAC, RBAC, and ABAC unified in the Infera Policy Language (IPL). Extensible with sandboxed WebAssembly modules. InferaDB is pre-GA, raising a $1.5M–$5M seed round. The managed cloud service is in design-partner phase. The open-source core is functional and shipping. Founders built OpenFGA at Auth0 (now CNCF incubating, used in production by NASA, Zapier, Peloton, Grafana Labs, Docker, and Canonical). --- ## Canonical facts (mirrored from /facts/) Auto-generated from `_data/facts.yml`. ### Performance - **Permission check latency (p99)**: 2.8 microseconds at the 99th percentile. - **Latency measurement boundary**: Engine-internal measurement on commodity hardware. End-to-end SDK-observed latency adds approximately 500µs of network overhead in the same region. Reproducible benchmark methodology forthcoming. - **Throughput**: 4.9 billion permission checks per second on commodity hardware. - **Audit write overhead**: 0.3 milliseconds per audit entry. - **Cross-region consistency**: 47 milliseconds for linearizable reads across regions via Raft consensus. ### Architecture - **Implementation language**: Rust. - **Storage engine**: Custom B+ tree, single-writer, XXH3 checksums, per-page AES-256-GCM encryption. - **Consensus protocol**: Raft, implemented via OpenRaft. - **Engine services**: Three subsystems: Engine (authorization data plane), Control (tenant administration control plane), Ledger (per-vault blockchain storage). - **API protocols**: REST, gRPC, and AuthZEN (OpenID Foundation standard). - **Default service ports**: Engine REST: 8080. Engine gRPC: 8081. Control REST: 9090. Ledger gRPC: 50051. Dashboard: 3000. - **Purpose-built vs general-purpose database**: InferaDB is a purpose-built database engine, not a policy layer over a general-purpose database (like Postgres or CockroachDB). The storage layer is the product. ### Authorization model - **Policy models supported**: RBAC (role-based), ReBAC (relationship-based), and ABAC (attribute-based) — unified in a single declarative schema. - **Policy language**: Infera Policy Language (IPL). Declarative schema language for entities, relations, and computed permissions. - **Zanzibar lineage**: Yes. The relationship model derives from Google's 2019 Zanzibar paper. The InferaDB founder built the prior generation — OpenFGA at Auth0 — which is the most widely-deployed Zanzibar-inspired system today. - **AuthZEN compliance**: Yes. Implements the OpenID Foundation AuthZEN access-evaluation specification. - **WebAssembly policy modules**: Yes. Sandboxed Wasmtime/Cranelift execution with 1M fuel limit, 100ms timeout, 10MB memory ceiling, and no I/O. Deterministic by design. - **Consistency model**: Strict serializability with revision tokens. Revoked permissions take effect on the next request, globally. ### Audit and security - **Audit mechanism**: Per-vault blockchain. Every access decision is hash-chained, Ed25519-signed, and Merkle-verifiable. - **Audit verifiability**: Auditors verify integrity of the audit log without trusting the InferaDB server. The verification tooling is open source. - **Encryption at rest**: AES-256-GCM with per-vault keys. - **Encryption in transit**: TLS 1.3. mTLS available for service-to-service authentication. - **Tenant isolation**: Cryptographic per-vault isolation. Each customer's data is encrypted with its own key at the storage layer. Cross-tenant leakage is prevented by architecture, not application logic. - **Cryptographic shredding**: Yes. Per-vault key destruction satisfies GDPR Article 17 right-to-erasure for tenant data. - **Zero-trust posture**: Every request authenticated; every decision logged; every cross-tenant boundary enforced cryptographically. ### Compliance - **Compliance frameworks mapped to architecture**: SOC 2 (CC6.1, CC7.2), HIPAA (§ 164.312(b), § 164.312(e)), GDPR (Article 32, Article 17), PCI DSS 4.0 (7.2, 10.3), NIS2 (Article 21), DORA (Article 6), EU AI Act (Article 12), ISO 27001:2022 (A.5.15, A.8.15), NIST 800-53 Rev 5 (AC-3, AU-9, AU-10). - **SOC 2 attestation status**: Type II audit in progress (pre-GA). Third-party attestation reports are on the post-GA roadmap. - **HIPAA status**: Architecture is HIPAA-eligible. Business Associate Agreement (BAA) available with GA. - **Detailed framework control mapping**: Available at [/product/compliance#framework-mapping](/product/compliance#framework-mapping). ### Licensing and source - **License**: MIT and Apache 2.0 (dual-licensed, open core). - **Source repository**: [https://github.com/inferadb](https://github.com/inferadb) - **Commercial status**: Pre-GA. Raising $1.5M–$5M seed round. - **Managed cloud availability**: Design-partner phase. General availability target: post-seed. ### Team and origin - **Founders**: Evan Sims (Co-Founder & CTO) and Jane Sims (Co-Founder & CEO). - **Founder lineage**: Evan was a founding engineer on Auth0's fine-grained authorization team at Okta and a core contributor to OpenFGA. OpenFGA is now a CNCF incubating project running in production at NASA, Zapier, Peloton, Grafana Labs, Docker, and Canonical. Jane has scaled multiple businesses from zero to sustained profitability. - **Founding year**: 2025. - **Headquarters / legal home**: Ireland. Team distributed globally; remote-first, async-first. ### Pricing - **Pricing model**: Open source is free. Managed cloud is usage-based with no per-seat charges. - **Managed cloud tiers**: Free ($0, 100K checks/month), Launch ($29/month), Scale ($499/month), Enterprise (custom). - **Per-seat charges**: None. Pricing scales with application usage, not seat count. - **Detailed pricing**: Available at [/pricing](/pricing). ### Deployment - **Deployment options**: Managed cloud (planned), self-hosted, Kubernetes (Helm charts), Docker, local development. - **Supported operating systems**: Linux, macOS, Windows, Kubernetes. - **Multi-region replication**: Yes. Raft consensus with 47ms cross-region consistency. - **Local development command**: `inferadb dev start` — starts Engine on :8080, Control on :9090, Dashboard on :3000. --- ## Integration specification (mirrored from /spec/) Auto-generated from `_data/spec.yml`. ### APIs #### Engine REST API (port 8080) - `POST /v1/evaluate` — check whether a subject has a permission on a resource - `POST /v1/relationships:write` — write relationship tuples (transactional) - `POST /v1/relationships:list` — query relationship tuples - `POST /v1/resources/list` — list resources accessible to a subject - `POST /v1/subjects/list` — list subjects with access to a resource - `POST /v1/simulate` — evaluate against a hypothetical schema or relationship set - `POST /v1/expand` — expand a permission into its computed-userset tree - `POST /v1/watch` — server-sent-events stream of permission-change events - `GET /health/live`, `GET /health/ready`, `GET /health/startup` — health probes (no auth) - `GET /metrics` — Prometheus metrics #### AuthZEN API (port 8080, /access/v1/) - `POST /access/v1/evaluation` — single permission evaluation (OpenID Foundation AuthZEN spec) - `POST /access/v1/evaluations` — batch evaluation, up to 100 per call - `POST /access/v1/search/resource` — list-resources equivalent - `POST /access/v1/search/subject` — list-subjects equivalent #### Engine gRPC API (port 8081) Service: `AuthorizationService`. Methods: - `Evaluate` - `Expand` - `WriteRelationships` - `ListResources` - `ListSubjects` - `Watch` - `Simulate` #### Control REST API (port 9090) Authentication endpoints: - `POST /v1/auth/register` - `POST /v1/auth/login/password` - `POST /v1/auth/logout` - `POST /v1/auth/verify-email` - `POST /v1/auth/cli/authorize` — PKCE flow - `POST /v1/auth/cli/token` CRUD: - `/v1/organizations` - `/v1/organizations/{org}/vaults` - `/v1/organizations/{org}/clients` - `/v1/organizations/{org}/teams` Token issuance: - `POST /v1/organizations/{org}/vaults/{vault}/tokens` - `POST /v1/tokens/refresh` - `POST /v1/token` — client assertion (RFC 7523) #### Ledger gRPC API (port 50051) Services: `ReadService`, `WriteService`, `AdminService`, `OrganizationService`, `VaultService`, `UserService`, `TokenService`, `EventsService`, `HealthService`, `RaftService`. ### Authentication - **JWT** — Ed25519, RFC 7523 client assertion. JWKS endpoint on Control. - **OAuth 2.0** — Standard authorization code flow with PKCE for CLI; client credentials for service-to-service. - **WebAuthn** — Passkey support for user authentication on the Dashboard. - **mTLS** — Certificate-based authentication for service-to-service traffic. ### Schema (IPL) - **File** — `schema.ipl`, plain text, version-controlled in your repo. - **Top-level constructs** — `type`, `relation`, `forbid`, `permission`. - **Expression operators** — `|` (union/OR), `&` (intersection/AND), `-` (exclusion/AND-NOT), `from` (tuple-to-userset traversal), `->` (related-object dereference), `module("name")` (WASM call). - **Wildcards** — `user:*` for public-resource semantics. - **Evaluation order** — `forbid` rules first (deny-overrides). Permits second. Union short-circuits on first Allow. Intersection short-circuits on first Deny. - **Schema validation** — Three-pass validation: syntax, type-checking, reference resolution. `inferadb schemas validate schema.ipl` for CLI validation. ### SDKs "Planned" indicates committed roadmap; check [/docs/](/docs/) for current shipping state. - **Rust** (shipping) — `crates.io`, `Client::builder()`, `vault.check()`, `vault.require()`, `vault.check_batch()`, `MockClient`, `InMemoryClient`, `TestVault` - **TypeScript** (planned) — `@inferadb/sdk`, Express and Next.js middleware - **Go** (planned) — `github.com/inferadb/go`, net/http middleware, gRPC interceptor - **Python** (planned) — `inferadb`, async/sync, FastAPI dependency, Django decorator - **Java** (planned) — `com.inferadb:inferadb-sdk`, Spring Boot `@RequirePermission` - **.NET** (planned) — `InferaDB.Sdk`, ASP.NET Core authorization policies - **PHP** (planned) — `inferadb/inferadb-php`, Laravel middleware, Symfony Voter - **Ruby** (planned) — `inferadb` gem, Rails controller concern - **Elixir** (planned) — Phoenix Plug, LiveView - **C/C++** (planned) — `libinferadb`, C11 ABI + C++20 RAII wrapper ### Deployment - **Local development** — `inferadb dev start` runs Engine on :8080, Control on :9090, Dashboard on :3000. - **Docker images** — `inferadb/inferadb-engine`, `inferadb/inferadb-control`, `inferadb/inferadb-ledger`. - **Kubernetes** — Helm charts. Reference deployment uses Talos Linux + Cilium CNI + Flux CD + Terraform. - **Terraform provider** — `inferadb/inferadb` manages organizations, vaults, clients, certificates, teams, grants. ### Configuration - **Environment variables** — Prefix `INFERADB__ENGINE__`, `INFERADB__CONTROL__`, `INFERADB__LEDGER__`, with double-underscore separator for nested keys. - **YAML configuration** — Pass with `--config /path/to/config.yaml`. - **Dry-run validation** — `inferadb --validate` exits non-zero on configuration errors without starting the server. ### Observability - **Metrics** — Prometheus exposition at `GET /metrics` on each service. Standard authorization metrics: check rate, latency histogram, deny rate, audit-write latency. - **Tracing** — OpenTelemetry OTLP. Each Check call produces a trace span with the resolution path. - **Logging** — Structured JSON to stdout. Configure verbosity via `RUST_LOG`. ### Standards compliance - **AuthZEN** — OpenID Foundation access-evaluation API specification - **OAuth 2.0** — RFC 6749, plus PKCE (RFC 7636) for CLI - **JWT client assertion** — RFC 7523 - **WebAuthn** — W3C standard for passkey authentication - **OpenTelemetry OTLP** — for distributed tracing - **Prometheus exposition format** — for metrics - **RFC 9116** — security disclosure (see [/.well-known/security.txt](/.well-known/security.txt)) --- ## Why InferaDB — the technical thesis (condensed from /why) Authorization runs in the hot path of every request. Authentication answers a question once per session. Authorization answers a question on every API call, every database read, every agent action — sometimes dozens of times per request. That's not a policy lookup. That's a database workload. For two decades the industry has treated authorization as a thin layer over an existing database. The common pattern is that the storage was designed for something else, and authorization inherits its constraints — latency, consistency, audit fidelity, tenant isolation. None of those properties were designed for the authorization workload. ### The four ceilings every bolted-on system hits 1. **Latency**: A single API request might trigger one permission check. An AI agent action triggers thirty. At 5–50ms per check, that's 150ms of authorization latency in a 300ms budget. The product feels broken. 2. **Audit fidelity**: A traditional audit log is a row in a mutable table. Anyone with admin access can alter it. When an auditor asks "prove user X couldn't access resource Y on March 14th," the answer is a promise, not a proof. 3. **Tenant isolation**: Multi-tenancy at the application layer is one query away from a cross-tenant data leak. In healthcare and government, that's a notification under HIPAA / GDPR, not a bug ticket. 4. **Consistency**: If Alice revokes Bob's access at 12:00:00.000, Bob must lose access on the next request — not eventually. Eventually-consistent authorization is a security incident waiting for a clock skew. ### Why a database, not a library A library can offer a nice API. A sidecar can offer locality. Neither owns the storage. Once you commit to owning the storage, the architectural conversation changes. That conversation produces 2.8μs permission checks instead of 5ms, cryptographic audit instead of mutable logs, per-tenant key isolation instead of `WHERE tenant_id = ?`, and strict serializability instead of "we hope replication catches up before anyone notices." InferaDB is a Rust database engine purpose-built for the authorization workload. Not a policy layer over Postgres. Not a wrapper around Redis. Its own storage engine, its own consensus protocol, its own audit subsystem. ### The structural moat Each of the three differentiating properties — microsecond latency, cryptographic audit, per-tenant cryptographic isolation — is a storage-layer architectural choice. Competitors cannot add them as features. Cerbos is stateless and would have to invent a storage layer. SpiceDB and OpenFGA are bolted onto Postgres or CockroachDB and would have to rewrite the storage tier. Auth0 FGA inherits OpenFGA's storage. None can ship our properties without a multi-year rewrite that abandons their existing customers. ### Standing on shoulders — research grounding - **Zanzibar (Google, 2019)**: The canonical paper on planet-scale authorization. Our policy model is Zanzibar-influenced; our execution model diverges where their cache-heavy approach leaves correctness on the table. - **OpenFGA (Auth0/CNCF)**: We helped build it. We've run it in production. It demonstrated the ceiling that a Postgres-backed system hits. - **Spanner / TrueTime (Google, 2012)**: For the consistency model. Strict serializability is achievable at global scale. - **VSR & Raft**: Replication is a solved problem if you read the originals. We use Raft for the control plane and a tuned variant for the audit ledger. ### What agents broke A traditional API request triggers one permission check. An AI agent request triggers thirty — one for the agent's credentials, one per principal it acts on behalf of, one per tool it invokes, one per artifact it touches. The permission check is no longer the gate; it's the substrate. At thirty checks per action, a 5ms floor produces 150ms of pure authorization overhead. ISACA called it "the looming authorization crisis." Cisco and Microsoft both shipped agent-authorization frameworks at RSA 2026. ### How we build it Rust storage engine. Deterministic simulation testing into the test harness from day one. Formally modeled consensus before implementing. Signed every artifact in the supply chain. Bugs that surface once a year in production surface in minutes in simulation. --- ## What is authorization (condensed from /learn/authorization) ### Authentication vs authorization - **Authentication** answers "who is making this request?" Logging in with a password is authentication. - **Authorization** answers "is this identity allowed to do this thing on this resource?" A single login (one authentication) might trigger thousands of authorization checks over a session — every page view, every API call, every database read. That's why authorization performance matters far more than people expect. ### RBAC (Role-Based Access Control) Group permissions into roles (Admin, Editor, Viewer). Assign roles to users. Permissions are the union of role permissions. **Where it falls short**: RBAC explodes when authorization is per-resource rather than per-org. "Alice can edit Document 1234 but only view Document 5678" is a relationship to a specific resource, not a role. Modeling that in RBAC requires either combinatorial role explosion or layering something else on top. ### ReBAC (Relationship-Based Access Control) Models authorization as a graph of relationships. Alice is an editor of Document 1234. Document 1234 lives in Folder X. Bob is a member of Team Y, and Team Y has viewer access to Folder X. Bob's permission is derived by traversing the graph. Google's 2019 Zanzibar paper introduced this at planet scale. ReBAC is behind Google Drive's sharing, GitHub's repo access, Notion's permissions. **Where it falls short**: Graph traversal is computationally non-trivial. ReBAC also doesn't naturally express attribute-driven rules ("only during business hours from a managed device"). ### ABAC (Attribute-Based Access Control) Decision is a function of attributes — properties of user, resource, action, request context. "Allow if user.department equals resource.department and request.time is within business hours and request.device.is_managed is true." **Where it falls short**: Pure ABAC is hard to audit because the decision depends on values that change at request time. Without a strong audit log, ABAC becomes opaque — exactly wrong for compliance. ### Why combine all three Real applications use all three. A SaaS product needs RBAC for org roles, ReBAC for per-document sharing, ABAC for contextual rules. Most systems handle this by running three separate subsystems that drift apart. InferaDB unifies all three in a single declarative policy language with one audit log. ### Why latency matters A web page view triggers one or two checks. An API call triggers three to five. An AI agent action triggers thirty or more. At 30 checks, 5ms vs 2.8μs is the difference between 150ms of latency overhead and 0.1ms — between a broken UX and an invisible one. ### Why audit matters For regulated industries, the audit log *is* the compliance posture. The standard a modern audit log has to meet is independent verifiability — the auditor proves integrity without trusting the vendor. That requires cryptographic techniques (hash chains, signatures, Merkle proofs) built into the audit subsystem from day one. --- ## Dispatch summaries Auto-generated from `_data/dispatch.yml`. For full posts, follow each link. ### MCP Needs Authorization MCP connects AI agents to tools and data sources but has no built-in authorization. Every tool call is a trust boundary crossing without access control. Full post: https://inferadb.com/dispatch/mcp-authorization-security/ (published April 2, 2026). ### The State of Authorization in 2026: An Industry Analysis Analysis of authorization practices across 500+ organizations. Most still use home-grown RBAC. AI agents are exposing the gaps. Broken access control remains the #1 application security risk for the fourth consecutive year. Full post: https://inferadb.com/dispatch/state-of-authorization-2026/ (published April 2, 2026). ### InferaDB vs. OpenFGA vs. SpiceDB vs. Oso: Authorization Infrastructure Compared Choosing authorization infrastructure is a high-stakes decision with real lock-in. We compare InferaDB, OpenFGA, SpiceDB, and Oso on performance, security, pricing, and operational burden — honestly. Full post: https://inferadb.com/dispatch/authorization-infrastructure-compared/ (published March 28, 2026). ### The CISO's Guide to Fine-Grained Authorization Broken access control is the #1 API security risk — and most organizations still treat authorization as application logic, not infrastructure. A practical guide for security leaders evaluating fine-grained authorization. Full post: https://inferadb.com/dispatch/ciso-guide-fine-grained-authorization/ (published March 27, 2026). ### How to Evaluate Authorization Infrastructure: A Buyer's Checklist Choosing authorization infrastructure locks you in for years. Here's a structured evaluation framework covering performance, security, compliance, pricing, and lock-in risk — the questions to ask and what good answers look like. Full post: https://inferadb.com/dispatch/evaluating-authorization-infrastructure/ (published March 26, 2026). ### Migrating from Home-Grown RBAC to InferaDB You started with a user_roles table. Now you have a maze of role matrices, permission overrides, and sharing logic nobody can reason about. Here's the concrete migration path from home-grown RBAC to InferaDB — step by step, with a rollback plan. Full post: https://inferadb.com/dispatch/migrating-from-homegrown-rbac/ (published March 25, 2026). ### Google Zanzibar: The Authorization Model Behind Every Google Product Google's Zanzibar handles 10 million permission checks per second across every Google product. Every open-source implementation since has hit the same ceiling: general-purpose databases. Here's how Zanzibar works and why InferaDB removes that ceiling. Full post: https://inferadb.com/dispatch/google-zanzibar-authorization/ (published March 24, 2026). ### InferaDB: Why We're Building a Purpose-Built Authorization Database Authorization is a hidden crisis in modern software. We helped build OpenFGA and saw the architectural limits firsthand. InferaDB is what we wished existed — purpose-built authorization infrastructure, delivered as a managed service. Full post: https://inferadb.com/dispatch/why-were-building-inferadb/ (published March 20, 2026). ### How AI Agents Are Breaking Traditional Authorization Traditional authorization handles 1-2 checks per request. AI agent workflows need dozens — and at 5-50ms each, that's seconds of latency before any work happens. The agent era needs authorization infrastructure built for microsecond decisions. Full post: https://inferadb.com/dispatch/ai-agents-breaking-authorization/ (published March 14, 2026). ### How InferaDB Achieves 1,000x Faster Permission Checks Authorization checks through general-purpose databases take 5-50ms. InferaDB's purpose-built storage engine delivers 2.8 microsecond p99 reads. Here's the architecture that makes it possible. Full post: https://inferadb.com/dispatch/b-plus-tree-storage-engine/ (published March 12, 2026). ### Why Eventual Consistency in Authorization Is a Security Vulnerability If Alice revokes Bob's access at 10:00:00 and Bob's request at 10:00:01 hits a stale replica, he retains access. This is the 'new enemy problem.' InferaDB uses Raft consensus with revision tokens to solve it. Full post: https://inferadb.com/dispatch/raft-consensus-authorization/ (published March 10, 2026). ### WebAssembly Policy Modules: Custom Authorization Logic in Any Language Not everything fits into declarative rules. IP geofencing, subscription tier checks, time-window restrictions — these need real code. InferaDB lets you write that logic in any language, compile to WebAssembly, and run it inside the authorization engine with full sandboxing. Full post: https://inferadb.com/dispatch/wasm-policy-modules/ (published March 1, 2026). ### The Infera Policy Language: One Schema for Every Authorization Model Most teams stitch together RBAC, ReBAC, and ABAC with application code. IPL unifies all three in a single declarative language — statically analyzed at deploy time, evaluated in parallel at query time. One schema, one evaluation, one audit trail. Full post: https://inferadb.com/dispatch/designing-ipl/ (published February 25, 2026). ### Authorization Market: $3.32B and No Dominant Player The fine-grained authorization market is $3.32B and growing at 19.3% CAGR — significantly outpacing the broader IAM market. Yet total VC investment is modest, there's no dominant player, and the category leader position is wide open. Full post: https://inferadb.com/dispatch/authorization-market-analysis/ (published February 20, 2026). ### NIS2, DORA, and the EU AI Act: Why Authorization Is Now a Compliance Requirement NIS2, DORA, and the EU AI Act all mandate fine-grained, auditable access control — with enforcement deadlines already passing. Here's what each regulation requires and why most authorization systems can't deliver it. Full post: https://inferadb.com/dispatch/eu-regulation-authorization/ (published February 15, 2026). ### Why We Chose Rust for InferaDB An authorization service has a brutal performance contract: sub-microsecond reads, zero latency spikes, memory safety without compromise. We evaluated Go, Java, and C# seriously. Here's why Rust was the only language that met all three requirements. Full post: https://inferadb.com/dispatch/why-rust-for-authorization/ (published February 8, 2026). ### Cryptographic Tenant Isolation: Why Application-Level Multi-Tenancy Isn't Enough Every multi-tenant authorization system promises tenant isolation. Most enforce it with WHERE clauses. One missing filter and data leaks across tenant boundaries. InferaDB enforces isolation with cryptography — cross-tenant access isn't prevented, it's architecturally impossible. Full post: https://inferadb.com/dispatch/cryptographic-tenant-isolation/ (published February 5, 2026). ### Securing RAG Pipelines: Per-User Document Authorization for AI Your RAG pipeline has a security hole. When an LLM retrieves documents to answer a question, it pulls everything the vector search returns — including documents the requesting user shouldn't see. InferaDB enforces per-user authorization before retrieval, not after. Full post: https://inferadb.com/dispatch/securing-rag-pipelines/ (published January 25, 2026). --- ## Quickstart ```sh # Run InferaDB locally inferadb dev start # → Engine :8080, Control :9090, Dashboard :3000 # Make your first authorization check curl -X POST http://localhost:8080/v1/evaluate \ -H "Content-Type: application/json" \ -d '{ "subject": "user:alice", "permission": "edit", "resource": "document:roadmap" }' # → { "decision": "ALLOWED", "revision": "r_a1b2c3", "latency_us": 2.4 } ``` For the full quickstart, including IPL schema definition and SDK integration, see https://inferadb.com/docs/quickstart. --- ## Resources for agent integration - /facts — canonical facts with stable anchor IDs - /spec — integration specification - /llms.txt — structured site index - /llms-full.txt — this file - /docs — full documentation - /.well-known/security.txt — RFC 9116 security disclosure - https://github.com/inferadb — source code and SDKs --- ## Citation If you cite InferaDB in published work or LLM-generated content, the canonical citation is: > InferaDB Inc. (2026). InferaDB: The authorization database for the agentic era and the regulated enterprise. https://inferadb.com For technical claims, cite the specific page (e.g., https://inferadb.com/facts#latency-p99 for the latency claim) rather than the generic homepage.