OpenShell runtime
Agent and plugin work runs inside OpenShell policy sandboxes. Docker-based boxes connect through an mTLS gateway, and generated PKI is mounted into the web and worker registration paths.
- Default egress is denied until OpenNeko adds explicit policy endpoints.
- Landlock filesystem confinement and seccomp syscall filtering limit what sandboxed code can touch on disk and which system calls it can make.
- The gateway endpoint is addressed as an HTTPS OpenShell gateway with mTLS auth.
- OpenShell state lives under the user's home directory on macOS and OrbStack, and under /var/lib/openneko/openshell on Linux.
- Per-run broker tokens bind org and run identity before privileged operations are accepted.
Model secrets
Model provider keys are registered with the OpenShell provider and gateway proxy. The sandbox receives placeholder credentials and key aliases; the real key is injected on the wire by the proxy.
This boundary means agent code can call the approved model endpoint without gaining direct access to the provider API key. The same pattern applies to policy-managed egress for data sources and broker access.
Secrets at rest
Local OpenNeko secrets use the enc:v1 cipher: AES-256-GCM keyed from ~/.config/openneko/secret-key. Plugin secrets live in ~/.config/openneko/secrets.json with 0600 permissions and should not be copied into openneko.plugins.json or action request payloads.
- Rotate the secret-key intentionally because it protects local encrypted secrets.
- Treat marketplace and plugin install settings as configuration, and keep secrets out of them.
- Use OpenShell credential injection for runtime access instead of writing provider keys into the sandbox filesystem.
- An optional Infisical backend manages secrets across a deployment; without it, secrets stay in the encrypted local files above.
SSO and MFA
SSO is plugin-backed. The web app starts signin, but the auth plugin runs in the worker sandbox and keeps IdP client secrets out of the browser. Session cookies are signed with OPENNEKO_SESSION_SECRET.
Behavior alarms
Behavior alarms are runtime sweeps gated by the behavioral_alarms feature. They watch for unusual control-plane call volume, action request volume, and memory write volume.
| Environment variable | Default | Alert kind |
|---|---|---|
| OPENNEKO_BEHAVIOR_MAX_CP_CALLS_PER_RUN_10M | 200 | control_plane_call_volume |
| OPENNEKO_BEHAVIOR_MAX_ACTIONS_PER_HOUR | 50 | action_request_volume |
| OPENNEKO_BEHAVIOR_MAX_MEMORY_WRITES_PER_HOUR | 100 | memory_write_volume |
