Governance

​

Read-only by default

• Databases are read-only at the session level — the connection is opened read-only, so mutating SQL is rejected by the database itself, whatever the assistant writes.
• REST / GraphQL / SaaS sources only expose read operations to the agent. Mutating operations (POST/PUT/PATCH/DELETE, GraphQL mutations) are not produced as tools unless you opt the connection into writes. The agent never sees a tool it isn’t allowed to call — the guard is structural, not a denylist or a prompt.

​

Opting into writes

• API / SaaS connections — turning it on gains the agent the mutating operations for that source, and only that source. You can still switch individual endpoints off.
• Databases — turning it on adds a single separate write action. Reads keep running in a read-only transaction even then, so the query tool can never become a way to change data, and schema changes (CREATE/ALTER/DROP/TRUNCATE) are refused outright. The write runs as the user in your connection string, so grant that user only what you’re willing to expose.

​

Two shapes of database access

• Free-form SQL — the assistant browses the schema and writes its own queries. Useful for exploration by your own team; wide by nature.
• Saved queries — you write the query once, name its parameters, and it becomes a single named action. The assistant supplies values, never SQL. Turn Let the assistant write SQL off and these are the entire surface: it can reach nothing you didn’t put there.

-- Saved as "get_customer_orders"
SELECT id, total, status, created_at
FROM orders
WHERE customer_id = {{customer_id}}
ORDER BY created_at DESC

​

Scoping data to the end user

• APIs — put {{claim.sub}} (or any claim you sign) in a header on the connection. Your endpoint receives it and filters, so your access rules stay in your backend. You can also pin a parameter: the assistant never sees it in the tool’s schema and the value is filled in from the verified identity over anything the assistant sends — so no prompt can move a request to another person’s data. Two things belong on your side for this to hold: read the identity only from that header (an endpoint that also trusts a customer_id parameter can be talked into the wrong answer), and authenticate CoreBase itself with an API key or mTLS — otherwise anyone who can reach the endpoint can claim to be anyone.
• Databases — turn on Scope rows to the end user and pick a setting name. Every statement then runs in a transaction that starts by applying the caller’s identity to that setting, so your own row-level security policies can read it:
  CREATE POLICY tenant_isolation ON orders
    USING (customer_ref = current_setting('app.end_user', true));
  

​

Choosing what an API exposes

• Offer every endpoint in the spec — off, the assistant sees only the endpoints you enabled and the custom tools you wrote. The same question a database’s Let the assistant write SQL switch asks: is this surface everything the system can do, or the part you chose?
• Allow free-form requests — off, the assistant can no longer pick its own method and path. Keep it on only for connections without a spec, where it’s the only way to act at all.

​

Approval before an action runs

​

Source scoping

​

Per-tenant isolation

• Each tenant’s data, annotations, memories, and connections are scoped by org_id and invisible across tenants.
• The application role runs without the ability to bypass RLS; isolation holds even if application code has a bug.
• The rare lookups that must span tenants (e.g. routing an incoming webhook to the right tenant) are handled through narrow, audited paths — never a broad bypass.

​

Audit

​

Secrets

• Database DSNs and provider keys are encrypted per tenant (AES-GCM, envelope-encrypted under a master key).
• CoreMCP keeps database credentials on your server — CoreBase never sees them.
• SaaS OAuth tokens live in the managed connector layer, not in CoreBase.
• Secrets, prompts, generated SQL, and result rows are never written to logs.

​

How the layers stack

​

Next