The safest place for your code is where it already is.

What we guarantee

• →Your code never reaches us. The indexing engine runs inside your own infrastructure. Source, embeddings and the knowledge graph are written to a database you control. None of it is transmitted to Oynix.
• →Your keys stay on your machine. Bring your own AI, embedding and database keys. They live on your engine and never touch our servers. When you rotate them, nothing on our side needs to change.
• →We ship the engine, not the vault. The hosted control plane holds only identity and access: who is on your team and what role they have. It is stateless with respect to your code and data.
• →Retrieval spends no tokens on us. Oynix answers as an MCP server. Your agent does the reasoning against facts we return. There is no model call on our side, so there is no prompt of yours passing through us.

Because your code, embeddings and connector data live in your own engine and database, Oynix the company cannot read them. This is not a policy we promise to follow. It is where the data physically is.

Who can see what

• →Roles. Master, Admin and Member. Billing and workspace deletion sit with Master. Configuration and integrations sit with Admin. Members query and use MCP. A workspace always keeps at least one Master.
• →Keys are credentials, not identities. A workspace key is a rotatable credential bound to a person. If one leaks, you rotate it without touching the user, the workspace or the data behind it.
• →Scoped, short-lived actions. When the control plane acts on your behalf, it uses short-lived, scoped credentials that are discarded after use. It never gains standing access to your engine.

Reporting a vulnerability

If you believe you have found a security issue, email security@oynix.dev. Tell us what you found and how to reproduce it. We read every report, we do not pursue researchers acting in good faith, and we will keep you posted while we fix it.