Security
Put AI to work without giving it undefined authority.
OpenNeko separates the intelligence doing the work from the credentials, data access, policy, approvals, and durable records that control what the work can reach.
See a demoFour explicit boundaries
Private is a deployment choice. Control is a system design.
The useful question is not whether an AI system is “secure” in the abstract. It is where the system runs, what each identity can reach, where credentials live, and which actions may cross the boundary.
Customer-controlled deployment
OpenNeko is self-hosted through Docker in infrastructure the customer controls. Data and operating context remain in that deployment.
↗Explicit model path
Use a supported external model provider or a local model. A local model can keep inference inside the deployment perimeter.
↗Scoped data and identity
Data access follows the configured source, role, identity, and read or write boundary rather than an unrestricted shared agent credential.
↗Governed action
State-changing work is proposed, approved, blocked, or allowed according to policy. Important decisions and receipts remain attributable.
↗The threat model
Assume the agent can be manipulated. Limit what that can become.
OpenNeko treats model-written and third-party work as untrusted. A compromised agent cannot obtain the credentials held outside its sandbox or expand itself beyond the data, network, and action boundaries approved for the run.
Read the technical security modelCredentials
The real model credential stays outside the sandbox and is injected by the gateway on the wire.
Database
The sandbox does not hold database credentials; access goes through the governed control path.
Network
Agent and plugin execution uses default-deny egress with explicitly allowed destinations and binaries.
Actions
A compromised agent still cannot step outside the data and action authority made available to the run.
Deployment responsibility
Serious security claims need a clear system boundary.
OpenNeko contributes product controls. The customer still owns the security and compliance of the complete deployed environment.
OpenNeko
Sandbox and broker boundaries, application policy, approval flow, product identity records, action receipts, and documented audit behavior.
Customer deployment
Host and network security, database operations, backups, TLS, endpoint controls, identity-provider policy, retention, monitoring, and incident response.
Shared
Source permissions, model-provider choice, plugin allowlists, action rules, security profile, audit export, and evidence for the complete system boundary.
OpenNeko can contribute controls inside a customer-managed system boundary. It is not, by itself, a complete CMMC-certified or ITAR-compliant environment.
Review technical details ↗See it work
See OpenNeko work across your business.
Bring one expensive problem. See OpenNeko check the software involved, explain what is going wrong, and get the next action ready.
