[REDACTED]<\/code> and send the rest. That one looks safe and fails quietly, because once every client is [REDACTED]<\/code>, the assistant can no longer tell one client from another because it is like joining two tables without a key. It answers, but without being relevant enough.<\/p>\n\n\n\nI built the layer in between, on PostgreSQL: row-level security, labels, the token columns and audit live in the database, the tokenizing and the gate in the application, the key and the mapping on a second server. Here is what it does, on a question from the lab (condensed from the run’s output):<\/p>\n\n\n
\nquestion asked : What did Emmental Immobilien AG complain about regarding custody fees?\nquestion sent : What did CLIENT_43aa5d8366b5 complain about regarding custody fees?\nmodel answer : CLIENT_43aa5d8366b5 complained that the custody fees had increased without notice. [doc 10]\nfor a reviewer : Emmental Immobilien AG complained that the custody fees had increased without notice. [doc 10]\n\n<\/pre><\/div>\n\n\nThe model chose its own search, kept the token, answered correctly and cited its source. It never held the name. This is pseudonymization, not anonymization: the tokens are reversible by design (for everything downstream of the filter, only through a separate server), and the text around a token can still say a lot about someone. The goal is narrower and testable: no known sensitive value reaches the provider, and the answers stay as relevant as on raw text.<\/p>\n\n\n\n
In my lab I take the example of a bank, because in Switzerland, sending client data covered by banking secrecy to an external API is a disclosure question under Article 47 of the Banking Act before it is a quality question, and FINMA expects banks to manage the data risks and third-party dependencies that come with AI. So the question is: can we build something secure enough to still use agentic capabilities? If it works in a sector as regulated as banking, most organizations can use it too. Retrieval techniques make governance possible; the other question is how far they go.
The lab has three synthetic banks, 240 clients, 18 relationship managers, 481 accounts, 30 servers and 1,521 free-text documents. It is small on purpose: big enough to measure, small enough to rebuild on a laptop and read every row. Every name in it is generated; where a generated company name turned out to match a firm in the Swiss commercial register, the generator swaps it, and any remaining resemblance is coincidental. This post walks through the data model, the vault that holds the tokens, the layers between the data and the model, a deliberate labelling gap and what catches it, the relevance measured with and without filtering, what a tracing tool ends up storing, and the query plans underneath.<\/p>\n\n\n\n
The interesting part is not hiding the names. It is knowing precisely which data is sensitive: the labels are what stop the leak, the same labels are what give the relevance back, and a name that no label knows is exactly where the guarantee ends.<\/p>\n\n\n\n
This demonstrates:<\/p>\n\n\n\n
\n- Row-level security on the vectors, not only on the documents, with the tenant set per transaction.<\/li>\n\n\n\n
- A label registry and a coverage query that fails toward a finding when a sensitive column is missing.<\/li>\n\n\n\n
- Deterministic tokens computed with a keyed hash on a separate PostgreSQL server, which is the only way back for everything downstream of the filter.<\/li>\n\n\n\n
- An egress gate that scans every request to the model, logs a hash of it, and blocks on a single finding.<\/li>\n\n\n\n
- Relevance kept: with the same search and the same tools, answers on tokens are as good as answers on raw text.<\/li>\n<\/ul>\n\n\n\n
Lab Environment Details<\/strong>
Bank server: <\/strong>
PostgreSQL 18.3, pgvector 0.8.6, pgAudit 18.0, postgresql_anonymizer 3.2.2.
Vault server:<\/strong>
PostgreSQL 18.3 with pgcrypto.
Embeddings computed locally on CPU: <\/strong>
dense voyage-4-nano at 1,024 dimensions, sparse SPLADE (prithivida\/Splade_PP_en_v1<\/code>) through fastembed.
Agent<\/strong>:
OpenAI gpt-6-luna<\/code> through Chat Completions with function tools.
Tracing:<\/strong>
Langfuse 4.50 self-hosted from its official Docker Compose file (ClickHouse 25.12, PostgreSQL 17, Redis 7, MinIO), Python SDK 4.16. All in Docker on WSL2, in a 6 GB VM. <\/p>\n\n\n\nThe lab is public and available with a runbook that replays every output below: lab 16 in pgvector_RAG_search_lab<\/a>.
Building it takes about 40 minutes of embeddings on a CPU, and replaying every step about an hour and a half; the dry runs need no API key.<\/p>\n\n\n\nThe data model<\/h2>\n\n\n\n
Two servers, three schemas. The bank server holds the business data, its filtered copies and the governance tables. The vault server holds only the key and the token mapping. No foreign key, foreign server or dblink<\/code> crosses between them.<\/p>\n\n\n\n![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/10\/01-schema-bank-1024x831.png\")
<\/figure>\n\n\n\nThe bank schema: business data, its filtered copies, the mention index and the versioned embeddings. Each sensitive structured column sits next to its token column; the free text has redacted and tokenized copies (title copies omitted here).<\/em><\/p>\n\n\n\nEach document is stored three times, raw, redacted and tokenized. That is not how you would run production; it is how you measure what each choice costs, on the same rows, with the same model:<\/p>\n\n\n
\nCREATE TABLE bank.documents (\n doc_id int PRIMARY KEY,\n bank_id text NOT NULL REFERENCES bank.banks,\n doc_type text NOT NULL CHECK (doc_type IN ('advisor_note', 'incident', 'email')),\n title text NOT NULL,\n body text NOT NULL,\n created_at timestamptz NOT NULL,\n title_redacted text,\n body_redacted text,\n title_tokenized text,\n body_tokenized text,\n key_version int\n);\n\n<\/pre><\/div>\n\n\nEmbeddings are versioned: every row says which model, which text state and which vault key produced it. Why that matters, and the event-driven pipeline that keeps vectors current, is the subject of my embedding versioning post<\/a> and its lab<\/a>. A partial unique index allows at most one active version per state, so a new set can be built next to the old one and switched when it is ready:<\/p>\n\n\n\nCREATE UNIQUE INDEX embedding_versions_one_active ON bank.embedding_versions (state) WHERE is_active;\n\n-- shortened: the repository version adds a hash of the embedded text\nCREATE TABLE bank.embeddings (\n version_id int NOT NULL REFERENCES bank.embedding_versions,\n doc_id int NOT NULL REFERENCES bank.documents,\n bank_id text NOT NULL,\n dense vector(1024) NOT NULL,\n sparse sparsevec(30522) NOT NULL,\n PRIMARY KEY (version_id, doc_id)\n);\nCREATE INDEX embeddings_dense_hnsw ON bank.embeddings USING hnsw (dense vector_cosine_ops);\nCREATE INDEX ON bank.embeddings (version_id, bank_id);\n\n<\/pre><\/div>\n\n\nThe bank_id<\/code> on embeddings<\/code> is deliberate. The vector table is the one people forget to protect: it gets the same tenant column, and the same row-level security policy, as the documents.<\/p>\n\n\n\nThe governance schema gov<\/code> is plain tables. A registry says which column is sensitive and where its token goes, and an egress log records every request that leaves, with a hash and the size of the payload and what the scanner found, never the payload itself. The gateway may read the log, insert into it and set each request’s outcome, nothing else:<\/p>\n\n\n\nCREATE TABLE gov.sensitive_columns (\n table_name text NOT NULL,\n column_name text NOT NULL,\n category text NOT NULL, -- CLIENT, PERSON, EMAIL, IBAN, HOST, IP, FREE_TEXT\n token_column text, -- where the deterministic token is written\n PRIMARY KEY (table_name, column_name)\n);\n\nGRANT SELECT, INSERT ON gov.egress_log TO gateway;\nGRANT UPDATE (outcome) ON gov.egress_log TO gateway; -- the rest of the log is append-only\n\n<\/pre><\/div>\n\n\nThe vault, which everything else depends on<\/h2>\n\n\n\n
The key, and the mapping from a token back to its value, are what turn a token into a name. Anyone who only ever sees tokens (the model, the agent’s role, a tracing store) has no other way back, and a reviewer gets names only through it, so they live on a second PostgreSQL server, with its own roles and credentials, and no postgres_fdw<\/code> or dblink<\/code> on the bank side. The two containers also sit on separate Docker networks. On one laptop that is as far as it goes: the bank’s superuser can run programs on its server, and the vault’s port is still reachable through the Docker host. In production the vault belongs on its own host, behind a firewall that only lets the gateway in.<\/p>\n\n\n\nOne honest limit of this lab’s layout: the bank tables keep each token next to its raw value (client_token<\/code> beside client_name<\/code>), because the pipeline needs both to filter the text. So the pipeline role and the bank’s administrators can map tokens back without the vault; what keeps the agent out is column privileges, below. One more route stays open in the lab: the agent’s role can read the raw-text embeddings kept for the measurement, and a sparse vector is indexed by words, so it partly exposes the words it was built from, names included. A stricter design moves the token columns out of the raw tables.<\/p>\n\n\n\n![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/10\/03-schema-vault-1024x766.png\")
<\/figure>\n\n\n\nThe vault server holds only the key and the token mapping. tokenizer<\/code> can compute tokens but read neither table; reidentifier<\/code> reads the mapping, never the key (the vault’s admin, a superuser in the lab, reads both).<\/em><\/p>\n\n\n\nNobody reads the key, not even the role that creates tokens. Tokens are computed inside the vault by a SECURITY DEFINER<\/code> function, which runs with its owner’s rights (in the lab the owner is the vault’s admin, a superuser, which a production setup would replace with a dedicated non-superuser owner), with a pinned search_path<\/code>:<\/p>\n\n\n\n-- shortened: the repository version also raises when no key is active\nCREATE FUNCTION vault.tokenize(p_category text, p_values text[])\nRETURNS TABLE (value text, token text)\nLANGUAGE plpgsql SECURITY DEFINER SET search_path = vault, public, pg_temp\nAS $$\n#variable_conflict use_column\nDECLARE\n k bytea;\n kv int;\nBEGIN\n SELECT secret, key_version INTO k, kv FROM vault.keys WHERE active;\n RETURN QUERY\n WITH src AS (\n SELECT DISTINCT v AS value FROM unnest(p_values) AS v WHERE v IS NOT NULL\n ), tok AS (\n SELECT s.value,\n upper(p_category) || '_' ||\n substr(encode(hmac(convert_to(upper(p_category) || ':' || lower(btrim(s.value)), 'UTF8'),\n k, 'sha256'), 'hex'), 1, 12) AS token\n FROM src s\n ), ins AS (\n INSERT INTO vault.mapping (token, key_version, category, value)\n SELECT DISTINCT ON (t.token) t.token, kv, upper(p_category), t.value\n FROM tok t ORDER BY t.token, t.value COLLATE "C"\n ON CONFLICT DO NOTHING\n )\n SELECT t.value, t.token FROM tok t;\nEND;\n$$;\n\n<\/pre><\/div>\n\n\nFunctions are executable by PUBLIC<\/code> by default, so the vault script revokes that before granting anything, and the public<\/code> schema in that search_path<\/code> is not writable by either role (the default since PostgreSQL 15, and revoked explicitly in the script):<\/p>\n\n\n\nREVOKE ALL ON ALL TABLES IN SCHEMA vault FROM PUBLIC;\nREVOKE ALL ON ALL FUNCTIONS IN SCHEMA vault FROM PUBLIC;\nGRANT USAGE ON SCHEMA vault TO tokenizer, reidentifier;\nGRANT EXECUTE ON FUNCTION vault.tokenize(text, text[]), vault.active_key_version() TO tokenizer;\nGRANT SELECT ON vault.mapping TO reidentifier;\nGRANT EXECUTE ON FUNCTION vault.active_key_version() TO reidentifier;\n\n<\/pre><\/div>\n\n\nFrom the run, by role:<\/p>\n\n\n
\ntokenizer: SELECT * FROM vault.keys;\n ERROR: permission denied for table keys\ntokenizer: SELECT * FROM vault.tokenize('client', ARRAY['Brenta Kontor AG', 'brenta kontor ag ']);\n value | token\n -------------------+---------------------\n brenta kontor ag | CLIENT_7119873645a3\n Brenta Kontor AG | CLIENT_7119873645a3\nreidentifier: SELECT * FROM vault.keys;\n ERROR: permission denied for table keys\n\n<\/pre><\/div>\n\n\nThree things the token is, and one it is not. It is the category plus the first 12 hex characters of an HMAC-SHA256 of the normalized value, a keyed hash nobody can reproduce without the key; whoever holds the tokenizer credential can still submit a guess and compare tokens (and the guess lands in the mapping), which is why that credential stays with the gateway. It is 48 bits, so by the birthday bound a collision within one category becomes a 1% risk around 2.4 million values; the largest category here has 481. And this version does not detect a collision: ON CONFLICT DO NOTHING<\/code> would skip it silently, where a production version should raise.<\/p>\n\n\n\nWhat it is not is entity resolution. The hash input is category and normalized string, with no tenant and no entity ID, so two different clients with the same name would share a token, and the same name in two banks gets the same token. The synthetic data has no such pair, which is why the results below are not affected, but a real CRM has them. A production version would tokenize a tenant-scoped canonical ID, and map aliases to it explicitly. The lab does that in one place only: a server’s hostname and its full domain name share one token.<\/p>\n\n\n\n
hostname | fqdn | host_token | fqdn_token\n----------------+-------------------------------+-------------------+-------------------\n alb-pg-prd-01 | alb-pg-prd-01.alder.internal | HOST_f774b8916acd | HOST_f774b8916acd\n<\/code><\/pre>\n\n\n\nArchitecture: two servers, one way in<\/h2>\n\n\n\n
![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/10\/06-governance-layers-1024x379.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/10\/05-question-sequence-1024x725.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/10\/04-build-flow-386x1024.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/10\/Screenshot-2026-10-02-221406-1024x459.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/10\/image-16-1024x968.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2026\/10\/Screenshot-2026-10-02-221624-1024x969.png\")
<\/figure>\n\n\n\n