Built for procurement from day one.
ZeroMan.ai operates on a least-privilege model with auditable decisions, governed agents, and a published responsible-disclosure path. This page is the running source of truth for design partners and enterprise buyers.
A deliberately narrow public surface.
ZeroMan.ai's public site is a marketing, research, resource, and contact surface. It does not host customer production tenants, customer supply-chain data, or measured deployment claims.
Public pages are anonymous. Contact submissions collect only the fields shown on the form, preserve routing context, and are kept separate from public content. Administrative workflows are separated from the public site and backed by role-scoped controls in the supporting CMS schema.
The site publishes a sitemap, changelog, status page, link-audit coverage, and responsible-disclosure path so public changes and trust signals leave a trace.
Governance belongs inside the decision loop.
The product design centers on governed decision loops: sense, decide, optimize, govern, execute, and learn. Each loop is expected to carry intent, context, permissions, model inputs, candidate actions, approval boundaries, and a durable audit trail.
Customer-identifying data is designed to stay tenant-scoped. ZeroMan.ai does not claim permission to train shared foundation models on customer-identifying data; any tenant-specific learning or fine-tuning requires explicit agreement and a documented data boundary.
Autonomy is designed to be granted per decision loop, not globally. Human review, policy thresholds, and rollback paths are first-class product primitives.
Roadmap items are named as roadmap items.
For design partners, the production-readiness roadmap includes SSO/OIDC, formal incident response, regional data-residency options, tenant-boundary evidence, and a SOC 2 readiness path.
ZeroMan.ai does not currently claim a completed SOC 2 report, ISO certification, customer production deployment, or measured production results. Those artifacts will be published only when they exist and are approved for public use.
Design partners can request the current control narrative, data-scope model, and roadmap artifacts under the appropriate confidentiality path.
Report suspected vulnerabilities directly.
Security researchers, buyers, and design partners can report suspected vulnerabilities by email or through the security contact route. Please include affected URL or asset, reproduction steps, expected impact, and a safe contact method.
We aim to acknowledge good-faith reports within two business days, treat reports as confidential while we investigate, and coordinate remediation before public disclosure when a real issue is confirmed.
Please do not access, modify, delete, or exfiltrate data that is not your own. Testing must avoid denial-of-service, social engineering, spam, destructive actions, or attempts to bypass third-party terms.
What is current, committed, or still on the roadmap.
This matrix separates the public-site controls available today from product design commitments and design-partner production roadmap items.
| Control | Status | Description | Evidence |
|---|---|---|---|
| Data isolation | Design commitment | The public site does not host customer tenant workloads. Product data boundaries are designed around tenant-scoped data, loop-scoped context, and explicit data-sharing agreements. | Platform brief |
| Encryption in transit | Current | The public site and download assets are intended to be served over HTTPS/TLS in production. Local development uses localhost for verification. | Public status |
| Encryption at rest | Current | Current public-site data stores rely on managed-provider storage controls. Production customer encryption evidence will be documented in partner artifacts before production use. | Security follow-up |
| Access control | Current | Public pages are anonymous. Admin and content workflows are separated from the public surface and mapped to role-scoped access patterns. | Current controls |
| Audit logging | Design commitment | The public site models traceability through status, build log, changelog, and link audit reports. Product decision loops are designed to preserve input, option, approval, and action traces. | Changelog |
| Model/data usage | Design commitment | ZeroMan.ai does not claim permission to train shared foundation models on customer-identifying data. Tenant-specific learning requires explicit agreement and a documented boundary. | Governance model |
| Regional hosting/data residency | Roadmap | Regional tenancy and data-residency choices are part of the design-partner production roadmap. The public site is not evidence of a production customer residency commitment. | Production roadmap |
| SSO/OIDC | Roadmap | OIDC-based SSO for enterprise identity providers is planned for design-partner production readiness. It is not presented as live customer SSO today. | Security follow-up |
| RLS/tenant boundaries | Design commitment | The supporting CMS schema uses row-level-security patterns. Product tenant boundaries will be documented separately before production customer use. | Current controls |
| Incident response | Roadmap | The public reporting path is current. A formal production incident-response playbook, severity model, and customer notification workflow remain roadmap artifacts. | Responsible disclosure |
| Vulnerability disclosure | Current | A human-readable disclosure section and machine-readable security.txt are published with a direct security email. | security.txt |
| SOC 2 roadmap | Roadmap | SOC 2 readiness is a roadmap item. ZeroMan.ai does not claim a completed SOC 2 report, audit, attestation, or certification today. | Production roadmap |