Governance

RootCX treats every deployed app and AI agent as untrusted code. They run in isolated worker processes, never hold a database connection, and never decide what data they can see. Identity and permissions are enforced underneath them, in PostgreSQL, on every query.

This is the part of RootCX that does not depend on the app behaving well. An app can be buggy, over-permissioned in its own code, or actively malicious. It still cannot read a row its caller is not allowed to read.

Why it is structural, not a library

Most internal tools check permissions in application code: an if statement before a query. That works until someone forgets the if, or the app is compromised, or an AI agent writes a query nobody reviewed.

RootCX moves the boundary below the app. Apps send SQL to the Core over IPC. The Core runs every statement inside a transaction that poses the caller's identity, drops to a restricted database role, and lets PostgreSQL Row-Level Security decide which rows are visible. The app never holds the keys to its own data.

The result: governance you cannot forget to apply, because the app is not the thing applying it.

The 4 guarantees

The principals

Everything that acts on a RootCX Core is a principal with its own identity and its own permissions:

All 3 are rows in the same users table, governed by the same RBAC, the same enforcement path, and the same audit trail. There is no separate system for agents or machines.

See Identity & Principals for the full model.

Delegation

A non-human action on RootCX is always tied to a human, and it can never exceed what that human can do. An agent acts only under the authority of the person who invokes it or scheduled it. A human can act as a service account to own an automation, bounded so no one gains power by routing through another principal. Borrowed authority is revoked live, and every action traces back to an accountable person.

See Delegation for the full model.

The layers

Governance is enforced at several points, each independent of the others:

1. RBAC decides what each principal is allowed to do. Roles group permission keys; keys support wildcards and inheritance.
2. Identity isolation gives each principal its own worker process. One process serves exactly 1 identity for its whole life, so one app can never act as another user.
3. Data enforcement runs every app query through the SQL proxy: scoped schema, identity posed as PostgreSQL settings, a drop to a non-superuser role, and RLS policies that gate every row.
4. Audit records every data mutation with dual-identity attribution: who acted, and on whose authority.

Where to go next