Trust · Standards

Every standard we claim, and who checked it

29 entries. Each one carries a basis, which says how far the check went and who did it. Read the basis before the claim.

No entry is audited. No third party has examined the platform and issued a report. Everything below is our own assessment, a gate we run ourselves, a control in the product, or a public specification we implement.

Audited0 entries

A third party examined this and issued a report we can show you.

Nothing sits on this basis. No third party has examined the platform and issued a report. When one has, the report will be linked here.

Readiness4 entries

The internal work is done. No report has been issued, and we describe it as readiness until one is.

Standard	What we claim	What you can look at
ISO/IEC 27001	An information security management system is established and a Statement of Applicability is complete. No accredited certification body has audited us.	The ISMS document set and the Statement of Applicability.
SOC 2 Type I	Readiness work is complete. No report has been issued.	The readiness document set. The letter will be linked here when an auditor produces one.
SOC 2 Type II	Not started. Type II needs an observation window that cannot begin before Type I.	Nothing yet.
Penetration test	No external firm has conducted one.	Nothing yet.

Self-attested3 entries

Our own assessment, on our own authority. No outside opinion stands behind it.

Standard	What we claim	What you can look at
NIST SSDF (SP 800-218)	The platform is built to the Secure Software Development Framework, and a self-attestation to the CISA common form is being assembled. The enforced practices below are its evidence.	The pipeline gates listed under Enforced in the pipeline.
NIST AI RMF	The reasoning engine is governed with the AI Risk Management Framework’s vocabulary — the same measure-and-manage functions the product gives customers.	The crosswalk in the product, with its controls and their evidence links.
Section 508 · WCAG 2.1 AA	A VPAT 2.4 is produced from the internal audit log. WCAG 2.1 Level AA and the Section 508 Refresh are targeted across every public surface. No Level AAA target is claimed.	The VPAT, and the automated check that runs on every marketing route on every change.

Enforced in the pipeline8 entries

A gate in the build pipeline fails the change when this lapses.

Standard	What we claim	What you can look at
Software Bill of Materials (CycloneDX)	Every released image gets an SBOM, validated against the frozen dependency set before it is signed, and bound to the image digest.	The container provenance workflow, and its SBOM check step.
Build provenance (SLSA)	Each build emits signed provenance binding the artifact digest to the source commit and the pipeline run that produced it. A moving tag is never attested.	The signed attestation on each released image digest, recorded in a public transparency log.
Dependency and vulnerability scanning	Dependencies are scanned on every change by three scanners, and the change fails when a finding crosses the threshold.	The security scan workflow and the three scanner configurations in the repository.
Static analysis (SAST)	Every change runs static analysis, and a high-severity, high-confidence finding fails the build.	The SAST gate in the security scan workflow.
Secret scanning	Every change is scanned for credential material, and a hit fails the build.	The scanner configuration in the repository.
Least-privilege pipeline	Pipeline tokens are scoped to read by default, third-party actions are pinned to a commit, and a job asks for more only when it needs it.	The permission blocks and pinned action digests in every workflow.
Automated accessibility checks	Every shared component and every public page carries an automated accessibility test, and a violation fails the build.	The component and page-level test suites.
Plain-word and sentence-shape gates	A controlled vocabulary and a set of banned sentence shapes are checked on every change across the site and the knowledge base.	The vocabulary rule and the voice test in the repository.

In the product8 entries

A control that exists in the shipped product today.

Standard	What we claim	What you can look at
Phishing-resistant sign-in (WebAuthn)	Passkeys are available on platform-hosted origins and an organization can require them. A passkey is bound to this site and cannot be replayed against a lookalike.	The passkey screens in your account settings.
AES-256-GCM at rest	Secret material is sealed with AES-256-GCM. The encryption library is a hard dependency with no fallback, so a deployment missing it fails to start.	The sealed secret store behind every connected account.
Default-deny authorization	Access is refused unless a rule grants it, and separation between accounts is enforced at the data layer.	The roles table and the audit log that records every grant.
Guarded outbound requests	A step reaches the hosts its bound connectors name and nothing else. Every URL is resolved and checked before connection and again on each redirect, and private and metadata addresses are refused.	The reachable set printed on every agent, and the connector bindings behind it.
Append-only record	Every step is written to a hash-linked chain that is never rewritten. Any holder of the entries can recompute every hash without a key.	The derivation is published, and a runnable verifier ships in the repository.
Human confirmation on sensitive actions	A sensitive action is held for a person. Nothing reaches your systems until someone approves, and the approval is written down with the approver on it.	The review queue and the decision record behind each call.
Customer-accessible audit log	Admins read who changed a role, a key, or a setting in their own work area. It is append-only, and secret material is stripped before an entry is written.	The audit log screen, and its CSV export.
Data deletion and export	Events, watched things, and a whole work area can be deleted, and an account can export what it holds.	The deletion and export screens, and the record each one writes.

Conformance6 entries

A public specification the platform implements, so other software interoperates with it. This makes no quality claim.

Standard	What we claim	What you can look at
OpenTelemetry	The standard signal paths are accepted, so an existing collector needs one more exporter target. Traces are processed today; metrics and logs are accepted with processing still in build.	The integration page states which signals are processed.
MCP	The platform exposes its doors as tools over the open tool protocol.	The tool list and the scope each tool needs.
OAuth 2.0 authorization code	Connected accounts use the authorization-code grant with refresh. Nine providers are in the registry, and the picker reports which ones this deployment holds a registration for.	The provider picker on a feed, and its availability column.
OpenAPI	The whole API is published as a versioned OpenAPI description.	The published description and the reference generated from it.
CycloneDX	SBOMs are produced in CycloneDX, so any standard tool reads them.	The SBOM attached to each released image digest.
SAML	An organization can sign in through its own identity provider.	The sign-in settings on your organization.

How to check this page yourself

The record derivation is published, and a runnable verifier ships in the repository. An evidence pack is checked from the file alone, with no key for three of the four checks. The four checks.
Build provenance and the SBOM are attached to each released image digest and recorded in a public transparency log. Ask for the digest and check it against the log.
The accessibility check runs on every public route on every change. The accessibility statement.
Send a security finding to security@dmzagent.com. We confirm receipt and tell you what we are doing about it.

This register describes the platform as it stands today and changes when the platform does. See also the trust and security page for subprocessors and the certification status table.