How we keep your data safe.

Principles

Proxima reads your email, watches your calendar, and lives in your team chat. The only way to earn that level of access is to be deliberate about how the data is handled. The four principles underneath every decision below:

• Least privilege. Each agent gets only the OAuth scopes it actually uses; each team member gets only the permissions they need; production access is gated and audited.
• Encryption end-to-end. Everything in transit. Every credential at rest. Customer data at rest in the database.
• Approval at the gate. No outbound action — email, calendar, message — leaves Proxima without an explicit human approval. The audit log is the contract.
• Boring by default. Managed services we trust, well- known patterns, no clever cryptography. Most security incidents come from novelty; we minimize ours.

Encryption

In transit

• All traffic to and from the Proxima dashboard, bot, and APIs uses TLS 1.2 or higher. We disable older protocols and weak cipher suites at the load balancer.
• HSTS is enforced on all marketing and product domains. Strict-Transport-Security: max-age=63072000; includeSubDomains.
• Inter-service traffic inside our private network also uses mTLS where the underlying transport supports it.

At rest

• All managed-database storage is encrypted with AES-256 (Postgres / Cloud SQL on Google Cloud).
• All object storage (backups, exports, image uploads) is encrypted with AES-256.
• Sensitive secrets (OAuth refresh tokens, signing keys, third-party API keys) are double-encrypted: the database is encrypted, AND the individual rows are encrypted with envelope encryption using a key stored in Google Cloud KMS. See Credential storage below.

Key management

Encryption keys are managed by Google Cloud KMS. Application-level credential encryption keys are rotated quarterly. Old keys are kept for the retention window of any data they encrypted, then destroyed.

Access controls

Customer access

• Sign-in is via Discord OAuth. We never store your Discord password and never see it.
• Workspace roles (owner, member) gate what actions a user can take within a workspace. Permissions are checked on every server-side request — no client-side enforcement.
• Users in workspace A cannot read or write data in workspace B, ever. This is enforced at the database query layer with explicit workspace-scoped predicates and unit-tested with multi-tenant boundary tests.

Employee access

• Production access is granted on a per-role basis to the smallest number of engineers practical. A typical engineer has read-only access; write access is granted per-incident.
• All employee access requires multi-factor authentication. Passwordless (FIDO2) is preferred where the system supports it.
• Production access is audit-logged. Logs are retained for 12 months and reviewed quarterly.
• Employees do not read customer email, calendar, or message content unless we have your explicit consent for a specific item, doing so is necessary for security purposes (e.g. investigating abuse), or we’re legally required to.
• Access is revoked within one business day of an employee leaving.

Infrastructure

Proxima runs on Google Cloud Platform in US-based regions (currently us-east1 and us-central1for redundancy). We’ll add EU regions when we have demand for it.

• Compute runs on managed services (Cloud Run, GKE Autopilot) with automatic patching of the underlying OS.
• Networks are isolated per environment. Production and staging share no compute or data.
• Database uses Cloud SQL with HA replication, point-in-time recovery, and 30-day encrypted backups.
• Edge traffic goes through Cloudflare for DDoS protection, WAF, and bot detection.
• Secrets are stored in Google Secret Manager. No secrets in code, no secrets in environment files committed to version control.

Application security

• Dependency monitoring. Every push runs Snyk and Dependabot. Critical and high vulnerabilities are patched within 48 hours; medium within 14 days.
• Static analysis. We run TypeScript strict mode and ESLint with security-focused rules on every PR. Known dangerous patterns (raw SQL string interpolation, unscoped DB queries) fail the build.
• Code review. Every change to production-bound code is reviewed by at least one other engineer before merge.
• SSRF / SMTP injection / authz bypass.We’ve audited every outbound HTTP call for SSRF, every SMTP-bound code path for header injection, and every internal tool that takes a workspace argument for unscoped queries. New code added to these surfaces requires explicit security review.
• Output encoding.All user-generated content is escaped for the surface it’s rendered into. Discord messages are rendered as plain text by default.
• Rate limiting. All public endpoints are rate- limited at the edge. Authenticated APIs are additionally throttled per workspace and per user.

Data handling

What we collect, where it lives

A summary; the full breakdown is in the Privacy Policy.

• Account data (Discord identity, workspace membership) — primary database, encrypted at rest.
• OAuth refresh tokens — primary database, additionally encrypted with envelope encryption (see below).
• Email / calendar / Notion / lead data— read on demand and held only as long as the agent is processing it. We don’t maintain a long-term mirror of your inbox.
• Approval audit log — primary database, retained for 24 months.
• Application logs — Google Cloud Logging, retained for 90 days, with sensitive fields redacted at the source.

What we deliberately don’t do

• Train AI models on your data.Not ours, not a third party’s. Our LLM provider (Anthropic) doesn’t train on data sent through their API.
• Sell or rent your data. Not to advertisers, not to data brokers, not to anyone.
• Log message bodies. Application logs record the shape of an operation (which agent, which approval, which workspace) but not the substantive content of the email or calendar event.

Credential storage

OAuth refresh tokens are the most sensitive thing we hold. They are stored as follows:

1. The refresh token is encrypted with AES-256-GCM using a per-row data key.
2. The data key is encrypted with a Key Encryption Key (KEK) stored in Google Cloud KMS.
3. The encrypted refresh token and the wrapped data key are stored together in the credentials table.
4. On read, the application decrypts the data key via KMS, then the refresh token via AES-GCM, in memory only. The plaintext is never written to disk or logs.

A separate credential service with a hardened API surface owns the read/write path; application servers never touch the credentials table directly. Credentials cannot be exfiltrated by a SQL-level read of the database alone — the attacker would also need access to KMS, which is gated by per-environment IAM roles.

Approval audit trail

Every outbound action ever surfaced by an agent — every email drafted, every calendar event proposed, every Discord message considered — is recorded in the workspace audit log along with:

• which agent generated the action, with model + version;
• the prompt context used;
• the user who approved, edited, or skipped;
• the timestamp;
• the final outbound payload (only on approval).

The audit log is append-only at the application layer. Workspace owners can export it at any time. We retain it for 24 months, consistent with the Privacy Policy.

Monitoring & incident response

Monitoring

• Application metrics, error traces, and access logs are streamed to Google Cloud Logging and a dedicated SIEM.
• Anomaly detection on authentication events, OAuth-token usage, and admin-action events.
• On-call engineers get paged on availability incidents within 5 minutes of detection.

Incident response

• We follow a documented incident-response runbook. Incidents are triaged to severity (S1–S4) within 15 minutes of detection.
• Data-breach notification.If we suffer a personal- data breach, we’ll notify affected customers within 72 hours of becoming aware of it, with the information we have at that point. We’ll follow up as the investigation continues.
• Public post-mortem. For S1 incidents we publish a post-mortem within 14 days on /status. We name the cause, the fix, and what we’re doing to prevent recurrence.

Vendor management

Every sub-processor is reviewed before onboarding for security posture, data-residency, and contractual commitments. Sub-processors that access personal data are bound by Data Processing Agreements with terms substantially equivalent to the ones we offer our customers in the Proxima DPA.

We re-review each sub-processor at least annually, and immediately on any material security event affecting them.

Sub-processors

When we add or change a sub-processor, we’ll update this list and email customers who’ve subscribed to sub-processor changes. To subscribe, email privacy.proxima@dterminal.netwith the subject “Subscribe: sub-processors”.

Compliance & posture

Proxima is early-stage and intentionally honest about which formal attestations we have today versus what we’re working toward.

Today

• GDPR / UK GDPR ready. We act as a data processor for customer data and offer a DPA incorporating the EU Standard Contractual Clauses and the UK IDTA.
• CCPA / CPRA ready. California residents have all rights described in the Privacy Policy.
• Google API Services User Data Policy compliance, including Limited Use. See Privacy → Google Workspace data.

In progress

• SOC 2 Type II.We’re running through Drata and expect to complete our Type I by end of 2026 and Type II roughly six months after that.
• HIPAA, PCI-DSS.Not in scope today. We don’t handle PHI or cardholder data and don’t recommend using Proxima for those workloads until we are.

Vulnerability disclosure

We welcome reports from security researchers. If you believe you’ve found a vulnerability in Proxima, please email us at security.proxima@dterminal.netwith the details and a way to reproduce it. We’ll respond within one business day.

Safe harbor

We won’t pursue legal action against good-faith security research that:

• does not access or modify data belonging to other customers;
• does not degrade availability of the service for other customers;
• does not exfiltrate data; uses test accounts or your own workspace wherever possible;
• gives us reasonable time to fix before public disclosure (we ask for 90 days; longer for systemic issues).

Out of scope

• Findings already known to be public.
• Self-XSS, missing security headers without a demonstrable impact, rate-limit issues without a working DoS, social engineering of our staff or customers.
• Issues in third-party services we don’t control.

Contact

For security questions, vulnerability reports, or to request a copy of our security questionnaire response, email security.proxima@dterminal.net.

For privacy / data-subject requests, email privacy.proxima@dterminal.net.