🔒 Enterprise Trust & Security

# Everything your InfoSec team needs.
One URL, no back-and-forth.

Forward this page to your security review team. It contains our architecture, the exact Oracle views we read, what we never do, and a lockdown script you control.

⬇ Download Lockdown Bundle Command Whitelist →
01 Architecture

## How data flows — and where it stops

TuneVault never opens an inbound port. The lightweight proxy agent runs on your Oracle server (or EBS app server) and initiates all connections outbound over HTTPS. No VPN, no inbound firewall changes, no inbound SSH. For SSH-SQL query mode, TuneVault opens an outbound SSH connection using credentials you supply — no inbound SSH listener is opened on your server.

🔍 Read the agent source before installing
View oracle-proxy.py in browser · Download oracle-proxy.py · View install.sh · View uninstall.sh

Python 3, ~7,500 lines, no obfuscation.
oracle-proxy.py SHA-256: `loading…` raw · install.sh SHA-256: /install.sh.sha256

01b Credential Storage

## How credentials are handled by connection mode

Storage behavior depends on how you connect. No mode ever stores plaintext passwords.

Connection Mode | Oracle Credentials Stored? | Storage Method | Plaintext on Disk?
--- | --- | --- | ---
Direct TCP — session-only | No — not persisted | In-process only, discarded after use | Never
Direct TCP — saved connection | Yes — encrypted at rest | AES-256-GCM ciphertext in `oracle_connections` | Never
Proxy / HTTP agent | API key only | API key stored as AES-256 ciphertext; Oracle queries run via OS auth on the proxy host — no Oracle password transmitted | Never
SSH-SQL mode (ssh_sqlplus) | SSH key only | Customer-supplied SSH private key stored AES-256-GCM; TuneVault opens outbound SSH to run sqlplus. No Oracle password stored for this mode. | Never

02 Oracle Views Queried

## Exactly what we read — live from the codebase

These are the V$ and DBA_ views TuneVault queries. This list is generated directly from oracle-client.js — if it's not here, we don't read it. All queries are SELECT only.

V$ Dynamic Performance Views (33 views)
V$ARCHIVED_LOG
V$BACKUP_CORRUPTION
V$COPY_CORRUPTION
V$DATABASE
V$DATAFILE
V$DIAG_ALERT_EXT
V$FLASH_RECOVERY_AREA_USAGE
V$INSTANCE
V$LIBRARYCACHE
V$LICENSE
V$LOG
V$LOG_HISTORY
V$OSSTAT
V$PARAMETER
V$PGASTAT
V$RECOVERY_FILE_DEST
V$RESOURCE_LIMIT
V$RMAN_BACKUP_JOB_DETAILS
V$RMAN_STATUS
V$ROWCACHE
V$SESSION
V$SESSION_LONGOPS
V$SGA
V$SGASTAT
V$SGA_RESIZE_OPS
V$SORT_SEGMENT
V$SQL
V$SQL_PLAN
V$SQL_WORKAREA_HISTOGRAM
V$SYSSTAT
V$SYSTEM_EVENT
V$TEMPSEG_USAGE
V$UNDOSTAT
V$VERSION
V$ACTIVE_SESSION_HISTORY
V$SEGMENT_STATISTICS
V$SYSMETRIC
DBA_ Data Dictionary Views (35 views)
DBA_ADVISOR_ACTIONS
DBA_ADVISOR_FINDINGS
DBA_ADVISOR_RECOMMENDATIONS
DBA_ADVISOR_TASKS
DBA_AUTOTASK_CLIENT
DBA_AUTOTASK_JOB_HISTORY
DBA_DATA_FILES
DBA_FEATURE_USAGE_STATISTICS
DBA_FREE_SPACE
DBA_HIST_PGASTAT
DBA_HIST_RESOURCE_LIMIT
DBA_HIST_SGA
DBA_HIST_SNAPSHOT
DBA_HIST_SQLSTAT
DBA_HIST_SQL_PLAN
DBA_HIST_TBSPC_SPACE_USAGE
DBA_HIST_UNDOSTAT
DBA_INDEXES
DBA_IND_COLUMNS
DBA_IND_PARTITIONS
DBA_IND_STATISTICS
DBA_IND_SUBPARTITIONS
DBA_OBJECTS
DBA_PROFILES
DBA_RECYCLEBIN
DBA_REGISTRY_HISTORY
DBA_REGISTRY_SQLPATCH
DBA_SCHEDULER_WINDOWS
DBA_SEGMENTS
DBA_SYS_PRIVS
DBA_TABLES
DBA_TABLESPACES
DBA_TABLESPACE_GROUPS
DBA_TABLESPACE_USAGE_METRICS
DBA_TAB_STATISTICS
DBA_TEMP_FREE_SPACE
DBA_USERS
DBA_USERS_WITH_DEFPWD
DBA_VERSION
APPS / APPLSYS Schema Views (EBS environments only — 18 views)
APPS.DUAL
APPS.FND_CONCURRENT_QUEUES
APPS.FND_CONCURRENT_QUEUES_VL
APPS.FND_CONCURRENT_REQUESTS
APPS.FND_CONCURRENT_QUEUE_SIZE
APPS.FND_OAM_METVAL
APPS.FND_PRODUCT_GROUPS
APPS.FND_PRODUCT_INSTALLATIONS
APPS.FND_SVC_COMPONENTS
APPS.FND_SVC_COMP_PARAM_VALS_V
APPS.FND_NODES
APPS.FND_PROFILE_OPTIONS
APPS.FND_PROFILE_OPTION_VALUES
APPS.WF_ERROR
APPS.WF_NOTIFICATIONS
APPS.AD_TRACKABLE_ENTITIES
APPS.AD_ADOP_SESSIONS
APPS.AD_ADOP_SESSION_PATCHES

APPS schema views are only queried when an EBS environment is detected via `APPS.DUAL` probe. Non-EBS Oracle databases are never queried against APPS schema.

03 What We Never Do

## Hard boundaries

These are not policies subject to internal override — they are architectural constraints enforced by the read-only Oracle user and proxy design.

✗
No DML on user schemas No INSERT, UPDATE, DELETE, or MERGE against any user table. The connecting Oracle user has no DML privilege.
✗
No DDL anywhere No CREATE, ALTER, DROP, or TRUNCATE. The health check user cannot create objects.
✗
No SYS or SYSTEM password TuneVault creates a dedicated read-only user (tunevault_reader) for network-authenticated connections. For agent-only connections where no credentials are stored, the agent connects via OS authentication on the Oracle server — equivalent to running sqlplus / as sysdba locally. This is identical to how Oracle Enterprise Manager agents work. All queries are read-only SELECTs regardless of connection method.
✗
No business data exfiltration We read metadata and system views only. We never query tables in user schemas, application tables, or any table with customer data.
✗
No AI-generated SQL execution AI analysis is read-only advisory only. Recommendations displayed to the user are never automatically executed against the database.
✗
No inbound connections TuneVault never initiates a connection to your network. The proxy calls out; we listen. No inbound firewall rules required.
✗
No bind variable values in AI prompts SQL text sent to OpenAI or Anthropic for analysis has bind variable values stripped before transmission.
✗
No arbitrary OS command execution EBS shell commands use an exact-match whitelist baked into the proxy. Shell injection is not possible — the whitelist is code, not config.
04 Required Oracle Privileges

## Minimum grants — verified against code

Two system privileges cover the core data dictionary and V$ views. One explicit view grant covers the alert log. EBS environments require additional APPS schema grants. All grants are read-only SELECT — no DML, no DDL.

oracle-setup.sql copy-paste safe
-- Step 1: Create a dedicated read-only user CREATE USER tunevault_ro IDENTIFIED BY <strong_password>; GRANT CREATE SESSION TO tunevault_ro; -- Allows the user to connect. Required for all subsequent privileges. -- Step 2: DBA_ data dictionary views (tablespaces, segments, indexes, users, etc.) GRANT SELECT ANY DICTIONARY TO tunevault_ro; -- Covers DBA_TABLESPACES, DBA_SEGMENTS, DBA_INDEXES, DBA_USERS, DBA_DATA_FILES, -- DBA_TABLES, DBA_OBJECTS, DBA_PROFILES, DBA_SYS_PRIVS, DBA_HIST_* and more. -- Step 3: V$ dynamic performance views (sessions, SQL, SGA, wait events, RMAN) GRANT SELECT_CATALOG_ROLE TO tunevault_ro; -- Covers V$SESSION, V$SQL, V$SYSSTAT, V$SYSTEM_EVENT, V$SGA, V$RMAN_BACKUP_JOB_DETAILS, -- V$PARAMETER, V$INSTANCE, V$DATABASE, V$LOG, V$UNDOSTAT, V$PGASTAT and more. -- Step 4: Alert log access (NOT covered by SELECT_CATALOG_ROLE — explicit grant required) GRANT SELECT ON V_$DIAG_ALERT_EXT TO tunevault_ro; -- Without this, alert log checks show "insufficient privileges" instead of real log data. -- Step 5: EBS APPS schema views (EBS environments only — skip ORA-00942 errors, some views vary by version) -- Run as APPS or a DBA user with grant option. GRANT SELECT ON APPS.FND_CONCURRENT_QUEUES TO tunevault_ro; GRANT SELECT ON APPS.FND_CONCURRENT_QUEUES_VL TO tunevault_ro; GRANT SELECT ON APPS.FND_CONCURRENT_REQUESTS TO tunevault_ro; GRANT SELECT ON APPS.FND_PRODUCT_GROUPS TO tunevault_ro; GRANT SELECT ON APPS.AD_TRACKABLE_ENTITIES TO tunevault_ro; GRANT SELECT ON APPS.FND_NODES TO tunevault_ro; GRANT SELECT ON APPS.AD_ADOP_SESSIONS TO tunevault_ro; GRANT SELECT ON APPS.AD_ADOP_SESSION_PATCHES TO tunevault_ro; GRANT SELECT ON APPS.FND_PROFILE_OPTIONS TO tunevault_ro; GRANT SELECT ON APPS.FND_PROFILE_OPTION_VALUES TO tunevault_ro; GRANT SELECT ON APPS.FND_SVC_COMP_PARAM_VALS_V TO tunevault_ro; GRANT SELECT ON APPS.FND_CONCURRENT_QUEUE_SIZE TO tunevault_ro; GRANT SELECT ON APPS.FND_SVC_COMPONENTS TO tunevault_ro; GRANT SELECT ON APPS.WF_ERROR TO tunevault_ro; GRANT SELECT ON APPS.WF_NOTIFICATIONS TO tunevault_ro; GRANT SELECT ON APPS.FND_OAM_METVAL TO tunevault_ro; GRANT SELECT ON APPS.FND_PRODUCT_INSTALLATIONS TO tunevault_ro;

Full setup walkthrough: oracle-setup guide → · Complete SQL query list: security/commands →

04b EBS Command Whitelist

## Every permitted EBS control command

These are the only EBS operational commands TuneVault can issue. The list is seeded in the database at deployment time and validated server-side on every request — user input never flows into command construction.

+ Full SQL query whitelist (200+ checks) →

Slug | Label | Category | Command Preview | Risk | Dry-run
--- | --- | --- | --- | --- | ---
Loading live whitelist from database...

Hard enforcement: Anything not in this table returns HTTP 403 and an `audit_log` rejection row — before any Oracle command is even considered. The slug validation happens against the database, not a client-supplied list. If a slug isn't in `ebs_control_commands`, it cannot be executed, ever.
04c Audit Trail

## Every action logged. Immutably.

The `audit_log` table captures every EBS control preview attempt — allowed and rejected — as append-only rows. No row is ever updated or deleted.

audit_log — append-only, no UPDATE/DELETE

    CREATE TABLE audit_log (
      id               BIGSERIAL    PRIMARY KEY,
      user_id          INTEGER      NOT NULL REFERENCES users(id),
      action           TEXT         NOT NULL,   -- e.g. 'ebs_control.preview'
      slug             TEXT         NOT NULL,   -- command slug attempted
      allowed          BOOLEAN      NOT NULL,   -- true = whitelisted, false = rejected
      rejection_reason TEXT,                     -- null when allowed=true
      metadata         JSONB        DEFAULT '{}', -- ip, user_agent, risk_level
      created_at       TIMESTAMPTZ  NOT NULL DEFAULT NOW()
    );

    -- No UPDATE/DELETE permissions granted on this table.
    -- Application role has INSERT + SELECT only.

Sample row — allowed attempt
action'ebs_control.preview'
slug'cm_bounce'
allowed true
rejection_reason null
metadata{"ip": "203.0.113.45", "risk_level": "medium"}
📌
Every rejection logged
Non-whitelisted slug attempts write a row with `allowed=false` and a rejection_reason — before returning HTTP 403.
🔒
Append-only by design
The application DB role has INSERT + SELECT only on audit_log. No UPDATE or DELETE is possible from the API tier.
🌐
IP captured on every row
The originating IP and user-agent are stored in metadata. Cross-reference with your WAF logs for full attribution.
♾
No retention limit
Audit rows are retained indefinitely. No automated purge job. Contact support@tunevault.app to request a log export.
04d Threat Model

## What an attacker would have to compromise

The table below maps each realistic attack scenario to the controls that block it. Every row is a question your security team will ask. Every cell is a concrete, verifiable answer.

Attack Scenario | What the Attacker Needs | Controls That Block It | Risk
--- | --- | --- | ---
Access another tenant's Oracle connection | Valid session + target connection ID | Server-side ownership check on every connection operation. Guessing an integer ID returns 404, not the connection. All credential columns are AES-256 encrypted — even a DB dump is ciphertext only. | BLOCKED
Steal Oracle credentials from TuneVault's database | Full Neon DB dump + the `ENCRYPTION_KEY` env var (separate secret) | AES-256-GCM encryption at rest. The key is a Render environment variable — never in DB, never in git, never in logs. Compromising only the DB yields ciphertext with no decryption path. | BLOCKED
Inject arbitrary commands via the agent channel | A valid per-tunnel API key + ability to intercept TLS | Agent enforces a hard command allowlist — only named commands with typed argument validation execute. No shell=True, no string interpolation. TLS validates server certificate via system CA bundle. | BLOCKED
Escalate from viewer → admin via API manipulation | Valid session with any role | RBAC enforced server-side via `requireRole()` middleware. Client-side visibility is cosmetic only — never trusted for access decisions. Role hierarchy: viewer → junior_dba → senior_dba → admin. | BLOCKED
Reuse a magic link / steal a session | Intercept email or session cookie | Magic links are single-use (database-enforced), 15-minute TTL, 256-bit entropy. Session cookies are HttpOnly + Secure + SameSite=Lax. Auth endpoint rate-limited: 10 requests/minute per IP. | HARDENED
Compromise the TuneVault cloud service | Full Render platform access | Even with cloud access, attacker can only issue commands from the agent channel allowlist. No shell access to the customer host is possible — agent is outbound-only, no inbound port. Credentials still encrypted separately from the DB. | HARDENED
Run arbitrary SQL via SQL Console | senior_dba session + target connection ownership | SQL Console requires `senior_dba` role. Execution enforces connection ownership server-side. Every query logged to `sql_audit_log` with user, SQL text, connection, duration, and outcome — permanent append-only. | AUDITED

05 Data Handling

## Where your data goes and how long it stays

TuneVault processes Oracle system metrics — not your business data. Here's the full picture.

Transit encryption
TLS 1.3
All data between proxy and TuneVault API is encrypted in transit via edge-terminated TLS 1.3.
At-rest encryption
AES-256
Health check results stored in managed Postgres (AES-256 at rest). Connection credentials encrypted AES-256-GCM before storage.
Raw result retention
Connection-scoped
Results are retained until the connection is deleted. Delete a connection via dashboard or `DELETE /api/connections/:id` to purge all results immediately.
Data deletion
On request
Deleting a connection via the dashboard or `DELETE /api/connections/:id` purges all associated health check results and credentials.
AI data handling
Redacted
SQL text sent to OpenAI (GPT-4o-mini) and Anthropic (Claude) has bind variable values stripped before transmission. Data is not used for model training per their enterprise API policies.
Third-party sharing
None
Your Oracle metrics are not sold or shared with third parties. OpenAI and Anthropic receive anonymized, redacted SQL text for AI analysis only — no business data, no query results.
What we collect: Oracle system metrics (tablespace usage, wait events, SQL statistics, session counts, backup status). System view metadata only.
What we never collect: Application table rows, business data, personally identifiable information from your Oracle database, Oracle user passwords, or SYS-level credentials.
06 Customer-Run Lockdown Script

## Your InfoSec team controls the proxy

Before installing the proxy agent, your team runs this script. It locks down the proxy to outbound-only HTTPS connections and creates a restricted OS user with no login shell.

🔒

### tunevault-lockdown.sh — Enterprise Hardening Script v2

Run as root on your Oracle application / proxy host. Idempotent — safe to re-run. Tested on OEL 7/8/9, RHEL 7/8/9, Ubuntu 20.04/22.04, Amazon Linux 2/2023, Debian.

1
Creates restricted `tunevault` OS user (`/sbin/nologin`)
2
Sets `/opt/tunevault` directory to mode 750
3
Installs SELinux module or AppArmor profile
4
Applies iptables uid-scoped outbound 443-only rules
5
Writes EBS-only sudoers whitelist (status commands only)
6
Configures logrotate: weekly, 52-week retention
# Run as root on your Oracle / proxy host
$ curl -o tunevault-lockdown.sh https://tunevault.app/security/lockdown.sh
$ chmod +x tunevault-lockdown.sh
$ sudo ./tunevault-lockdown.sh
⬇ Enterprise Lockdown Bundle Contact security@tunevault.app to request the enterprise lockdown bundle

Bundle includes: tunevault-lockdown.sh + README.md (SOC2/ISO/NIST mapping) + whitelist.json (SHA-256 hashes)

07 Incident & Disclosure

## How we handle security issues

We take security disclosures seriously and respond quickly. If you find something, tell us.

Security contact security@tunevault.app
Disclosure SLA 72-hour response, 30-day coordinated disclosure window
Operational status Email security@tunevault.app for current status
PGP key Available on request via security@tunevault.app
For confirmed security incidents, we will: (1) acknowledge within 72 hours, (2) assess severity within 5 business days, (3) notify affected customers before public disclosure, (4) publish a post-mortem with root cause and remediation within 30 days of fix.
08 Compliance Posture

## Honest about where we are

We're an early-stage company. We'll tell you exactly where we stand — not what sounds good on a sales call.

⧖ In Progress

#### SOC 2 Type II

Audit in progress. We use Vanta for continuous control monitoring. Target completion: Q4 2026. Contact us for the current readiness report.

✓ Ready

#### GDPR

Data subject deletion endpoint live (`DELETE /api/connections/:id`). All data processed and stored in the US. DPA available on request.

— Out of Scope

#### HIPAA

TuneVault reads Oracle system metadata, not application data. We do not process Protected Health Information (PHI) and are out of scope for HIPAA.

⧖ Planned

#### ISO 27001

Controls aligned to ISO 27001 A.9 (access control), A.12 (operations security), A.13 (communications security). Formal certification planned after SOC 2 completion.

✓ Ready

#### Penetration Testing

Annual third-party pen test. Most recent report available under NDA to enterprise prospects. Contact security@tunevault.app to request.

✓ Enforced

#### Least-Privilege Design

The Oracle connecting user holds `SELECT ANY DICTIONARY` (DBA_ views) and `SELECT_CATALOG_ROLE` (V$ views), plus an explicit grant on `V_$DIAG_ALERT_EXT` for alert log access. EBS environments require additional APPS schema grants. No DML, no DDL, no SYS privileges. Exception: agent-only connections (no stored credentials) use OS authentication. The agent runs on your server and queries are still read-only — but the connecting Oracle session has SYSDBA context. We recommend storing tunevault_reader credentials for strict least-privilege operation.

09 ROI Calculator Methodology

## How We Calculate DBA Hours Saved

The ROI calculator on our pricing page uses three published benchmarks and one internal estimate. Here's exactly what they are, where they come from, and what assumptions we made.

Input | Formula | Source
--- | --- | ---
Incident resolution time | 2.5 hrs per page | Gartner "Mean Time to Restore" benchmark for unplanned Oracle outages (includes triage, diagnosis, and remediation). Represents the median DBA-hours consumed per production incident.
Automation factor | 0.7 (70% reduction) | Internal estimate based on TuneVault feature coverage: the Patch Advisor covers ~30% of CVE-related incidents; Control tab v2 covers ~25% of Concurrent Manager + Workflow incidents; autonomous monitoring catches ~15% of storage/backup issues before they page. Aggregate coverage: ~70% of the incident categories we observe. We apply this to pages, not hours — a 70% reduction in pages fired, not a 70% reduction in resolution time per page. Conservative by design.
Routine monitoring per DB | 4 hrs/month per DB | Based on the IDUG 2024 DBA Workload Survey (International DB2 Users Group — the closest published survey covering Oracle DBA time allocation). Respondents reported 3–6 hours per database per month on routine checks: space monitoring, backup verification, index maintenance review, and performance baseline review. We use 4 hours as the midpoint.

Full Formula
`hours_saved = (pages × 2.5 × 0.7) + (dbs × 4)
monthly_saved = hours_saved × hourly_rate
payback_days = plan_price ÷ (monthly_saved ÷ 30)`

What this model does not account for: costs of post-incident root cause analysis, impact of delayed detection on user SLAs, or reputational cost of unplanned downtime. Including these would increase the modeled savings significantly. We excluded them to keep the estimate conservative and defensible.

The default slider values (4 databases, $150/hr, 8 pages/month) reflect a mid-market Oracle DBA profile in the US. Adjust them to match your environment — the math updates live. Questions? hello@tunevault.app