VARUX AXIS / DATABASE WRITE-PATH CONTROL

Stop risky production writes before they reach PostgreSQL.

Deterministic policy enforcement, approval workflows and durable audit evidence.

VARUX AXIS is a control layer for PostgreSQL write paths. It evaluates actor context, SQL intent, policy rules, and approval state before risky UPDATE, DELETE or DDL operations execute.

Current milestone
v0.6 Pilot Readiness
Suitable for
Controlled demos · local review · non-production pilot
Not yet
Compliance-certified enterprise production release
Built for technical review before rollout.
Explore Architecture

Choose your review path.

AXIS is designed to be evaluated by different technical audiences without hiding its current limits.

THREAT / EVIDENCE

Security Reviewer

Start with the security model, failure behavior, approval boundaries and audit evidence flow.

Security Model Evidence Failure Model
ARCHITECTURE / OPERATIONS

Platform Engineer

Review the write-path placement, control plane expectations, rollout modes and operational constraints.

Architecture Operating Modes Pilot Checklist
LOCAL REVIEW / NON-PRODUCTION

Pilot Evaluator

Use the pilot checklist to prepare a staging or non-production evaluation with representative SQL operations.

Pilot Path Pilot Checklist
PRODUCT / RISK

Founder / CTO

Understand what AXIS does, what it refuses to claim and where it fits in production database governance.

What AXIS Is Current Limitations

Production writes are still too easy to damage.

Modern systems let internal tools, automation, scripts, and AI agents touch production databases. A single broad DELETE or unsafe DDL can become an incident if it bypasses policy, approval and evidence.

Broad DELETE / UPDATE

Batch writes and missing WHERE conditions create irreversible damage.

Unsafe DDL

Schema changes can break behavior when bypassing review.

AI / automation access

Agents and scripts move faster than human review without boundaries.

Missing durable evidence

App logs cannot reliably prove who attempted what and why.

What AXIS Is

AXIS is a controlled execution gateway. Clients submit write intent through AXIS. AXIS builds context, classifies SQL, evaluates deterministic policy, writes durable evidence and only then allows, blocks or routes the operation to approval.

Gate

Collects context, normalizes SQL, classifies READ/WRITE and extracts risk signals.

Policy Engine

Evaluates policies deterministically to ALLOW, BLOCK or REQUIRE_APPROVAL.

Evidence

Records verifiable events so risky database operations can be reconstructed securely.

AXIS is:

  • deterministic PostgreSQL write-path control
  • controlled execution gateway
  • policy-enforced decision layer
  • approval boundary for risky operations
  • durable audit evidence generator
  • operator visibility and policy lifecycle surface

AXIS is not:

  • WAF, SIEM, or DLP
  • SQL injection detector
  • masking/encryption product
  • query optimizer
  • full drop-in PostgreSQL wire-protocol proxy
  • replacement for application authorization
  • compliance-certified release

Deterministic Write-Path Architecture

System Components

Clients / Services
Scripts / AI Agents
AXIS GATE
Context Builder
SQL Classifier
Policy Engine
Approval Workflow
Audit / Evidence Store
DB Adapter
ALLOW PostgreSQL
REQUIRE_APPROVAL Human Queue
BLOCK Controlled Error
Control Plane (Visibility, Policy, Evidence)

"Unsafe ambiguity must not silently proceed. Unknown or unsupported write-capable SQL should be blocked or routed to approval by policy."

Every write becomes context, decision and evidence.

AXIS decisions are deterministic. The same request context and policy version produce the same outcome.

1
Request
2
Context
3
Classification
4
Risk Signals
5
Policy Eval
6
Evidence
ALLOW
BLOCK
REQUIRE_APPROVAL
request_id actor app tenant role env sql_fingerprint operation risk_signals policy_version reason_code decision

Control Plane Preview

Operational truth, not decorative confidence.

Preview values only. A live deployment must bind these cards to real AXIS endpoints.
Audit Chain
Verified
last_event: 9a3b…
checked_events: 128
Evidence Store
Healthy
WAL projection up
malformed: 0
Policy
prod_main@1.0.0
mode: enforce
defaults.write: BLOCK
Approvals
1 Pending
oldest: 03m
TTL enforced
Runtime
Online
backend: healthy
adapter: reachable
service: axis-backend
status: healthy
mode: enforce
audit_integrity: verified
policy_loaded: true
policy_version: prod_main@1.0.0
pending_approvals: 1

decision_counts:
  ALLOW: 18
  BLOCK: 6
  REQUIRE_APPROVAL: 3

evidence_verification:
  valid: true
  verification_depth: full_hash
  checked_events: 128
  malformed_count: 0
  last_event_hash: 9a3b8c2d1e...
Health values are static previews.
Demo preview only. No backend request was sent.

Security Model

Architectural principles protecting the database write-path.

Deterministic Enforcement

Explicit policy rules and versioned metadata, not probabilistic guesswork.

Fail-Safe Defaults

Unsafe ambiguity or internal policy failure must not silently proceed to the DB.

Durable Evidence

Every critical write-path decision is securely recorded before action is taken.

Approval Boundaries

Risky operations routed to human approval bounded by strict policy_version and TTL.

Bypass Control

Protected write paths must route through AXIS. A real pilot must review:

  • App connection strings point to AXIS/Gate
  • Direct DB port is restricted from non-Gate workloads
  • Emergency direct write path requires audit event
  • Drift detection reports unexpected DB clients

Evidence that survives the incident review.

Application logs explain what an app thinks happened. AXIS evidence definitively explains what the production write-path allowed, blocked or escalated.

  • request_received
  • decision_made
  • approval_requested
  • approval_resolved
  • query_executed
  • error_returned
{
  "request_id": "req_82aa",
  "event_type": "decision_made",
  "actor": "ops.admin",
  "operation": "UPDATE",
  "target": "public.customers",
  "decision": "REQUIRE_APPROVAL",
  "reason_code": "approval_required_batch",
  "policy_version": "prod_main@1.0.0"
}

Operating modes for controlled rollout.

Observe / Shadow

Record decisions without blocking writes. Useful for evaluation.

Approval-first

Route risky writes into workflows before strict automated blocking.

Enforce

Apply policy deterministically to ALLOW, BLOCK or REQUIRE_APPROVAL.

Emergency Bypass

Scoped, time-limited auditable exception. Not an escape hatch.

Pilot and Technical Review Path

Evaluating AXIS follows a structured customer review path designed for security and platform engineering teams.

1
Understand architecture
2
Run local evaluation
3
Inspect decisions & evidence
4
Review pilot limitations

CURRENT POSTURE

AXIS v0.6 is suitable for controlled demos, local technical evaluation, architecture review and non-production pilot planning.

NOT YET

Not yet an enterprise production-ready distributed deployment or compliance-certified release.

Pilot Success Examples:

  • Dangerous DELETE blocked before PostgreSQL.
  • Approved bulk operation traced by request_id.
  • Decision shows reason_code and policy_version.
  • Audit timeline reconstructs write attempt.

Pilot readiness checklist

Before a technical review or pilot, prepare the inputs that make AXIS evaluation realistic.

1. Non-production DB

Use staging or a local database. Do not start with production.

2. Representative SQL

Collect realistic UPDATE, DELETE, DDL operations.

3. Policy requirements

Define examples of allowed and blocked writes.

4. Approval rules

Identify test approvers and workflow expectations.

Questions a serious reviewer should ask

Which SQL forms expand the classifier test corpus?

What identity model binds request fields to principals?

What transport security is required for the pilot?

Should evidence be exported to an append-only archive?

What KMS-backed verification is required later?

How do instances coordinate policy and continuity?

Which operator actions require a dedicated audit stream?

What latency budget is acceptable for write-path enforcement?

Current limitations are part of the review.

Security products lose trust when gaps are hidden. Evaluate AXIS v0.6 with clear boundaries.

Implemented today

  • Rust backend service with Axum API
  • PostgreSQL-focused SQL classification
  • Policy engine (ALLOW/BLOCK/APPROVAL)
  • Local JSONL store approval workflow
  • Audit evidence generation with hash-chain
  • Evidence verification & visibility endpoints
  • Policy validation, dry-run, and rollback

Not implemented yet

  • Full RBAC or SSO
  • Complete TLS/mTLS deployment story
  • Distributed consensus coordination
  • External KMS signed policy distribution
  • Tamper-proof external audit ledger
  • Formal compliance mapping or certification
  • SaaS control plane

This section is intentionally explicit so pilot discussions start from engineering reality, not marketing fog.

VARUX AXIS / TECHNICAL REVIEW

Production writes should not depend on hope.

Request a technical review of AXIS for architecture review, controlled demo discussion or non-production pilot planning.

Back to VARUX Lab
REVIEW SNAPSHOT
Current v0.6 Pilot Readiness
Scope PostgreSQL write-path
Decisions ALLOW / BLOCK / APPROVAL
Evidence Durable audit trail
Pilot Non-production planning