Documentation — Architecture

# Security Architecture

This page stands alone. If you read nothing else in this documentation set, this is the summary — every claim below is verified in detail on its own page, linked at the end of each section.

## What crosses the boundary — completely

Crosses | Payload
--- | ---
Agent poll | An API key and a request for queued work. Held open up to 25s.
Command result | The output of a specific health check or op — the finding data, nothing incidental.
License check (self-hosted) | A license key and a hostname. Once per boot, or on demand at the point of use.

That is the complete list. Your Oracle username and password never cross it. The SQL your database runs never crosses it. Query results beyond what a specific check explicitly requested never cross it.

## No inbound ports, ever

The agent installed on your Oracle server only makes outbound HTTPS requests. It never listens, never accepts a connection, and requires no firewall exception beyond what any server already needs to browse the internet. This is the property that makes self-hosted TuneVault workable inside networks that block everything else by default.

Full detail: Connectivity & Agent Protocol →

## Credentials are encrypted at rest, decrypted only in memory

Oracle, EBS, and SSH credentials are stored with AES-256-GCM. The encryption key is generated on your own machine at install time — never derived from another value you'd have to protect separately, never transmitted anywhere. Decryption happens in memory, per connection, only when a check actually needs to run.

Full detail: Oracle Privilege Model →

## Read-only by default; SYSDBA never required

The standard privilege model (`tunevault_reader`) is read-only and sufficient for all 200+ health checks, ADDM, and SQL Tuning Advisor. TuneVault's own AI tooling enforces the same discipline: DBA Agent's `run_sql` tool passes through the identical guard the SQL Console uses, rejecting any write statement before it reaches your database.

Full detail: AI Layer →

## Destructive operations require explicit confirmation

Starting or stopping an EBS service is never a single click. A client-side CONFIRM step stands between the button and the request that reaches your agent — an accidental click cannot bounce a running service. Separately, destructive operations are refused server-side while an ADOP patch cycle is detected in progress — before the command is queued for the agent, and regardless of confirmation. Clearing that refusal takes more than a click: the operator has to re-send the request with the active ADOP session ID.

Full detail: EBS & DB Operations →

## Licensing fails toward restriction, never toward unlimited

A self-hosted license that cannot reach the validation server does not fall back to unlimited access. It uses a cached result from its last successful validation, bounded to 30 days and tied to the specific key that earned it. A key that has never successfully validated receives only minimal capability — never a default of "trust it."

Full detail: Licensing & Deployment →

## Everything here is verifiable, not asserted

Every claim on this page links to a page showing the actual code path, actual table columns, or actual query behind it — not a description of intent. If you're evaluating TuneVault for a security review, that's the intended use of this documentation set: read this page for the summary, then follow any link to the primary source before you rely on the claim.

Self-hosted TuneVault runs this entire architecture inside your own network. Reading this page and then running the software yourself is a stronger form of verification than any document can provide.
Start over from Architecture Overview, or go straight to download self-hosted.