Security
How Arq handles data, deployment, authentication, and what we do and don't claim about compliance. Written for the procurement and security-review conversations a serious enterprise buyer runs.
Data boundaries
What stays in your infrastructure, what may leave under your control, and what never leaves. The first question your security reviewer will ask.
- Arq Signals snapshots (telemetry, catalog views, counters)
- Arq Analyzer output (findings.json, report.json)
- Arq Workbench — operator UI, hosted by you
- License activation files (offline-activated)
- Audit log content (server-side, in Workbench's store)
- Tickets you push to GitHub Issues, Jira, or your tracker
- Outbound destinations are your operator-configured integration credentials — never Elevarq
- You choose which findings to push, what fields to include, and when
- PostgreSQL query text and result data
- Raw snapshot row content beyond what is shown to you
- Telemetry to Elevarq — no phone-home, no anonymous usage stats, no crash reports without explicit consent
- License activation does not require internet at runtime
Deployment model
Arq is single-tenant and customer-installed. One Arq deployment per organization, running entirely in your infrastructure. Container-based — Docker Compose or Kubernetes — with persistent volumes for the Workbench store and the license artefact. No cloud dependency for core functionality.
The license is an Ed25519-signed JSON file. Activation is offline: upload the activation artefact via the Workbench setup wizard once, and the deployment runs from there without an internet round-trip. An anti-reuse ledger lives in the Workbench's local SQLite, so the same license cannot be reactivated in a different deployment without re-issuance.
Airgapped environments are a supported case, not an afterthought: the only outbound network requirement at install time is the container registry pull. Everything after that runs inside your perimeter.
Authentication, audit, and secret handling
Operator authentication
Local email + password (argon2id with conservative cost parameters and complexity rules), or OIDC single sign-on (Authorization Code flow with PKCE). One identity provider per deployment, strict admin-email binding, server-side session with sliding plus hard expiry, double-submit CSRF on mutating routes, rate-limited login.
Analyzer authentication
Imports from the Arq Analyzer to Workbench use a separate bearer-token channel, stored as bcrypt hashes. Analyzer tokens do not grant access to the operator UI — separation is enforced at the API layer.
Audit log
Every push attempt (success or failure), every status transition on a finding, every credential addition or removal, and every operator login is captured in a server-side audit log with a closed event schema. Events carry classification codes for downstream review; secret values are redacted at the emission boundary.
Integration credentials
Encrypted at rest with AES-256-GCM. The key is derived through HKDF from a workspace seed that is established at first install and never leaves the deployment. Workbench exposes no admin endpoint that returns plaintext credentials.
PostgreSQL access
Arq Signals connects with pg_monitor role privileges — read-only across the catalog and stats views. No writes, no schema changes, no superuser, no agent processes on database hosts.
Support bundles
If you choose to share a support bundle with Elevarq for troubleshooting, the bundle is generated and reviewed locally first. You decide what to redact and what to send. We do not collect support data automatically and do not receive raw operational state by default.
Compliance posture
What we claim — and what we deliberately don't.
Arq is designed for auditability and aligned with SOC 2 and ISO/IEC 27001 controls — change management, access control, audit trail, documented operating procedures. We are not certified, and we will not claim to be. If your procurement process requires a current certification on file, Arq is not the right fit today.
The framing matters because security reviewers we respect ask what evidence backs each claim, not what logo is on the website. The data-boundary table above, the authentication/audit section, the open-source nature of Arq Signals, and the offline-activatable license model are the actual evidence — verifiable by anyone running Arq in their infrastructure.
Specific control families we map to: SOC 2 CC8.1 (change management — issue → reviewed PR → signed commit); CC6 (logical access — OIDC + bound admin email + audit log); ISO/IEC 27001 A.8.32 (change management), A.5.37 (documented operating procedures), A.5.24 (incident preparation). Mapping documents are available on request under NDA.
For security reviewers
The questions procurement and security teams ask, answered concretely.
- Where does Arq run?
- In your infrastructure. Single-tenant, container-based, persistent volumes for the operator store and license. No shared cluster, no managed-SaaS offering.
- What does Arq access in our PostgreSQL?
- Read-only access via the
pg_monitorrole. Catalog views and statistics views only. No DML, no DDL, no superuser, no replication privileges, no agents on database hosts. - Does Arq exfiltrate query content?
- No. Snapshots contain telemetry, catalog views, and counters — no query text or row content beyond what the standard
pg_stat_*views expose. Snapshots stay in your network. - Does Arq phone home?
- No. License activation is offline. There is no telemetry, no anonymous usage statistics, no crash reports sent without explicit operator consent.
- How is access to Workbench controlled?
- Local email + password (argon2id) or OIDC single sign-on. The admin email is bound to a single identity provider per deployment. All operator actions are captured in a server-side audit log.
- How are integration credentials stored?
- Encrypted at rest with AES-256-GCM. The key is derived from a workspace seed established at install time, via HKDF. Workbench does not expose plaintext credentials through any admin endpoint.
- What's the support-bundle / data-sharing model?
- No automatic data collection. Support bundles are generated and reviewed locally; the operator decides what to redact and what to share. We do not receive raw operational state by default.
- Is the source code auditable?
- Arq Signals is open source under BSD-3-Clause — github.com/Elevarq/Arq-Signals. The Arq Analyzer and Workbench are commercial; source review for enterprise security teams is available under NDA.
- Do you have SOC 2 or ISO 27001 certification?
- No. Arq is designed for auditability and aligned with both control families; we are not certified, and we will not claim to be. If a current certification is a hard requirement for your procurement, Arq is not the right fit today.
- How do we report a vulnerability?
- Email security@elevarq.com. We will acknowledge receipt and coordinate disclosure with you.