Security & TrustField Brief  Nº 003

Compliant autonomy. A human always holds the keys.

LiquidSilicon lets AI agents act on your business, and is engineered so a person stays in control of every consequential move. The Builder agent only ever writes proposals — it never applies a change on its own. When enabled, a Guardian scan reads each proposal for PII and prompt injection and can block critical and high-severity findings. You grant autonomy across five trust tiers and can revert to observe-only in one action. Every action is an append-only event you can replay, and each tenant’s data — including its AI keys — is walled off by forced Postgres row-level security. You bring your own model keys; they are encrypted under a dedicated key, and we never train on your data.

01 / CONTROL REGISTER

Six controls, one principle: no unsupervised action.

Every control below is implemented in shipped code
ControlWhat it doesGuarantee
Human approval gateC-01The Builder writes proposals only. Nothing consequential ships without a human yes.Dual control
Guardian proposal scanC-02When enabled, each proposal is scanned for PII, prompt injection, and out-of-scope actions; critical and high findings are blocked.Critical + high blocked
Graduated autonomyC-03Five trust tiers you set. Revert to observe-only in one action; emergency freeze halts all agents.Human override always
Append-only audit trailC-04Every action is an event, never an overwrite. Any past state is replayable, with full attribution.Event-sourced core
Tenant isolationC-05Postgres row-level security, enabled and forced on every tenant table — including AI keys and spend.Owner obeys policy too
Your keys, your dataC-06BYOK keys encrypted under a dedicated key with rotation. Your calls, your provider agreement.We never train on it
02 / HUMAN GATES BY DESIGN

The AI proposes. A person disposes.

Nothing ships without a human yes.

The Builder agent — the only agent that can author a change to your system — never applies anything directly. It emits an implementation plan for human review. This is a dual-control model: an agent can write a proposal, but a person is the one who ships it.

The Builder runs only against work a human has already approved to the ready stage, and its output is put through a sandbox validation step before it is even offered for review. Autonomous runs are off by default (BUILDER_AUTO_ENABLED=false).

  • Proposals only. The Builder writes plans, not live changes.
  • Human-approved input. It acts only on features a person moved to ready.
  • Off by default. Automatic execution is opt-in per deployment.
AGENTPROPOSALOUTPUTSHIPSHUMANGATEPROPOSEAPPROVE ✓REJECT · SENT BACKNOTHING SHIPS WITHOUT A HUMAN YES
Fig. 1The approval circuit. An agent proposal meets a human gate: approve to ship (and log an event), or reject and send it back.
03 / GUARDIAN SCAN

When enabled, every proposal is read before it is applied.

GUARDIANPRE-DEPLOY SCANPROPOSALS →PASSPASSPIIHALTEDPASSPASSVETO BEFORE DEPLOY
Fig. 2When enabled, Guardian scans each proposal. Four sheets pass; one is halted on a PII flag.

Detection is deterministic first — regex patterns, no AI in the loop — so PII and injection checks are reliable and repeatable. Only the deeper categories escalate to AI analysis.

What Guardian reads on every proposal
LayerDetectsAction
PII exposureSSN, email, phone, credit card, provider API keys (AWS / Stripe / GitHub / OpenAI / Anthropic), private-key blocks, connection strings, hard-coded passwordsCritical → block
Prompt injection“Ignore previous instructions”, jailbreak / DAN patterns, safety-filter override attempts, role-reassignmentFlag + block
Permission boundaryAn agent referencing entities or actions outside its declared scope, or proposing above its impact ceiling (Builder cannot self-classify critical)Scope violation → block
Deeper categoriesCompliance violations, security vulnerabilities, data exfiltration — escalated to AI analysis where regex alone is insufficientSeverity-scored

Findings at critical or high severity block the source outright; lower-severity findings annotate but let the work continue. Each agent also carries a permission boundary that caps the entities it may touch and the maximum impact it may propose.

04 / GRADUATED AUTONOMY

You set the temperature — and you can cool it instantly.

OBSERVE00SUGGEST01AUTOMATE02EXPAND03REPLACE04CURRENTCOOL · OBSERVE-ONLYHOT · FULL AUTONOMY
Fig. 3Autonomy as a temperature gauge: observe → suggest → automate → expand → replace. The needle sits at the tier you have granted; you can pull it back at any time.

Autonomy is not a switch, it is a dial. Agents start at tier 0 (observe) and earn each higher tier by getting the last one right. You raise the dial one step at a time, and you own the direction of travel in both directions.

Human override is always available. Revert to observe-only in a single action — no redeploy, no downtime. An emergency freeze drops a tenant straight to tier 0 and halts every agent action at once, logging the demotion as it goes.

  • Tier 0 default. New tenants observe only — nothing acts.
  • One-action revert. Pull autonomy back to observe with no downtime.
  • Emergency freeze. Instantly halt all agents and drop to tier 0.
  • Human rating weight. Your feedback overrides part of an agent’s earned score.
05 / AUDIT TRAIL

Every action is an event you can replay.

APPEND-ONLY EVENT LOG← LATESTE1E2E3E4E5E6E7REBUILDPROJECTION · ORDERSPROJECTION · REVENUEREPLAY FROM ANY POINT
Fig. 4The append-only event log. The whole log folds down to rebuild projections, and a replay arc reconstructs any past state from it.

Event-sourced, not overwritten.

The core is append-only. An action is never an in-place edit — it is a new event on the log. That means any past state of your operation can be replayed and reconstructed, and nothing about how your software got here is a mystery.

Every Builder run — start, plan approved, plan blocked, completed, failed — is written to the events table with full attribution. The audit trail is not a bolt-on log; it is the same event stream the platform is built on.

06 / TENANT ISOLATION

Your data is walled off at the database, not just the app.

Tenant separation is enforced in PostgreSQL itself with row-level security, so even a bug in application code cannot leak one tenant’s data to another. Every request sets app.current_tenant_id, and RLS policies filter every read and write against it.

RLS is not only enabled but forced — so the table owner role is subject to the same policies, closing the usual owner-bypass gap. It covers every tenant-scoped table, explicitly including the two most sensitive: tenant_ai_config (your encrypted AI keys) and ai_spend_ledger (your spend records).

  • Enabled + FORCED. Even the table owner obeys the tenant policy.
  • Every tenant table. Events, insights, trust state, keys, spend, users.
  • Defense in depth. A app-layer bug still cannot cross the tenant boundary.
07 / YOUR KEYS, YOUR DATA

Bring your own model keys. We guard them; we don’t train on you.

LiquidSilicon is BYOK-first: you connect your own AI provider keys. Practically, that means your agent calls run under your agreement with the provider — your data flows on your terms, and we never train on tenant data.

The keys themselves are the crown jewels, so they get crown-jewel handling: encrypted at rest under a dedicated encryption key, held separately from the session secret, and versioned so the key material can be rotated without a disruptive migration.

  • Cipher. AES-256-GCM authenticated encryption (envelope: IV + tag + ciphertext).
  • Key. A dedicated 32-byte BYOK_ENCRYPTION_KEY, separate from the app session secret.
  • Rotation. Ciphertext is versioned (v2: prefix) so keys rotate without a flag-day migration.
  • At rest. Keys live in tenant_ai_config, itself under forced row-level security (C-05).
  • In use. Calls run under your provider agreement. We never train on your data.
08 / STANDARDS ALIGNMENT

How our controls map to the frameworks.

We are candid about what is certified and what is not. Below is where each control we already ship maps to the frameworks that matter for agentic AI — stated as a mapping, not a claim of certification.

Our control → framework item
Our controlFrameworkItem it addressesStatus
Human approval gate + graduated trust tiersNIST AI RMFHuman oversight / “Govern” + “Manage”; TRAIGA safe-harbor relevanceDesigned to align
Human approval gate (no unsupervised action)OWASP Agentic Top 10ASI01 — goal hijacking & excessive agencyMitigation mapped
Guardian PII + prompt-injection scanningOWASP Agentic Top 10Prompt injection / instruction manipulationMitigation mapped
Forced RLS + per-agent permission boundariesOWASP Agentic Top 10ASI03 — privilege abuse & isolation failureMitigation mapped
Append-only event log with attributionOWASP Agentic Top 10Chain-of-custody / traceability of agent actionsMitigation mapped
Organizational controls & audit readinessSOC 2 Type IISecurity / availability / confidentiality criteriaIn preparation

Plainly stated: LiquidSilicon is not SOC 2 certified today — a SOC 2 Type II is in preparation. “Designed to align with NIST AI RMF” and “mitigation mapped to the OWASP Agentic Top 10” describe engineering intent and control coverage, not an audit, a certification, insurance, or a compliance attestation, and should not be read as any of those. For the EU AI Act, the platform is transparency-ready: interactions with an AI agent are disclosed as AI. We will update this page as formal attestations are completed.

09 / RESPONSIBLE DISCLOSURE

Found something? Tell us first.

We welcome reports from security researchers. Email us with details and steps to reproduce, and give us a reasonable window to remediate before any public disclosure. We will acknowledge your report and keep you updated.

security@liquidsilicon.ai