Security & Trust
We are asking for a path into production. Here is exactly what that path looks like.
Every control on this page is one your security team can verify: a role grant, a certificate, a signature, a retention period.
Architecture
What connects to what
What the agent probes on first connection is the seven-dimension topology discovery, and everything downstream of it — detection, the advisor, the action plane and the gate — is described layer by layer on the platform page.
There is nothing behind this page that this page does not say. The six blocks below are the whole path in detail: the role your DBA creates and what it may read, what crosses the boundary in each direction, how one tenant is kept away from another, what a ledger entry's signature covers, how the artifacts are signed, and how long anything is kept.
How the agent connects
- One agent per tenant, never shared between customers. Runs as a container, a Kubernetes Deployment or sidecar, or a native package with systemd.
- Database access through a read-only monitoring role. No superuser. Managed clouds can use IAM authentication instead of a stored password.
- A small, capped, read-only connection pool with short statement, lock, and idle-in-transaction timeouts, so monitoring can never become the load.
- Agent identity is a private key that never leaves the host. First boot enrols and receives a short-lived mutual-TLS client certificate that renews itself before expiry.
What leaves your database
- Metrics, catalog metadata, execution plans, and query text. Literals in query text are scrubbed on the agent before transmission. Parameter capture is off by default.
- Row data never leaves. Oversized plans are truncated. Timestamps are server-side.
- Query text is classified confidential, stored encrypted, not indexed for search, and visible only to owners of your tenant.
- Platform keys and similar secrets found in query text are masked before capture.
Isolation and encryption
- Every tenant row is protected by database row-level security, forced on. Warehouse queries carry an explicit tenant predicate and events are partitioned by tenant with per-tenant access controls.
- Modern TLS in transit everywhere. Per-tenant data-encryption keys at rest, held in your cloud provider's secrets manager.
- Cross-tenant access exists only for support with an explicit bypass that is itself written to the trust ledger.
The trust ledger
- Append-only, per tenant, chain-hashed, and cryptographically signed with keys that rotate on a schedule. Periodic snapshots give inclusion proofs for any entry.
- Verify a range from the console or through the MCP server. Export in a documented format for auditors.
- Retention is long-term. Deletion requests are met by destroying the tenant key, which makes the data unreadable while the chain stays intact.
Supply chain
- Container image, Helm chart, and native packages are all signed. The public key is published so you can verify before you install.
- A software bill of materials is attested to every image. The install script verifies the release signature before it runs.
- Continuous vulnerability scanning with defined triage and patch windows by severity.
Retention and residency
- Defined retention per data class, from raw metrics through session history to the long-lived ledger, configurable where it matters.
- You choose the region at deployment. EU residency is available through a dedicated EU-region deployment.
- Control-plane data is retained for the life of the tenant plus a soft-delete window, then hard-deleted.
Proof, not logs
A log can be edited. A chain cannot.
Every observation, decision and action, by a human or by an agent, lands in a per-tenant, append-only ledger. Each entry carries a hash of its own payload and a hash of the entry before it, then the whole thing is signed. Change one entry and every entry after it stops verifying.
- entry 1
anomaly observed
- payload hash
- …21a0f
- prev hash
- genesis
- signature
- valid
- entry 2
fix proposed
- payload hash
- …28a1f
- prev hash
- …21a0f
- signature
- valid
- entry 3
human approved
- payload hash
- …35a2f
- prev hash
- …28a1f
- signature
- valid
- entry 4
action verified
- payload hash
- …42a3f
- prev hash
- …35a2f
- signature
- valid
Verify any range yourself, from the console or through the MCP server. Hand the export to an auditor without translating anything.
Verifying a range, the snapshot proofs and what an auditor export contains are covered in the trust ledger section of the platform.
Compliance
SOC 2-aligned controls, audit underway
Our control set is mapped to the SOC 2 trust services criteria and an independent audit is in progress. Enterprise customers receive the current readiness report and the control matrix under NDA.
- GDPR data processing agreement available on request, with a subprocessor list and advance notice before any new subprocessor receives data.
- Singapore PDPA as the primary regime for DBExplore Pte. Ltd., GDPR for EU data subjects.
- Security questionnaires answered promptly, with the control matrix under NDA.
- MFA mandatory for all staff, quarterly access review.
Subprocessors
| Provider | Purpose | Location |
|---|---|---|
| Amazon Web Services, or Google Cloud / Azure per deployment | Infrastructure, KMS, email | Region you select |
| Anthropic | Claude API for advisor narratives | United States |
| PagerDuty | Alert delivery | United States |
| Slack | Alert delivery and approvals | United States |
| GitHub | Artifact distribution | United States |
| Sentry | Error telemetry, scrubbed | United States |
Report a vulnerability
Email security@dbexplore.com. We acknowledge quickly and keep you informed until the fix ships. Our security.txt carries the same contact.
Security questions we get on the first call
Do you need superuser?
No. The agent uses a read-only monitoring role. On managed clouds it can authenticate with the provider's IAM instead of a stored password.
Can I run the agent in my VPC without outbound internet?
Yes for self-hosted deployments, where the agent talks only to your own control plane. For SaaS, the agent needs outbound HTTPS to the DBExplore edge over mutual TLS.
How do you handle a data deletion request?
We destroy the tenant data-encryption key promptly on request, which renders every encrypted record unreadable while the signed ledger chain stays intact, and complete the remaining deletions within a defined window.
Can we get a DPA and a subprocessor list?
Yes. Both are available on request, and subprocessor changes are announced in advance before any new processor receives data.
Send this page to your security team.
Then let us walk them through the agent threat model and the ledger verification live.