Trust · Security
What we protect, how, and where each claim stands.
Customers route their own records through DMZAgent. Every claim below carries its basis: who checked it, how far the check went, and what you can look at.
Certification status
Readiness, an auditor’s report, and a certificate are three different states, and each row below says which one applies. The standards register carries every standard, protocol and practice we claim, with the basis of each claim beside it.
| Framework | Where we are |
|---|---|
| ISO/IEC 27001 | ISMS established and a Statement of Applicability completed internally. Not certified — no accredited certification body has audited us. |
| SOC 2 Type I | Readiness work complete. No report issued. We will link the letter here when an auditor has produced one. |
| SOC 2 Type II | Not started. Type II requires an observation window that opens once Type I closes. |
| Penetration test | Not yet conducted by an external firm. |
| Section 508 · WCAG 2.1 AA | VPAT 2.4 produced, and every marketing route is checked automatically on every change. See accessibility. |
Standards we adopt as practice
The standards below are self-attested: we do the work and attest to it on our own authority, with no third-party opinion. Each one names a practice the build pipeline enforces today.
| Standard or practice | Where we are |
|---|---|
| NIST SSDF (SP 800-218) | We build to the Secure Software Development Framework and are assembling a self-attestation to the CISA common form. The practices below are its evidence. |
| Software Bill of Materials | A signed SBOM is produced for every build and validated before it is signed, so a release can always be traced to the exact components it shipped. |
| Build provenance (SLSA) | Each build emits signed provenance binding the artifact to the exact source commit and pipeline that produced it. |
| Supply-chain integrity | Dependencies and secrets are scanned on every change, the pipeline’s own dependencies are pinned and its token least-privileged, and infrastructure changes pass an automated policy gate before merge. |
| NIST AI RMF | We govern the reasoning engine with the AI Risk Management Framework’s vocabulary — the same measure-and-manage functions the product gives customers. |
A standard that needs an outside auditor to be claimed stays in the status table above until one has looked. The full register labels every entry with its basis, including the ones a build gate enforces and the specifications we implement for interoperability.
Subprocessors
Third parties that may process customer data on our behalf, and what each one is for.
| Processor | Purpose | What it can see |
|---|---|---|
| Cloudflare | Hosting, compute, database, object storage, and the network edge. The whole platform runs here. | All customer data at rest and in transit. |
| Anthropic | Model inference behind the reasoning engine. | The content of records submitted for reasoning, at the moment they are reasoned over. |
| Stripe | Payment processing and subscription billing. | Billing contact and payment details. Card data travels from the browser to Stripe directly and does not reach our servers. |
| Resend | Transactional email — sign-in links, notifications. | Recipient email addresses and message contents. |
Identity providers you connect yourself — Microsoft Entra ID, Google Workspace, Okta, or a SAML provider — are your systems, under your own contracts with those vendors. Our processing begins at the assertion they hand us, which is why they sit outside this list.
Controls in the product today
- Phishing-resistant sign-in. Passkeys (WebAuthn) are available on DMZAgent-hosted origins, and an organization can require them of its members. A passkey signs only against the origin that created it, so a lookalike domain collects nothing it can use.
- Secrets encrypted with AES-256-GCM. The encryption library is a hard dependency with no fallback path: a deployment missing it fails to start.
- Default-deny authorization. Access is refused unless a rule grants it, and the data layer enforces tenant isolation on every query.
- Guarded outbound fetches. Any URL a customer supplies is resolved and validated before we connect, then pinned to that validated address for the life of the request. A redirect issued afterwards lands on the same address.
- An append-only record. Observations are written once and kept. What the system knew, and when, stays answerable after the fact.
What we don’t claim
- Data residency. All customer data is processed in the United States. EU and other regional hosting are unavailable today.
- Third-party audit. Every row above marked readiness carries our own assessment. No outside auditor has issued an opinion on any of them.
- Uptime SLA. Self-serve plans carry no availability commitment. Enterprise agreements negotiate one, and the agreement is where it binds.
Reporting a vulnerability
Send it to security@dmzagent.com with the affected component, the steps to reproduce it, and the impact you believe it has.
We acknowledge receipt within 3 business days and send an initial assessment with a severity rating within 10. A critical finding gets a fix or a documented mitigation within 30 calendar days, a high finding within 90. These are the targets our security policy publishes, held by a small team in good faith.
Hold publication until the fix ships or until we agree a date with you, and we will not pursue legal action over the research. Tell us the name or handle you want in the advisory, and anonymous reporting is equally welcome.
Last reviewed 30 August 2026. This page tracks the platform, and changes when the platform does. For contractual terms — DPA, security addendum, negotiated SLA — write to security@dmzagent.com.