Zero-trust security, derived from your schema.
Tenant isolation is computed from foreign keys and enforced in one data path. There is no filter for a developer to forget, so the most expensive class of data leak is engineered out.
- ·The most expensive multi-tenant bug is a forgotten tenant filter. Here there is no filter to forget, because the path to the tenant is computed from your own foreign keys.
- ·Every table starts denied. Access is an explicit grant held as data you can review, not code someone has to read.
- ·One data path carries every read and write, so there is no back door around the rules, including for an AI agent.
The number one multi-tenant failure is a forgotten WHERE clause.
Every multi-tenant system rebuilds the same dangerous plumbing: a tenant column, a convention, and hundreds of hand-written filters that all have to be right. One missing filter on one query exposes one customer's data to another. It passes code review, it passes tests, and it surfaces as a breach.
The usual answer is discipline: policies, reviews, testing. Discipline doesn't scale across years of changes and rotating teams. The failure mode isn't incompetence. It's that the design depends on nobody ever making the mistake.
The mechanisms, not the adjectives.
Foreign-key walk at load time
The security engine loads each governed table and walks its foreign keys to find the path to the tenant table. Root tables filter on their own tenant column. Child tables get a synthesized join chain to the nearest tenant-owning ancestor. The resolved paths are cached and applied to every read and write.
Isolation is a property of the data model, not of developer discipline. Model a normal foreign key and scoping comes with it.
Deny by default
Every table starts denied. Access is granted per operation through permission keys (row.select, row.insert, row.update, row.delete) resolved per user, per tenant, through role membership. A null key means always denied. There is no silent inheritance.
The system defaults to deny. Getting access requires an explicit, auditable grant, and that grant is data you can review, not code you have to read.
One data path, no bypass
All reads and writes flow through a single no-ORM data manager. Filters are scrubbed for injection. Sort fields are whitelisted. The one deliberate escape hatch requires a written justification that lands in the audit log on every execution.
One chokepoint means security, tenancy, and audit are enforced uniformly. There is no back-door query that skips the rules.
Column-level security and a tenant hierarchy
Sensitive columns can be gated independently of the row. Tenants form a hierarchy: a user sees their tenant and its descendants, never a sibling organization. Rows missing a tenant assignment are hidden from everyone. The system fails closed.
Defense in depth at the field level, and an org model that matches how enterprises are actually structured.
Register a table. Watch what you didn't have to do.
- 1
Add your table to the security registry with its permission keys. That's the whole task.
- 2
At refresh, the engine walks the schema, finds the tenant path, and compiles the join chain for that table.
- 3
Every query from every client now carries the tenant scope and permission checks. Nobody wrote a filter.
- 4
Try to read it without a grant: denied. Try to reach another tenant's rows: they don't exist as far as the query is concerned.
- 5
Check the audit trail: the change history and every access decision are already being recorded.
The AI angle.
IBM found 97 percent of organizations with an AI-related breach lacked AI access controls. On Forge, an AI agent gets a session like any user, and the engine scopes everything it touches. A prompt injection can change what an agent asks for. It can't change what the data path lets it see, because the enforcement lives below the model.
Keep going.
AI done right
MCP-native access, prompt-authored rules, and a security engine every AI agent inherits.
Go deeper →Data & instant API
Register a table and it is secured, audited, and queryable. No ORM, no per-table code.
Go deeper →Operations
The platform ships with its own ops console, real-time notifications, and full change history.
Go deeper →See it on your schema, not ours.
A fixed-price assessment gets this running over your actual data.