The Kimo Bridge security model

What leaves your network, and what never does?

Start with the inventory, because every other control exists to keep it true. The table describes a source in Bridge mode; a source in Cloud mode additionally syncs the tables you choose, through the same tunnel and under the same allow-lists.

One nuance matters for European teams: query results can contain personal data, and the EDPB considers remote access from a third country to data in the EEA a transfer in its own right.⁷Source 7 · European Data Protection Board, 2021Recommendations 01/2020 on measures that supplement transfer tools, version 2.0edpb.europa.eu The bridge minimizes what moves and records every movement; your policy decides whether results include personal data at all. The whitepaper Your Data, Your Rules covers the regulatory side in depth, and the glossary explains data residency.

Design principles

1. 1No implicit trust from location. NIST's zero trust architecture rejects trust granted to assets or accounts based solely on their physical or network location.¹Source 1 · National Institute of Standards and Technology, 2020SP 800-207: Zero Trust Architecturecsrc.nist.gov Being connected through the tunnel authorizes nothing by itself.
2. 2Deny by default. OWASP's first prevention measure for broken access control — the top category in its 2021 Top 10 — is to deny by default except for public resources.⁴Source 4 · OWASP Top 10, 2021A01:2021 – Broken Access Controltop10.owasp.org A new bridge can reach your database but answers nothing until you allow tables and columns.
3. 3The customer holds the keys. Credentials, private keys and policy live on your host. Kimo cannot widen access, and a compromise of Kimo cannot reveal your database password.
4. 4Defense in depth. The bridge's parser, the policy, the database role and database row-level security each block bad queries on their own.
5. 5Everything is attributable. Each query carries the identity of the Kimo user who caused it, from dashboard click to database log.

Identity and the tunnel

Enrollment

On first start, the bridge generates an asymmetric key pair on your host and sends Kimo a certificate signing request together with the enrollment token from the Bridge console. One-time tokens (kbt_) expire after 24 hours or one use; group tokens (kbg_) for Kubernetes enroll multiple replicas and can require human approval per new member. Kimo returns a client certificate bound to the bridge's key, workspace and group, valid for 24 hours and renewed automatically well before expiry. The private key never leaves the host.

Mutual TLS over TLS 1.3

The bridge opens one outbound connection to Kimo's regional endpoint on TCP 443 and negotiates TLS 1.3 only. TLS is designed to prevent eavesdropping, tampering and message forgery, and TLS 1.3 supports certificate-based client authentication through the server's CertificateRequest message.²Source 2 · IETF / RFC Editor, 2018RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3rfc-editor.org Both sides present certificates: the bridge verifies Kimo's endpoint against a CA bundle pinned in the image, and Kimo verifies the bridge's client certificate. RFC 8446 has since been obsoleted by RFC 9846, a backward-compatible revision that keeps the TLS 1.3 version number, so nothing changes for deployed bridges.³Source 3 · IETF / RFC Editor, 2026RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3rfc-editor.org

Why outbound-only matters

Because the bridge dials out, nothing listens for connections from the internet: no inbound firewall rule, no port forward, no public IP, no VPN account for a vendor. Your attack surface does not grow with the integration, and your egress policy can allow exactly one destination. The glossary entry on outbound-only tunnels compares this pattern with VPNs and IP allow-listing.

How is each query authorized?

Kimo compiles queries from your semantic layer, with filters and aggregations pushed down to the source. The bridge treats every one of them as untrusted input and runs it through the same pipeline:

1. 1
   Step 1:

   Verify the request signature

   Each request is signed by Kimo and carries workspace, user, source, a SHA-256 hash of the SQL, the expected policy version, a nonce and a 60-second expiry. The bridge verifies the signature against a key pinned at enrollment and rejects replays and expired requests.

2. 2
   Step 2:

   Parse, do not pattern-match

   The bridge parses the SQL with the source's dialect grammar. Only a single read statement is accepted. Stacked statements, DDL, DML, COPY, SET, locking clauses and calls to functions outside a read-only allow-list (for example set_config, pg_read_file, dblink) are rejected.

3. 3
   Step 3:

   Check every referenced table and column

   All table and column references, including those inside subqueries, CTEs and views, are resolved and checked against the allow-list. SELECT * is expanded before checking, so a newly added sensitive column is never silently included.

4. 4
   Step 4:

   Apply row filters and group sizes

   Row filters from the policy are injected using the requesting user's attributes (for example their regions). For grouped queries, groups smaller than min_group_size are suppressed.

5. 5
   Step 5:

   Enforce limits

   Per-source rate limits are applied before execution; row, byte and time caps during it. A query that exceeds a cap is cancelled and returns an error, never a silently truncated result.

6. 6
   Step 6:

   Execute with the read-only role and log

   The query runs in a read-only transaction under the bridge's database role. The decision, row count, bytes and duration are written to the audit log whether the query succeeded, failed or was denied.

1234567891011121314151617policy:
  default: deny
  functions: read_only          # built-in allow-list of side-effect-free functions
  tables:
    analytics.accounts:
      columns: [id, region, plan, mrr_cents, created_at, churned_at]
      row_filter: "region = ANY({{user.attributes.regions}})"
    analytics.tickets:
      columns: [id, account_id, priority, opened_at, closed_at]
  min_group_size: 5
  limits:
    max_rows: 50000
    max_bytes: 20MB
    timeout: 30s
    rate: 20/s
  alerts:
    denied_per_minute: 10       # alert when denials spike

Kimo reads a summary of this policy to hide disallowed fields from users before they ever build a query, but enforcement happens only on your host. If Kimo's summary and your file disagree, the file wins and the console flags the mismatch.

The database layer: read-only roles and row-level security

The bridge's role should be able to do nothing but read the schemas you intend — the setup is in the Docker guide. Where different users may see different rows, add database-native row-level security so that the database enforces the same rule as the bridge, independently.

PostgreSQL makes this straightforward with one caveat set. Once RLS is enabled on a table, a default-deny policy applies if no policy exists; superusers and roles with BYPASSRLS always bypass RLS, and table owners do too unless the table forces it.⁶Source 6 · PostgreSQL DocumentationRow Security Policiespostgresql.org The bridge role must therefore be none of those. The bridge passes the requesting user's attributes to the session in a transaction-local setting, which RLS policies can read:

123456789ALTER TABLE analytics.accounts ENABLE ROW LEVEL SECURITY;
ALTER TABLE analytics.accounts FORCE ROW LEVEL SECURITY;

-- The bridge sets kimo.user_regions with SET LOCAL inside each transaction.
-- The bridge's parser blocks set_config(), so queries cannot change it.
CREATE POLICY bridge_region_scope ON analytics.accounts
  FOR SELECT TO kimo_bridge
  USING (region = ANY (string_to_array(
    current_setting('kimo.user_regions', true), ',')));

With both layers in place, a mistake in the bridge policy file is caught by the database, and a mistake in the database grants is caught by the bridge. That redundancy is the point.

What does the audit log record?

Every request produces one JSON line in /var/lib/kimo-bridge/audit.jsonl (or on stdout in Kubernetes). The fields follow the when / where / who / what structure the OWASP Logging Cheat Sheet recommends, and deliberately exclude what it says not to log directly — access tokens, connection strings, keys and sensitive personal data.⁵Source 5 · OWASP Cheat Sheet SeriesLogging Cheat Sheetcheatsheetseries.owasp.org

12345678910111213141516171819{
  "ts": "2026-10-03T09:14:22.418Z",
  "event_id": "aud_01J9Z8M3Q4",
  "bridge": "fra-prod-01",
  "group": "prod-eu",
  "source": "crm_pg",
  "workspace": "ws_acme",
  "user": "usr_7f3a",
  "origin": "dashboard:board-deck/tile-4",
  "request_id": "req_5c21e0",
  "sql_sha256": "9b1f…e07a",
  "policy_version": "2026-09-30.3",
  "decision": "allow",
  "reason": null,
  "rows": 24,
  "bytes": 1832,
  "duration_ms": 212,
  "prev_hash": "c4d2…11b9"
}

• Tamper-evident. Each record includes the hash of the previous one, so a modified or deleted record breaks the chain. kimo-bridge audit verify checks it. OWASP recommends exactly this kind of tamper detection, plus copying logs to read-only storage quickly.⁵Source 5 · OWASP Cheat Sheet SeriesLogging Cheat Sheetcheatsheetseries.owasp.org
• Two copies. Records are mirrored to Kimo's Activity view for analysts, while the local file stays authoritative for your security team. Ship it to your SIEM with your usual agent.
• Denials are first-class. OWASP also advises logging access control failures and alerting on repeated ones.⁴Source 4 · OWASP Top 10, 2021A01:2021 – Broken Access Controltop10.owasp.org Denied requests are logged with a reason (column_not_allowed, rate_limited, signature_expired…) and the denied_per_minute alert fires on spikes.

How do you revoke access instantly?

Test the kill switch before you need it. A quarterly drill — pause, confirm dashboards show the source as unavailable, resume — takes five minutes and turns a theoretical control into a practiced one.

What if something is compromised?

A security model is only as good as its answers to bad days. The table organizes them by STRIDE category — spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege.⁸Source 8 · Microsoft LearnThreats — Microsoft Threat Modeling Tool (STRIDE model)learn.microsoft.com

Security review checklist

Ready to install? Follow Install Kimo Bridge with Docker for a single host or Deploy Kimo Bridge on Kubernetes for production clusters, or read the Kimo Bridge overview.