Security & Isolation

Security Architecture

Last updated: November 2026 · Launch Milestone 16 Nov 2026

What the code really does. Every claim on this page describes verifiable security controls implemented in our codebase and deployment configurations. We make no unverified compliance certifications.

The 8-Gate Security Pipeline

Every request that enters the Rigsfactory execution engine must traverse eight ordered security gates before reaching a stage server:

1Gate 1

Authenticate

Verifies OIDC workload tokens, local JWTs, or Argon2id-hashed API keys.

2Gate 2

Tenant

Validates tenant context against the authenticated organization boundary.

3Gate 3

Authorize

Checks caller permissions against stage execution and deployment roles.

4Gate 4

Rate Limit

Enforces tenant-scoped sliding window request and concurrency ceilings.

5Gate 5

DLP In

Inspects inbound envelopes and strips unintended secrets or access keys.

6Gate 6

Handler

Executes stage operations within isolated cgroup/namespace boundaries.

7Gate 7

DLP Out

Verifies outbound deliverables do not contain host secrets or environment tokens.

8Gate 8

Audit Log

Appends an immutable log entry with stage inputs, outputs, approver, and duration.

1. What We Read & Ingest

  • Usage metadata only: TeksOptima reads Snowflake ACCOUNT_USAGE views and Databricks system.* tables (billing, compute, jobs, and serving). We never query or store customer table records.
  • SQL statement text in Databricks is omitted (NULL) by default unless explicitly enabled by an authorized administrator.
  • Databricks user identities (query authors, job owners, and emails in tags) are replaced by a salted hash inside the customer workspace before leaving it. The salt never leaves the customer's secret scope; we cannot reverse the hash.
  • InfraOps telemetry is limited to incident signals (DAG IDs, model names, query IDs, error codes). Database connection credentials stay exclusively inside the customer's network.

2. Build Sandboxing & Execution Isolation

  • Code generated during TeksBuild is compiled and run in Runbox: a separate container per project on an internal network, with outbound access limited to package registries through a proxy.
  • A host firewall blocks connections from those containers to the build server and its local services. The containers have no access to the host VM's filesystem.
  • Internal daemons (Ollama model runner, SearXNG, Camofox) bind strictly to loopback (127.0.0.1) and are not exposed to the public internet.
  • External requests to the Rigsfactory engine pass through an nginx reverse proxy over TLS before reaching the gateway service.

3. Cryptography & Credential Storage

  • Data-source credentials and upload tokens are encrypted at rest using AES-256-GCM with a unique, cryptographically random initialization vector (IV) per entry.
  • Token comparison (approval tokens, cron secrets, webhook signatures) is performed exclusively with constant-time algorithms to prevent timing attacks.
  • Service principal OAuth secrets are entered once, encrypted at rest, and never shown, logged, or returned via the API. Access tokens obtained from them are short-lived and kept in memory only.
  • Transport security: every public endpoint is served over HTTPS only, and the web apps send HTTP Strict Transport Security (HSTS) headers.

4. Human Gates & Approval Security

  • Every code change, pipeline deployment, and live infrastructure modification requires explicit human approval.
  • Approval links (/approve/[token]) carry an HMAC-SHA256 signature with a strict 14-day expiry. Mail scanners and prefetching bots cannot trigger approvals because state changes require a button POST.
  • Decisions are single-use: once decided, an approval token cannot be replayed or altered.
  • Chatbot approvals via Microsoft Teams verify Bot Framework JSON Web Key Sets (JWKS) and enforce a 5-minute timestamp clock tolerance. Slack actions verify the v0 signature.

5. Hosting & Network Boundaries

  • The Teks1platform shell runs on Vercel Functions in Singapore (sin1), matching our Neon Postgres region (ap-southeast-1) for minimal network latency and strict regional locality.
  • Database state is managed in Neon Serverless Postgres, encrypted at rest, with Neon's point-in-time restore over the window our Neon plan provides.
  • SSRF Protection: The platform's connection testing suite blocks requests to loopback addresses, link-local subnets, and cloud metadata endpoints (169.254.169.254).

Reporting a Vulnerability

We welcome vulnerability reports from security researchers and customers. If you believe you have discovered a vulnerability in any Tekspaz service:

  • Email your findings to security@tekspaz.ai or sales@tekspaz.com.
  • Do not include real customer credentials or sensitive production data in your report.
  • Allow us reasonable time to investigate and patch before public disclosure.