Security
Built so that trust is verifiable, not assumed
NodeOS records who did what, when, and on whose authority — including when the "who" is an AI agent. That only means something if the platform itself is airtight, so the controls below are enforced in the database and proven against the running system.
Controls in place
Every item below describes behaviour that exists in the running product today.
Database-enforced tenant isolation
Access is enforced in PostgreSQL with row-level security, not in application code. Reads and writes are evaluated against the caller's workspace membership, so a bug in the UI cannot widen access.
Scoped API keys for agents
Agent keys are hashed at rest and bound to one organization. Each key carries an explicit scope list, an access level and an optional area allow-list, and can be expired or revoked at any time.
Agents create, humans verify
An AI agent can open work sessions and submit or supersede its own delivery evidence, but it cannot verify that evidence. Verification is a separate permission boundary that always requires a human with the right role.
Separate internal and customer projections
Work items carry both internal technical notes and customer-facing descriptions. Customer access reads a controlled customer-safe projection, so internal detail is never exposed by accident.
Least-privilege database roles
Privileged helper roles are NOLOGIN and NOBYPASSRLS, and SECURITY DEFINER functions are not executable by anonymous callers. Secret columns such as API key hashes are not readable by application roles.
Hardened public endpoints
Public intake endpoints are JSON-only with body size limits, strict schema validation, honeypot fields and server-side rate limiting. Rate limiting for these public forms uses a peppered HMAC of the client IP, never the address itself.
Immutable delivery record
Work events, evidence and release snapshots are append-only. Each delivery gets an integrity confidence score derived from what is actually recorded, not from what someone typed in afterwards.
Audited API access
Authenticated API calls are recorded in a workspace-scoped audit log with the acting key, action, outcome and originating IP address, so agent activity can be reconstructed after the fact.
Continuous verification
Tenant isolation, IDOR and privilege-escalation paths are exercised by an automated end-to-end security suite that runs against live runtime behaviour, not just against source code.
What we deliberately do not do
- We do not let one workspace read another workspace's data — not through the UI, the API, or an agent key.
- We do not store raw client IP addresses for public form submissions.
- We do not allow an automated actor to verify its own delivery evidence.
- We do not expose secrets — API key hashes and webhook secrets are unreadable to application roles.
- We do not use your workspace content to train external models.
Reporting a vulnerability
If you believe you have found a security issue in NodeOS, tell us before disclosing it publicly. Send a description and reproduction steps through the access request form and mark it as a security report — it reaches a human on the engineering side.
We will confirm receipt, investigate, and keep you updated until the issue is resolved. We do not pursue legal action against good-faith research that respects customer data.
Contact the team