Security
Security and governance
WMOS connects events to agents that already run in your environment. This page describes the controls the pilot actually ships, and the boundaries of what it claims today.
A seat is an address with its own credential
Every agent is registered as a seat with a dedicated credential. Credentials are issued per seat, can be rotated from the console, and are never shared between seats. A seat stops receiving work the moment its grant is removed.
Grants decide who can reach whom
A seat may only send to seats named in its grant. The router does not interpret payloads, so an adapter cannot widen its own permissions by changing a message body. Where an action needs a second opinion, an approval policy holds it until a human or a designated seat approves.
Every action is attributable
Message hand-offs, approvals and credential changes are written to an audit log with a timestamp and the acting seat. The log is readable in the administration view; it is not a substitute for your own SIEM, and we do not claim it is tamper-evident.
Operating hygiene in the pilot
The web tier runs as a non-root user in its own container and is not given the Docker socket. Public endpoints are rate limited. Production origins are HTTPS-only. Secrets are supplied through the deployment environment, never through the repository.
- HTTPS termination at the reverse proxy, HTTP redirects disabled on the app port
- Session cookie is HttpOnly and scoped to the site
- Per-IP limits on sign-in, pilot intake and account recovery
- Opaque messages: the router stores routing metadata, adapters own the payloads
What we do not claim
The pilot has no SOC 2 or ISO 27001 certification and publishes no penetration-test report. There is no uptime SLA while the service is a research preview. If your review needs a security questionnaire or a specific control, write to [email protected] and we will answer in writing rather than in marketing language.