Trust & Security

Last updated: June 12, 2026

DeployMill is the neutral, agent-safe control plane for shipping web apps. Our customers connect an AI coding agent (Claude, Codex, any MCP client) and hand it the deploy lifecycle: creating projects, deploying, managing previews, domains, databases, and rollbacks. The entire product thesis is that it is safe to give an autonomous agent the keys to production.

That makes security the product, not a feature of it. An agent platform that treats guardrails as an afterthought is asking you to trust a stochastic process with your production environment. We built the guardrails first (secret values the agent can never see, previews that can't touch prod data, automatic rollback when a deploy fails its health gate, and an audit trail that attributes every change), then built the deploy tools on top of them.

This page is the hub: it summarizes our security posture in plain English and links to every policy in the set. If your enterprise review needs an answer that isn't here, email [email protected].

Our security posture

Secrets & the zero-readback vault

The single most important guardrail in DeployMill is that the AI agent never sees a secret value.

• Org-scoped secrets are encrypted at rest with AES-256-GCM in DeployMill's vault.
• Secret values are entered by a human, through a single-use browser hand-off link. The agent requests a secret slot. A person fills it in. The value never transits the agent's connection.
• Secrets are never returned to an MCP client, never echoed into a tool response, and never appear in an agent transcript. There is no "read secret" tool, by design.
• When an app needs a secret, DeployMill injects it server-side into the app's runtime environment. The agent can bind a secret to an app by name. It can never read one.

The same posture applies to DeployMill's own infrastructure credentials (container registry tokens, cluster credentials, database and storage keys): clients authenticate to DeployMill with an OAuth access token, and every backend credential stays server-side. No tool response ever contains one.

Tenant isolation

Every workspace (organization) is a separate tenant, isolated by construction:

• Apps, secrets, databases, domains, and audit records are all org-scoped. Every query and every tool call is checked against the calling token's organization.
• Tenant app pods are isolated from each other with Kubernetes NetworkPolicy, so one customer's workload cannot reach another's.
• OAuth tokens never cross workspace boundaries. A token minted for one organization cannot read or mutate another's resources.

Authentication & access

• MCP clients and API consumers authenticate with OAuth 2.0 + PKCE, with Dynamic Client Registration, via Better Auth. Access tokens are short-lived. We do not hand out static API keys to clients.
• Humans sign in with Google, GitHub, or email. Enterprise SSO (OIDC/SAML) is available for organizations that need centralized identity.
• Workspace administration (members, roles, invites, SSO configuration) is deliberately human-driven, with role-based access. Agents ship apps, and people run the workspace.

Agent-safety guardrails

Beyond who can call the API, DeployMill bounds what an autonomous agent can break. These are product-level guardrails, built into the deploy lifecycle:

• Full preview isolation. Every preview gets a copy-on-write database branch and a fresh volume/bucket. An agent experimenting in a preview is structurally incapable of corrupting production data.
• Auto-rollback on a failed health gate. Deploys are health-gated rolling updates. A deploy that fails its health check is rolled back automatically. A bad agent-driven deploy self-heals instead of taking you down.
• Dry-runnable diff/plan/apply. The reconcile flow shows what would change before anything mutates production, so agents (and humans) can review the plan first.
• Append-only, attributable audit trail. Every mutating action is recorded with who (or whose agent) performed it. You can always reconstruct what changed, when, and on whose authority.
• Scoped, short-lived git credentials. When an agent needs repository access, it receives narrowly scoped, expiring credentials (get_clone_credentials), never a long-lived personal token, and never the platform's own source credentials.

For the full picture of what agents can and cannot do, see AI Agent Access & Safety.

Encryption

• In transit: TLS/HTTPS everywhere, covering the dashboard, the MCP API, and every deployed customer app. Certificates are provisioned and renewed automatically via Let's Encrypt.
• At rest: secret values are encrypted with AES-256-GCM in the vault. Platform data lives in managed Postgres. See Subprocessors for exactly where each category of data is stored.

Infrastructure & availability

• Compute runs on self-operated Kubernetes (k3s) with health-gated rolling updates, so new versions only take traffic once they prove healthy.
• Ingress is Caddy with automatic Let's Encrypt TLS.
• Databases are managed Postgres (internal default, or Neon / Supabase, your choice per project), source lives in GitHub, and object storage is Cloudflare R2, all behind provider-neutral interfaces, all enumerated in Subprocessors.
• Uptime commitments and service credits are defined in the SLA.

Monitoring & incident response

The control plane is instrumented with OpenTelemetry: traces, metrics, and logs to an observability backend (Grafana Cloud or any OTLP endpoint), with alerting bridged into our issue tracker so anomalies become tracked work, not lost pages. Telemetry covers DeployMill's own operations, not your app's data (again, Subprocessors spells out the boundary).

If an incident affects the confidentiality or integrity of customer data, we notify affected customers without undue delay, consistent with the DPA.

Compliance & certifications

We'd rather be honest than impressive here:

• DeployMill is building toward SOC 2. We run an internal weekly audit process across security, compliance, privacy, and performance, so the controls are being exercised continuously, not assembled the week before an audit.
• Current certification status: [confirm current certification status]. We do not currently claim SOC 2, ISO 27001, HIPAA, or PCI DSS certification. When that changes, this page will say so plainly.
• GDPR / CCPA: we offer a DPA, maintain a current Subprocessors list, and honor data-subject rights as described in the Privacy Policy.

If your procurement process needs a security questionnaire completed or more detail than this page provides, email [email protected].

Data privacy

We collect what we need to run the platform and no more. What we collect, why, how long we keep it, and how to get it deleted are covered in:

• Privacy Policy: what we collect and your rights.
• Data Retention & Deletion: how long each category of data lives and how deletion works.
• Subprocessors: every third party that receives data, what they receive, and why.

Shared responsibility

Security on DeployMill is shared, the same way it is on any platform:

• DeployMill secures the platform: the control plane, the secrets vault, tenant isolation, the deploy pipeline, TLS, and the guardrails described above.
• You secure your application: your code, its dependencies, the data your app collects, and what you instruct your agent to do. The guardrails bound an agent's blast radius, but they don't review your application logic.

The full division of duties, including the agent-specific responsibilities unique to an agent-driven platform, is laid out in Shared Responsibility and AI Agent Access & Safety.

Report a vulnerability

We work with security researchers, and we say thank you. If you believe you've found a vulnerability in DeployMill, email [email protected]. Our Vulnerability Disclosure policy covers scope, rules of engagement, our safe-harbor commitment, and what to expect after you report.

Policy index

Contact

• Security & vulnerability reports: [email protected]
• Privacy requests: [email protected]
• Everything else: [email protected]