Technical documents

Security Architecture Pack

Security review pack

The security and architecture documentation Sixta provides for review during procurement — how it connects, what it can and cannot reach, and how access is governed.

By
Ewen Fortune
01 March 2026
8
min read

Every security review of an autonomous database agent arrives at the same three questions. What can it see? What can it change? And how would we know if it did something we did not expect?

This pack answers them in the form security teams normally want them: data flows, privilege grants, network connections, guardrails and the audit record. It is the same material Sixta supplies for internal vendor security evaluation, published here so it can be read before a call rather than after one.

01. Data flow summary

Sixta collects no personally identifiable information, by design rather than by filter. It reads performance metadata, query fingerprints, schema structure and configuration values. PII is excluded by the way Sixta queries a database, not stripped out after collection. No row-level data is accessed or transmitted at any point.

[table-1]

Air-gapped deployment is available. Sixta can run entirely inside your network against a locally hosted model such as Ollama or vLLM, and in that configuration nothing leaves your infrastructure at all.

What Sixta does not do

No Sixta telemetry is sent back to Sixta the company. No usage data, metrics or diagnostics are collected from a customer deployment. Analytics on the marketing site use memory-only persistence and set no cookies.

02. Permissions model

Sixta operates at two distinct access levels. Read-only covers every diagnostic function, which is the great majority of what Sixta does. Autonomous permissions are optional, separately credentialed and individually grantable: enabling parameter tuning does not enable index creation, and neither is enabled by installing Sixta.

PostgreSQL, minimum read-only

[table-2]

MySQL, minimum read-only

[table-3]

Observability platforms

Where you already run an observability platform, Sixta reads from it rather than duplicating collection. Every integration is read-only and scoped.

[table-4]

03. Network posture

Sixta deploys inside your infrastructure: VPC, on-premise or air-gapped. Outbound, it connects to the configured LLM endpoint and, if you use the Slack or Teams integrations, to api.sixta.ai for websocket coordination.

[table-5]

On api.sixta.ai: this relay handles Slack and Teams websocket coordination only. No customer data flows through it. It is not required for API-only access, for custom integrations, or for air-gapped deployments.

In air-gapped mode, with a locally deployed model and custom output integrations, no outbound connections are required at all.

04. Autonomous actions and guardrails

Autonomous actions are off by default. Each action type is enabled independently and requires its own database credential. Every action is written to the audit trail before it executes, not after.

[table-6]

05. Audit logging

Every Sixta action, whether diagnostic, autonomous or a message sent to a channel, produces a structured audit record. Records are stored locally and can be forwarded to your SIEM or log aggregator.

The general action log below is written on every tool invocation, with 90-day default retention.

[table-7]

Parameter change operations log additional fields: the dry-run flag, the score before the change, the workload type, per-parameter detail (knob, previous value, new value, applied, error) and rollback status.

06. Deployment options

[table-8]

Setup timeline

Day 1. Deploy Sixta, grant read-only credentials, connect observability.

Week 1. Sixta observes, establishes baselines and produces its first diagnostic reports.

Week 2 onwards. Optionally enable autonomous actions, once you have reviewed the recommendations Sixta has been making and can see what it would have done.

Questions

The full technical reference, including grant SQL, network diagrams and the complete audit schema, is available on request. Write to ewen@sixta.ai.

<table><thead><tr><th>Data category</th><th>Contents</th><th>Destination</th><th>Leaves network?</th></tr></thead><tbody><tr><td>Database telemetry</td><td>Query metrics, execution plans, lock and session data, replication status, schema metadata</td><td>Processed locally within customer infrastructure</td><td>No</td></tr><tr><td>LLM reasoning context</td><td>Performance metadata, query fingerprints, table names, configuration values</td><td>Configured LLM endpoint (Anthropic API, internal, or local)</td><td>Configurable</td></tr><tr><td>Findings and recommendations</td><td>Root-cause analysis, remediation recommendations, alerts, status updates</td><td>Slack, Teams, API, or custom integrations</td><td>Configurable</td></tr><tr><td>Observability enrichment</td><td>Metrics, logs, APM traces, incidents and SLO data from existing platforms</td><td>Ingested from CloudWatch, Datadog or Percona PMM</td><td>No (pulled in)</td></tr></tbody></table> <table><thead><tr><th>Privilege</th><th>Purpose</th><th>Mode</th></tr></thead><tbody><tr><td>pg_monitor role</td><td>Session stats, replication stats, all pg_stat_* views</td><td>Read-only</td></tr><tr><td>SELECT on pg_stat_statements</td><td>Query risk analysis and performance baselining</td><td>Read-only</td></tr><tr><td>Standard catalog access</td><td>pg_class, pg_locks, pg_settings (via pg_monitor)</td><td>Read-only</td></tr><tr><td>pg_table_size(), pg_total_relation_size(), pg_indexes_size()</td><td>Capacity and growth tracking. Available to all roles by default.</td><td>Read-only</td></tr><tr><td>ALTER SYSTEM (PG 15+) or superuser (PG 14 and below)</td><td>Parameter tuning, separately credentialed. In PG 15+, superuser can grant ALTER SYSTEM on individual parameters; in PG 14 and below, superuser is required.</td><td>Autonomous (opt-in)</td></tr><tr><td>Table ownership on target tables</td><td>CREATE INDEX CONCURRENTLY</td><td>Autonomous (opt-in)</td></tr><tr><td>pg_signal_backend</td><td>Terminate runaway queries</td><td>Autonomous (opt-in)</td></tr></tbody></table> <table><thead><tr><th>Privilege</th><th>Purpose</th><th>Mode</th></tr></thead><tbody><tr><td>SELECT on performance_schema, sys</td><td>Wait events, statement history, thread activity</td><td>Read-only</td></tr><tr><td>PROCESS</td><td>Active connections, SHOW ENGINE INNODB STATUS, EXPLAIN FOR CONNECTION</td><td>Read-only</td></tr><tr><td>REPLICATION SLAVE</td><td>Topology detection via SHOW REPLICAS</td><td>Read-only</td></tr><tr><td>SYSTEM_VARIABLES_ADMIN</td><td>Runtime parameter tuning via SET GLOBAL</td><td>Autonomous (opt-in)</td></tr><tr><td>INDEX on target schemas</td><td>CREATE and DROP INDEX</td><td>Autonomous (opt-in)</td></tr><tr><td>CONNECTION_ADMIN</td><td>KILL runaway queries</td><td>Autonomous (opt-in)</td></tr></tbody></table> <table><thead><tr><th>Platform</th><th>Credentials</th><th>Access level</th></tr></thead><tbody><tr><td>AWS</td><td>IAM role (recommended), IAM user access keys, or AWS CLI profile</td><td>Read-only: Performance Insights, CloudWatch, CloudWatch Logs, RDS Describe* APIs</td></tr><tr><td>Datadog</td><td>API key plus scoped application key</td><td>Read-only: metrics, events, monitors, logs, APM, incidents, SLOs</td></tr><tr><td>Percona PMM</td><td>Grafana service account token (Viewer)</td><td>Read-only: metrics, QAN, inventory, alerts</td></tr></tbody></table> <table><thead><tr><th>Connection</th><th>Direction</th><th>Protocol</th><th>Data</th><th>Required?</th></tr></thead><tbody><tr><td>Database instances</td><td>Sixta to DB</td><td>PostgreSQL / MySQL, TLS required</td><td>Performance metadata only, no row data</td><td>Yes</td></tr><tr><td>LLM endpoint</td><td>Sixta to LLM</td><td>HTTPS</td><td>Query fingerprints, metadata, configuration values</td><td>Yes (can be local)</td></tr><tr><td>api.sixta.ai relay</td><td>Sixta to and from relay</td><td>WSS (443)</td><td>Slack and Teams websocket coordination only</td><td>Only for Slack/Teams</td></tr><tr><td>Observability platforms</td><td>Sixta to API</td><td>HTTPS</td><td>Metric queries, event correlation</td><td>Optional</td></tr><tr><td>Output integrations</td><td>Sixta to target</td><td>HTTPS / webhook</td><td>Findings and recommendations</td><td>Configurable</td></tr></tbody></table> <table><thead><tr><th>Action</th><th>Scope</th><th>Guardrails</th><th>Status</th></tr></thead><tbody><tr><td>Parameter tuning</td><td>ALTER SYSTEM SET (PG), SET GLOBAL (MySQL), ModifyDBParameterGroup (RDS)</td><td>Dry-run by default; previous values recorded for automatic rollback</td><td>Live</td></tr><tr><td>Index creation</td><td>CREATE INDEX CONCURRENTLY</td><td>Query risk analyser produces exact DDL with risk classification</td><td>Planned</td></tr><tr><td>Query termination</td><td>Terminate runaway queries exceeding defined thresholds</td><td>Duration and resource threshold; query can be re-executed by the application</td><td>Planned</td></tr><tr><td>Vacuum / Analyze</td><td>VACUUM and ANALYZE based on the vacuum advisor</td><td>Maintenance operation; always safe to run</td><td>Planned</td></tr></tbody></table> <table><thead><tr><th>Field</th><th>Type</th><th>Description</th></tr></thead><tbody><tr><td>id</td><td>ULID</td><td>Time-sortable unique identifier</td></tr><tr><td>timestamp</td><td>UTC ISO 8601</td><td>When the action occurred</td></tr><tr><td>tool</td><td>string</td><td>e.g. vacuum_advisor, tune_apply, query_risk_analyzer</td></tr><tr><td>instance_id</td><td>string</td><td>Logical instance name, e.g. prod-pg</td></tr><tr><td>action_kind</td><td>string</td><td>result (auto-stored tool output)</td></tr><tr><td>severity</td><td>enum</td><td>info | warn | critical</td></tr><tr><td>params</td><td>JSON</td><td>Original invocation parameters</td></tr><tr><td>data</td><td>JSON</td><td>Full tool output (complete assessment or result)</td></tr><tr><td>summary</td><td>string</td><td>One-line human-readable description</td></tr><tr><td>db_engine</td><td>enum</td><td>postgresql | mysql</td></tr><tr><td>expires_at</td><td>timestamp</td><td>Retention expiry, 90 days by default</td></tr></tbody></table> <table><thead><tr><th>Option</th><th>LLM access</th><th>Network</th><th>Best for</th></tr></thead><tbody><tr><td>Standard SaaS</td><td>Anthropic API</td><td>Outbound HTTPS to api.anthropic.com</td><td>Fastest deployment; most teams</td></tr><tr><td>Private LLM</td><td>Customer-hosted (Ollama, vLLM, etc.)</td><td>LLM stays in-network; Sixta outbound optional</td><td>Regulated environments; data sovereignty</td></tr><tr><td>Fully air-gapped</td><td>Local model plus custom integrations</td><td>Zero outbound connections</td><td>Highest security; no external dependencies</td></tr></tbody></table>
Subjects
Security and trust

More from this category

Database Observability vs Monitoring

Your database monitoring dashboard says everything is green. Your users are reporting errors. Both things are true at the same time, and the gap between them is where incidents live.

Read more

The Real Cost of Database Incidents

When a database goes down, the first question is always "how do we fix it?" The question that rarely gets asked until later, sometimes much later, is "what did that actually cost us?" The answer is usually worse than anyone expected.

Read more