QuietNode
Security & governance

Security you can verify, run by run.

QuietNode deploys in your VPC and holds no credential. QuietLens is read-only, enforced in code. QuietMend is in development and has never run against live systems. This page gives a security reviewer the architecture, the access design, the controls, and what the audit trail looks like.

See what’s in the security docs packMeet your AI employees

  • 149 of 149 golden cases

    QuietLens deterministic engine, published with each release; an ungrounded number fails the build

  • Read-only by construction

    QuietLens allows a single SELECT, enforced in code; there is no write tool

  • Deployed in your VPC

    Product state and connector credentials stay under your control

Architecture

Deployment and connector credentials stay in your boundary.

QuietNode runs inside your VPC, with product state and connector credentials under your control. QuietLens reads through connectors in your environment. Prompt and model traffic follows the endpoint you configure, including a private in-VPC endpoint when required.

Business question or ticket

Slack, chat, or Jira intake

Your VPC — customer boundary

QuietNode platform

Runs inside your environment

Scoped connectors

Warehouse — read-only

SELECT-only sessions, allowlisted schemas

BI tools

Report metadata, lineage, refresh state

Git

Branch and pull request only

Evidence + approval gate

Evidence pack assembled; nothing moves without sign-off

Human reviewer

Your team approves the outcome

Product state and connector credentials remain in your boundaryPrompt traffic follows the model endpoint you configure
Access lifecycle

Access matches the role and the run.

QuietMend is designed to ask for short-lived access scoped to the ticket, and to get it only after a person approves. It is in development and has never run against live systems. QuietLens uses a customer-managed, read-only service identity, and logs every action.

01

Request

An assigned ticket starts a QuietMend run

02

Plan and access request

Posted on the ticket first

03

Human approval

Designed: short-lived access, scoped to the ticket

04

Run in DEV

Change prepared in DEV only

05

Access ends

Designed: no standing access

06

Pull request

A person reviews and merges

Governance controls

Eight controls, written down.

These are not configuration options layered on afterwards. QuietLens enforces them in code. For QuietMend they are the design, and it is in development.

Customer VPC deployment

QuietNode runs inside your environment. Product state and connector credentials remain under your control.

Read-only by default

QuietLens is read-only, enforced in code: the SQL policy allows a single SELECT, and there is no write tool.

Role-bound access

QuietLens uses a customer-managed read-only identity. QuietMend is designed to ask for short-lived access scoped to the ticket.

Role-based permissions

Each AI employee's permissions are written down, and can be audited.

Approval gates

QuietMend is designed to wait for a person to approve its access request before it gets any access.

Audit logs

Every action is logged. The QuietLens audit log is hash-chained.

No production change without review

QuietMend cannot merge and cannot write to production. It is in development and has never run against live systems.

Customer-controlled routing

QuietLens answers with no LLM key at all, or uses your own model endpoint, including a self-hosted one.

Audit evidence

What the auditor actually sees.

An illustrative run shape: a business user asks why the daily revenue report is missing. It shows the trail a run leaves behind — scope, access, queries, evidence, approval, and the recorded action.

Illustrative audit timeline

Run QN-2189 — missing daily revenue report

QuietLens BICompleted

  1. 06:42:10

    Scope bound

    scope: revenue_daily

    Investigation bound to the revenue_daily report lineage. Connectors in scope: Snowflake (read-only), Airflow, Power BI.

  2. 06:42:11

    Read-only access checked

    service identitySELECT-only

    Customer-managed service identity checked against the allowlisted SELECT-only scope. No write grant issued.

  3. 06:43:27

    Queries executed

    SELECT-only4 queries

    Four queries against allowlisted schemas, each logged with full query text, duration, and row counts.

  4. 06:44:05

    Evidence pack attached

    6 artifacts

    Lineage trace, the failed Airflow task load_revenue_daily, last successful run, affected reports, and the owning team.

  5. 06:57:11

    Investigation completed

    session closed

    The connector session closed. The read-only service identity remains customer-managed, with no run-specific grant left open.

  6. 07:12:45

    Reviewer approved

    approval: on-call

    Data platform on-call reviewed the evidence pack and approved the recommended action.

  7. 07:13:02

    Action recorded

    DATA-512

    Operational ticket DATA-512 raised with the evidence pack attached. The full timeline is retained for audit.

Every run — execution or investigation — produces this timeline. It is retained end-to-end and exportable for your security and compliance reviews.

Security FAQ

Security questions, answered.

The questions security reviewers ask first. For anything deeper, the docs pack covers the full model.

QuietLens holds read-only access, enforced in code: the SQL policy allows a single SELECT and there is no write tool. QuietMend is designed to post a plan and an access request on the ticket, and to wait for a person to approve before it gets any access.

Next step

Security review on your timeline.

The pack itemizes the control mapping, data-handling and retention policy, eval methodology, and release provenance, plus QuietMend’s access design. A DPA template is available on request. See the full list, then request what your review needs.

See what’s in the security docs packMeet your AI employees