Governance

What stops an assistant from binding a risk

Three independent controls in the database. Each one alone would stop it, and none of them can be bypassed by the assistants or by us.

Enforced in: PostgreSQL
Independent controls: Three
Tested: On every build

Why the database

Rules that do not depend on our code

Policies, reviews and training fail quietly. You find out a step was skipped after something goes wrong.

Slipstream’s controls sit beneath the application. They do not depend on our code, a prompt or a model behaving. An assistant that tried to finalize a term would be refused by Postgres.

The controls

Three controls, each enough on its own

1 · Insert trigger

Every draft is stored as pending

A BEFORE INSERT trigger on slip_proposals forces the status to proposed and clears the decision fields.

It runs for every caller, including the service role the assistants use. A draft that asks to arrive approved is stored as pending anyway.

supabase/schema.sql · insert trigger

create or replace function slip_proposals_force_pending()
returns trigger
language plpgsql
set search_path = pg_temp
as $$
begin
  new.status     := 'proposed';
  new.decided_by := null;
  new.decided_at := null;
  return new;
end;
$$;

create trigger slip_proposals_force_pending_trg
  before insert on slip_proposals
  for each row
  execute function slip_proposals_force_pending();

2 · Withheld privilege

Nobody holds the update grant

No role has UPDATE on slip_proposals: not the assistants, not a signed-in user, not an administrator.

This is a privilege, not a runtime check. Without the grant, Postgres refuses the statement before it runs.

supabase/schema.sql · grant layer

-- Strip Supabase's defaults from both roles first,
-- then grant back exactly what is wanted.
revoke all on slip_proposals
  from anon, authenticated;

grant select, insert on slip_proposals
  to authenticated;

-- Deliberately absent: UPDATE, DELETE.

3 · Gated function

One way out, and it checks who is asking

A single SECURITY DEFINER function is the only path out of pending. It refuses anyone not signed in, and anyone outside the firm the term was drafted for.

A counterparty cannot approve on your behalf. The decision and its audit row are written in one transaction.

decide_slip_proposal · the only exit

create or replace function decide_slip_proposal(
  p_proposal_id uuid,
  p_decision    text,
  p_value       jsonb
)
returns slip_proposals
language plpgsql
security definer
set search_path = public, pg_temp
as $$
begin
  if v_uid is null then
    raise exception 'not authenticated';
  end if;

  if v_org <> v_prop.proposer_org_id then
    raise exception
      'only a member of the proposing organization '
      'can decide this proposal';
  end if;

  -- Decision and audit row, one transaction.
end;
$$;

The audit trail

Append-only, for every role

Every state change writes one row: the actor, person or assistant, their firm, and a hash chained to the row before.

Update and delete are refused by trigger, so the service role the assistants use is refused too. A placement cannot be deleted either, because the delete would reach the trail.

audit_events · immutability

create trigger audit_events_no_update_trg
  before update on audit_events
  for each row execute function audit_events_immutable();

create trigger audit_events_no_delete_trg
  before delete on audit_events
  for each row execute function audit_events_immutable();

-- Triggers rather than policies: the service role
-- the assistants use bypasses row-level security.

Limits

What these controls do not cover

They do not make drafts correct

A draft can still be wrong. The controls stop it becoming binding without a person.

They do not replace your own controls

Delegated authority and referral limits live in your firm. Slipstream records who decided.

They do not govern the model provider

That is contractual. Anthropic’s paid API does not train on prompts, and each submission records which model read it.

Deletion is not available

The trail and the placement cannot be deleted. Redaction would be a design change, not a setting.

Questions

From security and compliance reviewers

Does the AI know our underwriting rules?: No. The assistants work from the submission and general market language. Your underwriters remain the authority on appetite and referral limits.
Where does our data sit?: In the United States: Supabase on AWS us-east-1, Vercel, Liveblocks and Anthropic. The full list is on the security page.
Can one firm see another firm’s placement?: No. Access is granted per placement. A placement you were not invited to returns nothing, as if it did not exist.
What if the application has a bug?: The controls sit below the application. A bug or a bad prompt still cannot move a draft out of pending without a signed-in person at the right firm.
How can we verify this?: Ask for a walkthrough and we will run the statements against a live database in front of you. Each control is also tested on every build.
Can we get our data out?: Yes. Either firm can export a placement as one self-contained HTML file with every term, quote, document hash and audit event.
Is Slipstream SOC 2 certified?: No. SOC 2 Type II is planned before general availability. No audit has started.

Ask a question Design partner program