Secure DB Audit Gateway — by System Access

Let them into production. Keep proof of every row they saw.

GLEJT is a security gateway for read-only access to production databases. SQL specialists and external vendors investigate incidents; GLEJT enforces SELECT-only, time-boxes every grant to a real ticket — and records exactly what each person saw, in an audit nobody can rewrite.

Request a demo Explore the features
  • Self-hosted, no agents
  • SELECT-only, enforced twice
  • Fail-closed audit
https://glejt.internal G GLEJT GATEWAY Secure DB Audit Gateway AK analyst MY SESSIONS ALLOCATED CONNECTIONS billing-core PROD PostgreSQL pg-prod-eu1:5432 / billing INC-1234 ⏳ 02:14:37 OPEN ► orders-analytics UAT Oracle ora-uat-eu2:1521 / orders CHG-0552 ⏳ 3d 04:12 OPEN ► LIVE AUDIT STREAM 14:02:11 PAGE_VIEWED analyst@corp billing-core page 3 · 20 rows captured 14:01:47 DENIED vendor@ext billing-core UPDATE customers SET … 14:00:03 ANOMALY vendor@ext off-hours access · volume ×12 Hash chain intact — 12,340 events verified head #a41f…9c02
Every connection badged UAT/PROD, with a live expiry countdown.

Three questions security teams can't answer today

“What did the vendor actually see?”

GLEJT stores the values of every result page viewed — replayable step by step.

“Could our audit log be rewritten?”

Not undetectably: append-only WORM storage, hash-chained, verified in one click.

“Who still has access from last quarter?”

Nobody. Access is bound to a ticket and a time window — it expires by itself.

0% of viewed result pages captured in the audit
0× read-only enforcement — SQL parser + DB session
0 database engines — PostgreSQL · MySQL/MariaDB · Oracle · MSSQL
0 UI languages — EN · DE · ES · SK · HU

How it works

From request to proof in four steps

GLEJT sits as a proxy in front of your databases. No agents, no schema changes — credentials never leave the gateway.

  1. 01

    Connect

    An admin registers a database connection. Credentials are envelope-encrypted with AES-256-GCM; the master key lives outside the database.

  2. 02

    Grant

    Access exists only as an allocation: user + connection + open ticket + expiry. Tickets are validated live in Jira or ServiceNow — fail-closed.

  3. 03

    Query

    Only SELECT statements pass — enforced by SQL parsing and again by a read-only DB session. Results are paged; every viewed page is captured with its values.

  4. 04

    Prove

    Replay any session as a timeline and export an Ed25519-signed evidence pack (PDF + JSON) that verifies offline — without trusting GLEJT, or us.

Capabilities

What makes GLEJT different

Not another SQL client — a control plane for the riskiest access you grant.

Worksheet — billing-core · PROD UPDATE customers SET credit_limit = 99999 WHERE id = 4711; DENIED ✕ → blocked by policy (not a SELECT) · recorded as audit event #12341 SELECT id, status, total FROM orders WHERE created_at > now() - interval '1 day'; OK ✓ id status total 10412 PAID 129.90 10413 PENDING 54.00 10414 PAID 310.25 1 · SQL AST allowlist sqlglot parse — SELECT or nothing 2 · Read-only DB session read-only account & transaction
UPDATE refused and recorded — the SELECT passes.

Read-only gateway

Nothing changes in production. Ever.

DDL, DML, multi-statements and procedure calls are hard-blocked — twice, independently. Every refused statement is recorded as DENIED, so an “accident” becomes evidence.

  • SELECT-only allowlist on the SQL syntax tree
  • Second line: read-only database account and transaction
  • Blocked attempts land in the audit, not in your data
RESULT — PAGE 3 OF 12 customer city total Weiss GmbH Wien 420.00 Nagy Kft. Budapest 118.50 Ferro s.r.o. Bratislava 902.10 Lopez S.L. Madrid 77.90 ‹ page 3 / 12 › PAGE_VIEWED · page 2 20 rows · sha256 ✓ chained PAGE_VIEWED · page 3 20 rows · values captured WORM audit ledger append-only · UPDATE/DELETE blocked by trigger · hash-chained
Page-by-page capture: the audit holds the values, not just the query.

Row-level capture

“Who saw what” stops being a guess.

Query logs tell you what was asked. GLEJT records what was answered: the exact rows of every page each user opened, bound to their session.

  • Server-side paging — viewing page 3 means exactly those rows
  • Exposure becomes measurable, not “probably the whole table”
  • Session replay rebuilds the timeline with an integrity verdict
NEW ALLOCATION VX vendor@external.io role: External · SSO via Entra ID → billing-core PROD INC-1234 ✓ validated live in Jira · open · assigned until Fri 18:00 FOUR-EYES APPROVAL · 2 OF 2 sec-lead@corp approved · 13:58 dba-oncall@corp approved · 14:00 · SoD check ✓ 🚨 BREAK-GLASS · emergency access immediate, short-lived allocation · escalated audit · alert fired mandatory post-hoc review: pending — due 09:00 REVIEW NOW
Allocation: user + connection + INC-1234 + expiry. On expiry it simply disappears.

Access governance

Access that offboards itself.

Every grant is a time-boxed allocation tied to a live-validated ticket. Sensitive grants can require a second pair of eyes — and for 3 a.m. incidents there is break-glass with a mandatory morning review.

  • UAT/PROD badges and a live countdown on every connection
  • Four-eyes approvals (N-of-M) and a separation-of-duties engine
  • Break-glass emergency access — audited, escalated, reviewed
HASH CHAIN #12337 QUERY_OK h: 7fe1…a2 #12338 PAGE_VIEWED h: c04d…5b #12339 DENIED h: 91aa…7e #12340 PAGE_VIEWED h: a41f…02 Verify integrity → chain intact · 12,340 events 0.4 s SESSION REPLAY 14:00:03 submit SELECT … FROM orders 14:00:04 page 1 20 rows shown 14:02:11 page 3 20 rows shown ✍ evidence.pdf Ed25519 signed · verify offline Admin actions — same ledger grants, edits, role changes · before/after · actor · IP
One click: “Chain intact — 12,340 events.” One more: a signed evidence PDF.

Tamper-evident audit

An audit even your own DBA can't rewrite.

Audit tables are append-only and hash-chained; integrity is verified in one click. Admin actions — who granted, who changed what — live in the same tamper-evident ledger.

  • WORM storage: database triggers block UPDATE and DELETE
  • Hash chain across events — any edit breaks it, visibly
  • Ed25519-signed evidence pack: PDF + machine-verifiable JSON
DYNAMIC MASKING MASKING ON name email card J*** N**** a***@***.com **** **** **** 1234 M*** L**** m***@***.es **** **** **** 8802 P*** H**** p***@***.hu **** **** **** 4471 masked before display · masked before audit — the ledger never stores raw PII SUBJECT EXPOSURE LOOKUP subject: jan.novak@example.com SEARCH 3 sessions saw this subject · vendor@ext (2) · analyst@corp (1) last exposure: 2026-07-11 14:02 · billing-core · page 3 Leak triage paste leaked values → keyed blind index (HMAC) returns matching sessions · no plaintext stored
The vendor debugs the order — the customer stays masked.

Data protection

Personal data stays personal.

Sensitive columns are masked before display and before audit — the audit trail never becomes a second copy of PII. And when data does leak, a keyed blind index answers “who saw this person's records?” in seconds.

  • Dynamic masking: e-mail, names, IBAN, cards, national IDs
  • Subject exposure lookup without storing plaintext (HMAC blind index)
  • Leak triage: paste leaked values, get the sessions that saw them
SQL SENTINEL SUSPICIOUS_SQL · exfiltration pattern SELECT * FROM customers UNION SELECT … -- AUTO-SUSPENDED alert → security team · Slack/Teams/SMTP ANOMALY SIGNALS OFF-HOURS · 02:41 outside business hours (Mon–Fri 08–18) VOLUME ×12 12× the user's usual rows/session FIRST TOUCH customers.card_number — never queried before AI ANALYZER (optional) second opinion behind a port · privacy-preserving prompt Security alerts — review & resume every signal lands in the audit + SIEM · one click to resume a false positive RESUME ✓ EVIDENCE PACK
Caught, suspended, alerted — before the second query runs.

Detection & response

Suspicious SQL doesn't wait for the audit.

SQL Sentinel scores every statement: known exfiltration patterns auto-suspend the allocation on the spot, and anomaly heuristics flag off-hours access, unusual volumes and first touches of sensitive tables.

  • Auto-suspend on suspicious SQL, with a security-alert workflow
  • Anomaly signals: off-hours, row volume, first touch of a sensitive table
  • Optional AI analyzer behind a port — with a privacy-preserving prompt
GLEJT self-hosted proxy IdP — SSO + SCIM Entra ID · Okta · OIDC JIT users · roles from groups Ticketing Jira · ServiceNow live validation · fail-closed SIEM Splunk · Sentinel · QRadar CEF / syslog · webhook Databases PostgreSQL · MySQL/MariaDB Oracle · MSSQL — no agents Web + Tauri desktop one HTTPS endpoint · zero install
GLEJT in the middle — your IdP, ticketing, SIEM and databases around it.

Enterprise fit

Plugs into what you already run.

Self-hosted proxy: your network, your keys, no agents on the databases. Identities come from your IdP, events flow to your SIEM, and tickets stay the source of truth.

  • SSO (OIDC — Entra ID, Okta) and SCIM 2.0 provisioning
  • SIEM streaming: CEF over syslog or webhook — Splunk, Sentinel, QRadar
  • PostgreSQL, MySQL/MariaDB, Oracle and MSSQL behind one gateway

Also in the box

The details that decide security reviews.

Fail-closed audit

If the audit record can't be written, the data is not shown. There is no “seen but unrecorded”.

Encrypted credentials

Envelope encryption (AES-256-GCM); the master key never sits next to the data.

Config-change ledger

Who changed which rule, when, from which IP — with before/after snapshots.

Server-side RBAC

Admin, Analyst, Developer, External — enforced on the server, not in the UI.

Retention with proof

Purge captured values per policy; the tamper-evident event ledger remains.

JIT self-service

Request → approve → time-boxed access. One-click approvals, no standing grants.

Web + desktop

Zero-install browser client over one HTTPS endpoint; thin Tauri desktop app.

Hardened build

Sensitive modules ship as compiled native code — resistant to tampering.

Evidence your auditors will accept

Tamper-evident records per user, per query, per row viewed — mapped to the frameworks you answer to.

Run the free 21-point self-assessment →

Pricing

Price it for your team

Start with the core gateway and switch on only the modules you need. Prices are per user, per month — estimates to size a deal.

Core gateway €15 /user/mo Always included Read-only SELECT gateway, row-level capture, WORM audit with hash-chain, session replay, signed evidence packs, server-side RBAC and time-boxed allocations.

Add-on modules

Roadmap

Where GLEJT goes next

Built with security teams, for security teams — the next bets:

01

Externally anchored audit

The hash-chain head published to external append-only storage, plus an open-source verifier: evidence anyone can check without trusting GLEJT — or us.

02

Detection → response

Signed webhooks to SOAR and PagerDuty, kill-session in flight, one-click playbooks: suspend, evidence pack, ticket.

03

Sensitive-data discovery

A schema scanner proposes PII columns and classification tags — one definition feeding masking, Sentinel and the blind index.

04

Modern data stack

Snowflake, BigQuery, Redshift and MongoDB behind the same gateway and the same proof.

See GLEJT on your own data.

Self-hosted, running against one UAT database in days. No agents, no schema changes — and your first signed evidence pack the same afternoon.

30 minutes, your use case, no slides.

We use your details only to arrange the demo. No newsletters.