Security by subtraction
The most secure data is data that never leaves your machine, and the second most secure is data nobody else on that machine can read. Instead of hardening a cloud full of customer data, we removed the cloud, then encrypted what stays under a key only you hold. What follows is how the runtime actually behaves, and every claim here can be checked against the software you install.
Local by default
The web interface binds to localhost out of the box. Nothing on your network can reach it unless an administrator explicitly turns on network access, and that switch is a single, deliberate setting. Exposure is opt-in, never a surprise.
Zero telemetry
The runtime contains no analytics, no crash uploaders, and no phone-home of any kind. Logs are written to local files on your disk and stay there. You do not have to take our word for it: run the host with a network capture attached and watch what leaves the machine. With only local models configured, the answer is nothing.
Egress under your control
Outbound calls happen only to model and service providers you configure, using keys you supply. Beyond that, both the whole installation and any individual agent can be marked local-only: a local-only agent is denied cloud access altogether and works purely with on-box models. Every time data does leave, for a cloud model, an Internet tool, or a channel reply, the Egress Audit records it with the agent and provider involved, and the Session Inspector shows the run.
Sandboxed execution
When agents run scripts or shell commands, the default execution mode is a Docker container with the agent workspace mounted in, not your host machine. Running directly on the host exists as an explicit administrator choice, clearly labeled as unsafe, and script execution can be disabled entirely.
Your data is files you own
Conversations are plain files under your own user folder, one transcript per chat, not rows in a shared database. You can open them, back them up, or delete them with a file manager and no help from us. An administrator can export the whole environment as one passphrase-protected backup that Oscova cannot open without that passphrase.
Confidential agents
Any custom agent can be switched to Confidential Chat. From then on its chat titles, messages, tool calls and results, rendered instructions, saved sessions, and the stored runs of its scheduled tasks are encrypted on disk. Only the running host, with your vault unlocked, can read them. Confidential conversations never feed memory, search, or reflection, cannot be exported, and hooks receive only the shape of an outcome, never its content. A confidential task due while the vault is locked is skipped rather than run in the clear.
Encrypted files
A confidential agent also gets its own file tools that read, write, edit, and patch encrypted files inside its workspace. The filename stays visible; the content is authenticated ciphertext under the same key. Ordinary file tools, the shell, and the sandbox cannot decrypt it, and the built-in editor opens it only after you unlock the vault.
Incognito chats
Start any chat as Incognito and it is never written to disk and never added to memory. It is deleted, with its attachments, when you sign out, after about thirty minutes idle, or when the app restarts. Incognito governs what is kept, not what is sent: a cloud model chosen for that chat still receives the messages you send it.
Keys you hold
Every user sets a Vault Password at first sign-in. It wraps a per-user encryption key that protects saved API keys, connected-account tokens, and all confidential data. The key exists only in memory while the vault is unlocked; a restart locks it until the password is entered again, and we cannot recover a forgotten one. We chose this over the operating system keyring on purpose: the whole environment can be backed up and restored on another machine, and each person unlocks their own data with their own password there.
Where this fits
These properties, together, are what let Oscova run in places ordinary assistants are kept out of: a clinic, a law practice, a bank branch, an accounting firm, a research lab under NDA, a security team, a newsroom protecting a source. Those settings do not fail on model quality. They fail on three questions: does it leave the building, who can read it on the disk, and what happens under pressure. The answers here are behavioral. We do not claim a certification for your sector; we give you a runtime whose behavior you can verify against your own policy.
Reporting a vulnerability
If you believe you have found a security issue, please report it privately through GitHub security advisories on github.com/oscova rather than in a public issue. We will acknowledge the report, fix confirmed issues, and credit you if you wish. There is no bug bounty program at this time, only our genuine thanks.