Security

1. Our approach

NeuralOS is a platform operated by Klinworks, LLC where individuals and teams work with AI agents, automations, and apps. That means we look after valuable information: your account, the content of your workspace and, often, the credentials your agents use to act in other services.

We practice defense in depth: several independent layers of protection, so that if one fails, the others still contain the risk. On this page we describe only measures we already apply in the product. Anything that is still a goal is clearly labeled as such.

This page complements our Privacy Policy, our AI Use Policy, and the list of subprocessors.

2. Infrastructure

NeuralOS relies on established infrastructure providers rather than operating its own data centers. The complete named list is on Subprocessors.

• Security headers: the API applies hardened HTTP headers and a CORS policy restricted to our own origins.
• Rate limits: the API limits request rates using a shared store, so limits hold even when several replicas are running.
• Least privilege: infrastructure credentials live only in the provider's environment variables, never in code or in the database.

3. Encryption

• In transit: connections to neuralos.io and to the API use HTTPS/TLS; unencrypted requests are redirected to HTTPS.
• At rest: the database and file storage are encrypted at rest by our data provider.
• Application-level secrets: on top of provider encryption, we encrypt the most sensitive data ourselves with AES-256-GCM (authenticated encryption) before storing it.
• Envelope encryption: each secret gets its own random data key, which is in turn wrapped by a master key. This lets us rotate master keys without exposing data, and a compromised data key affects a single secret.
• Bound to context: each encrypted secret is cryptographically bound to its workspace or user; copied to another context, it simply will not decrypt.
• Fail closed: if an integrity check fails, the operation is rejected; partial data is never returned.

4. Your own keys (BYOK) and integration credentials

You can connect your own AI provider keys (BYOK, "bring your own key") and third-party integration credentials. We treat them as the most sensitive data on the platform:

• they are encrypted with a key specific to your workspace before being stored;
• they are never shown in full again after you save them (you only see a masked version) and are never written to logs;
• they are decrypted only at the moment they are used for the call that needs them;
• you can revoke or replace them at any time from your workspace.

Master encryption keys are never stored in the database or in the code repository, and an automated secret scanner blocks any change that tries to include one.

5. Authentication and access control

Your account

• Two-step verification (2FA): works with any TOTP app. The secret is stored encrypted, and backup codes are stored hashed and are single-use.
• Revocable sessions: you can see your active sessions and sign out of one or all of them. Changing your password signs out your other sessions, and we notify you by email.
• Anti-bot and anti-enumeration: sign-up and sign-in are protected with Cloudflare Turnstile, and sign-up does not reveal whether an email already has an account.
• Credential handling: authentication is handled by Supabase Auth; we never store plaintext passwords.

Your workspace

• Row-level isolation: tables holding customer data have PostgreSQL row-level security (RLS) enabled, so the database only returns rows from the workspace you belong to.
• Roles: each member has a role (owner, admin, member, or viewer), and the API checks that role before every sensitive action.
• Internal access: Klinworks, LLC personnel access customer data only when needed to provide support, investigate an incident, or comply with the law.

6. AI agent security

Agents can read, write, and act on your behalf. That is why we constrain them by design:

• Explicit permissions: an agent only uses the tools, integrations, and knowledge sources you grant it.
• What matters waits for your signature: consequential actions (for example, spending or external sends) can require human approval, and every approval or rejection is recorded along with who made it.
• Untrusted content: we treat external content an agent reads (web pages, documents, emails) as data, not as instructions, to reduce the risk of prompt injection. No defense is perfect: review what an agent proposes before approving it.
• Model providers: prompts are sent to the providers listed on Subprocessors solely to generate the response. More details in the AI Use Policy.

7. Secure development

Every API code change goes through a continuous integration pipeline that must pass before it is deployed:

1. Secret scanning (gitleaks): no key or password can enter the repository.
2. Database security gate: reviews Supabase security advisories (for example, tables without RLS) and blocks the change if any are found.
3. Strict type checking, linting, and formatting.
4. Automated tests with minimum coverage thresholds, including integration tests against a real database.
5. Production build.

The web application also has its own guardians that verify the contracts between the web app and the API. Data schema changes are made only through versioned migrations.

8. Monitoring and logging

• Append-only audit log: relevant actions (role changes, billing, agents, automations, and more) are recorded with who, what, and when. A trigger in the database itself prevents those entries from being changed or deleted, even with direct access.
• Immutable payment ledger: balance movements and payments are also recorded append-only.
• Health monitoring: an external guardian checks every 15 minutes that the website and API respond, and every 6 hours runs the full sign-in flow, just as a real user would. Any incident is recorded immediately for the team.
• Errors: we use Sentry to detect and diagnose failures, with limited technical data.
• Service status: see /status.

9. Incident response

If we detect or are told about a security incident, we follow this process:

1. Detection and assessment: we confirm scope and severity.
2. Containment: we isolate affected systems, revoke exposed credentials, and rotate keys where appropriate.
3. Notification: if an incident affects your personal data, we notify you without undue delay and, where required, notify the competent authorities within legal deadlines (for example, 72 hours under the GDPR).
4. Recovery: we restore service and verify that the cause has been fixed.
5. Learning: we analyze the root cause and add controls so it does not happen again.

10. Responsible disclosure

We are grateful to those who research in good faith and help us protect our users. If you find a vulnerability in neuralos.io, its subdomains, or the NeuralOS API, email us at ceo@neuralos.io with:

• a description of the issue and its potential impact;
• steps to reproduce it (and, if you can, a proof of concept);
• your preferred contact method.

We ask that you: not access, modify, or delete other people's data; not degrade the service (no denial-of-service testing, spam, or social engineering of our team or users); use only your own or test accounts; and give us reasonable time to fix the issue before publishing anything.

We commit to: acknowledge receipt, keep you informed of progress, credit your contribution if you wish, and not take legal action against good-faith research carried out under these rules. We do not currently run a paid bounty program.

11. Compliance and certifications

We only claim certifications we actually hold.

Our main infrastructure providers hold their own certifications, which you can review in their trust centers. When we pass an audit, we will reflect it here.

12. Your part in security

Security is shared. We protect the platform; you control who gets into your account and what your agents can do. We recommend that you:

• turn on two-step verification and keep your backup codes somewhere safe;
• use a unique password and do not share your account;
• give each member and each agent only the permissions they need;
• review the actions an agent proposes before approving them;
• rotate your BYOK keys if you suspect they have been exposed, and sign out of sessions you do not recognize;
• tell us right away if you notice suspicious activity.

If you build apps with NeuralOS, you are responsible for the security of their logic and of your own end users' data.

13. Changes to this page

We continuously improve our security measures and will update this page to reflect them. The last-updated date appears at the top. If a change materially reduces the level of protection described here, we will give at least 30 days' notice.

14. Contact

For any security question, or to report a vulnerability or an incident, email ceo@neuralos.io. If it is urgent, include URGENT in the subject line.

Klinworks, LLC · a Delaware limited liability company (USA) · file number 10704723.