Start a conversation →
KATEMBA · ASSURANCE NOTES REF. KTB-SR-01

Architecture notes for a sceptical reviewer.

How tenant isolation, governance, audit and self-hosting are actually implemented, not asserted.

This page is written to be useful to a security reviewer or a procurement officer reading on their own. It deliberately avoids marketing language. If you came here from the home page, this is the page that explains the claims made there.

1 “How do you guarantee that one customer’s data can never be seen by another?”

Tenant isolation, enforced below the application

The mechanism. Multi-tenancy is enforced by PostgreSQL row-level security (RLS), applied table by table. Every row in every tenant-scoped table carries a tenant identifier. Every database connection asserts a tenant context. The database refuses queries that try to read across tenants, regardless of what the application code is trying to do.

Why this matters. The dominant failure mode in multi-tenant software is an application-layer bug: a missed where tenant_id = ? clause, an over-permissive cache key, a forgotten check in a new endpoint. RLS takes that class of bug out of application code entirely: even a buggy query can’t return data outside its tenant context, because the database filters it before the application sees a single row.

psql · cross-tenant access attempt
tenant_a select count(*) from credit_memos;
count: 142 ALLOW · own tenant context
tenant_b select * from credit_memos where tenant_id = 'tenant_a';
(0 rows) DENY · 0 rows, filtered by the database
fig. 1: the same query class, two tenant contexts. Row-level security answers before the application can make a mistake. Illustrative session; the real report is regenerated live during your review.

The evidence. The platform ships with a cross-tenant test suite that runs in CI on every change. For every tenant-scoped table, it attempts cross-tenant access from a different tenant’s context and asserts that the access is denied. The suite produces a structured report. No release ships if the suite is failing.

What we hand to procurement. A current cross-tenant isolation report, generated on demand against your environment. It lists every tenant-scoped table and the result of an actual cross-tenant access attempt against each.

2 “Where does our data go?”

It runs where you do

The mechanism. Self-hosting is the default deployment model. The application, the database, the audit log and the AI gateway run inside your cloud account or on-premises environment. Outbound calls to model providers (Anthropic, Azure OpenAI, Google Vertex, and others) are configurable and auditable; in environments where they are not acceptable, the AI gateway can be configured to use only models running inside your environment.

Where it sits in the stack. Most clients run it inside their own hyperscaler account (Azure, AWS, GCP) on managed services. The architecture is cloud-agnostic; deployment patterns for each hyperscaler are documented.

For high-sensitivity clients. Deploy a dedicated instance per high-sensitivity tenant. The platform’s multi-tenancy is the default; single-tenant deployments are a configuration choice, not a fork.

What we hand to procurement. A deployment architecture document specific to your environment, with data flow diagrams, the list of network egress endpoints, and the data residency assertion mapped to your relevant regulation.

3 “Can we tell, after the fact, what happened and why?”

Everything significant is logged

The mechanism. Every significant action - user action, AI invocation, configuration change, persona promotion, data access - is written to an append-only audit trail. Every entry is attributed: who or what initiated the action, in which tenant context, against which records, using which model and persona version.

AI usage attribution. Every AI call records the persona version, the model version, the prompt as evaluated, the response, the tool calls made, the user and the tenant context. Cost and latency telemetry are captured per call.

Retention and access. Audit retention is configurable to your regulatory requirements. Access to the audit trail is itself audited. Export to your SIEM is supported.

What we hand to procurement. An audit-trail design document: what is logged, where it is stored, how it is protected, how long it is retained, and how it can be exported.

4 “How do you know what the AI is doing, and how it changes?”

Governed models, not loose prompts

The mechanism. Every AI persona is authored, versioned, evaluated and served through Persona Factory. Each persona version carries:

  • An explicit definition of allowed behaviour and boundaries.
  • An evaluation set with representative cases and expected behaviour.
  • A grading result for every version against that evaluation set.
  • Governance metadata: what data the persona can see, what tools it can call, who can promote it to production.

Promotion gates. A new persona version is not available in production until it has passed the evaluation set. Model upgrades re-run the evaluation set on every persona before they are accepted.

Configuration history. The audit trail records every persona promotion, every model swap, every governance metadata change. “What was live on 14 March?” is a query.

What we hand to procurement. A persona-governance design document and, on request, a current evaluation report against a sample of production personas.

5 “What happens if we don’t want to be a Katemba client any more?”

You can leave

The mechanism. You already have everything that would make leaving possible.

  • The source code is in your repository. Application code, infrastructure-as-code, platform components.
  • The data is in your environment. Database, object storage, audit trail: all under your control.
  • The architecture is documented. Including the patterns specific to the platform, so an independent team can pick it up.

There is no captive SaaS to leave, no proprietary runtime to re-implement, and no data export ceremony required. The leaving posture is the same as the running posture. That’s intentional.

The mechanisms above exist to make someone else’s job easier.

Where this lands in your frameworks

  • UK GDPR and your DPIA. Data residency, per-tenant isolation and the audit trail give your DPO the processing map a DPIA needs: where data lives, who can reach it, and what touched it.
  • Operational resilience and exit planning. For FCA/PRA-regulated firms: self-hosted deployment, source-code handover and the documented leaving posture are written to slot into an exit plan, not to resist one.
  • Model risk and record-keeping. Versioned personas, evaluation gates and per-call logging answer “what model, what behaviour, what output, when”, the question model-risk and AI-governance frameworks keep asking.
  • Your security questionnaire. The five sections above are ordered the way the questions usually arrive. Send us the questionnaire and we’ll answer it in your format.
A small firm earns trust by being precise about what is real and what is in flight.

What we don’t claim

  • We do not claim formal certifications we do not hold, and we clearly mark anything in progress as in progress.
  • The cross-tenant isolation test suite is a piece of platform engineering; it is not an external attestation. We treat it as evidence to be reviewed alongside, not in place of, a formal third-party assessment.
  • Evaluation sets are as good as the cases in them. We design them with domain owners and extend them as the work evolves. Passing the evaluation suite is evidence that behaviour has not changed unexpectedly, not proof the AI is “correct” in any absolute sense.
If you’re a security reviewer, the answer to each is yes.

What to ask us next

  • Can we see a sample cross-tenant isolation report?
  • Can we see the audit-trail design for an in-flight engagement?
  • Can we see a sample persona-governance document?
  • Can we run our own threat model against a representative deployment?

Tell us the audience for the evidence and we’ll get the right people on the call.