kosa8 security: one sealed machine per agent, with every control on your side

01What an AI agent sandbox has to stop

A coding agent runs code it just wrote or downloaded, and text it reads (a README, an issue, a tool description) can steer it. kosa8 assumes the worst case: an attacker controls what the agent reads and has root inside the agent's machine. Under that assumption a sandbox has to keep the agent away from the host's files, sockets and other sandboxes; decide every packet on the host; keep real credentials out of the guest; hold risky actions for a person; and leave a record nobody can quietly edit.

02The isolation model: a microVM per sandbox

Each sandbox is a hardware-virtualised microVM with its own kernel, its own disk and its own private network. On an Apple silicon Mac kosa8 uses Apple's Virtualization framework; on x86-64 Linux it uses Cloud Hypervisor on KVM. An agent inside sees the one folder you shared and nothing else on your computer.

kosa8 is three programs: the kosa8 command, the kosa8d service, which runs as your user without administrator rights, and kosa8-guestd, a helper inside each VM. The helper is on the untrusted side; nothing the service decides depends on it telling the truth.

One distinction matters: kosa8 run and the Docker-compatible API use one shared VM, where containers are separated from each other by ordinary container isolation. kosa8 sandbox and kosa8 agent run give each workload a VM of its own, and a signed organisation policy with require_sandbox makes that mandatory.

03Network rules and the egress broker

Network rules are enforced on the host, in the userspace network that every frame from the VM crosses, so root inside the guest cannot lift them. The rules exist before the VM boots. DNS is answered by the host, for listed names only. Refused attempts are written to the audit log.

API keys stay with the egress broker in kosa8d. A brokered sandbox holds a placeholder that is worthless anywhere else; the broker admits hosts by name and port and adds the real key on the way out.

That prints the policy in force and how many frames and DNS answers were passed or refused.

04Approvals for risky actions

kosa8 classifies actions by blast radius: read-only, contained, destructive and escalating. Destructive actions, and escalating ones that widen the boundary (host mounts, network egress, the policy itself), ask every time and cannot be auto-approved.

For tool calls through the kosa8 MCP gateway, an organisation's signed rules can answer allow, deny or ask. A call held for a person is approved for exactly that call, once, for ten minutes:

When the signed policy lists named approvers, an escalating action needs approvals signed by those people (kosa8 approve request, then kosa8 approve sign). The service re-verifies them, refuses replays and records them.

05The audit log

Every state-changing request, brokered network request, refused connection, MCP tool decision and signed approval is written to ~/.kosa8/audit.jsonl with its actor (human, agent, tool, guest or policy). Only the service writes it. Each entry carries a keyed hash (HMAC-SHA256) linked to the one before, a sealed record of where the chain ends, and an Ed25519 signature anyone can check with the public key.

Reads, tool arguments and results (stored as SHA-256 digests), environment variables, request bodies and API keys are left out on purpose. kosa8 audit export --format cef feeds a SIEM, and kosa8 evidence export writes a signed package an assessor can check offline. See AI agent governance evidence.

06How releases are built, signed and checked

• macOS. Binaries are signed with a Developer ID and notarised by Apple. kosa8.app is also stapled, so Gatekeeper can check it offline; the plain zip archives are notarised but not stapled, so Gatekeeper checks them with Apple at first launch.
• Windows. kosa8.exe is Authenticode-signed with Azure Trusted Signing, and an unsigned build fails the publish job.
• Checksums. Every release ships checksums.txt. The install script refuses to install without it, and when a release carries a cosign signature over that file it checks the signature too.
• The pipeline. A v* tag first builds and tests the full matrix (make check, make test) without signing anything, then hands off to a separate signing workflow, the only place the signing credentials are held. In kosa8's release workflows, third-party GitHub Actions are pinned to commit hashes.

Check a download yourself:

The first should report OK for each file you downloaded; the second should show a Developer ID signature, not adhoc.

07FIPS 140-3 builds for government

A separate government channel builds kosa8 against Go's FIPS 140-3 cryptographic module, using the module snapshot that has completed CMVP validation, with fips140=on as the run-time default. Before anything ships, the workflow runs the whole test suite under the module and checks every shipped binary's build settings. Its checksums are signed keylessly with cosign against the workflow's own identity, recorded in the public Rekor transparency log, and each archive comes with a CycloneDX SBOM. Builds go to a private release repository, from vX.Y.Z tags only.

A FIPS build reports crypto: on. An organisation can require the module in its signed policy, and the daemon then refuses to start without it. The validation belongs to Go's module, not to kosa8 as a product. Ask contact@kosa8.com about access.

08Privacy: no telemetry

The kosa8 software has no telemetry, no crash reporting and no analytics. Sandboxes, files, commands, snapshots, prompts and audit logs stay on your machine. With a paid licence the software activates and revalidates the key with Polar, the merchant of record, and reports aggregate usage counts once a day for billing; KOSA8_OFFLINE=1 or a signed site licence turns that off. The website sets no cookies. The details are in the privacy policy.

09Threat model, and what kosa8 does not protect against

kosa8's threat model treats the agent's inputs as attacker-controlled and grants the attacker root inside the guest. The trusted base is the host operating system, the user account kosa8 runs as, and kosa8d. The hypervisor is assumed to separate guest and host memory correctly. Stated plainly, kosa8 does not protect against:

• A hypervisor escape. A bug in the virtualization layer would break the boundary. It is a smaller surface than a shared kernel, not zero.
• Anything running as you on the host. A process under your account can call the service as a person, read ~/.kosa8 and approve a held call. A malicious host root can stop the daemon and rewrite local state, which is why the audit log should be forwarded off the machine.
• Misuse of what you allowed. An allowed host that accepts uploads is a way out for data. The broker's placeholder is spendable along its route while the sandbox runs. HTTPS tunnels to allowed hosts are opaque, and request and response bodies are not inspected.
• Prompt injection itself. kosa8 bounds what a hijacked agent can do; it does not stop the model reading hostile text. First-use tool pinning trusts the first definition a server gives unless the organisation's policy lists the pins.
• Open defaults. A sandbox you create by hand with no network flag has an unrestricted network unless the organisation sets default_egress. Agent-created and brokered sandboxes are closed by default.
• Side and timing channels, the contents of the images you run, and the host's own hardening and disk encryption.

kosa8 has not yet had an external penetration test and has no SOC 2 report. The research paper sets out the threat model, the security goals and the residual risk for each.

10How to report a vulnerability

Email contact@kosa8.com with a description, steps to reproduce, and the output of kosa8 version --json. Please give us a chance to fix the issue before you publish it. Do not include other people's data in a report.

11Questions

Does an AI agent in a kosa8 sandbox share my computer's kernel?

No. Each kosa8 sandbox is a microVM with its own Linux kernel, on Apple's Virtualization framework on a Mac or Cloud Hypervisor on KVM on x86-64 Linux. The exception is kosa8 run and the Docker-compatible API, which share one VM; kosa8 sandbox and kosa8 agent run give each workload its own.

Can code inside the sandbox read my API key?

Not for brokered credentials. The key stays with the egress broker on the host, and the sandbox gets a placeholder that is worthless anywhere else. The placeholder can still be spent along its allowed route while the sandbox runs, so scope the key at the provider too.

Does kosa8 send telemetry?

No. The software has no telemetry, crash reporting or analytics. A paid licence talks to Polar to activate the key and reports aggregate usage counts once a day; KOSA8_OFFLINE=1 or a signed site licence turns that off.

How do I check that a kosa8 download is genuine?

Compare it against the release's checksums.txt with shasum -a 256 -c, and on a Mac run codesign -dv and spctl -a -vv on the binary to see a Developer ID signature and the notarisation. The install script checks the checksum for you.

12Guides and deep dives

• Docker containers vs microVMs: which isolates an AI agent better?
• How do I restrict an AI agent's network access to an allow-list?
• How do I give an AI agent API keys without exposing them?
• How do I require human approval before an AI agent runs a risky command?
• What an audit log for AI agents should record
• Prompt injection, API keys and the egress broker
• Research: sealed machines for autonomous agents

14Try it on your own machine

kosa8 installs with one line on macOS and Linux. Sandboxes run locally on Apple silicon Macs and x86-64 Linux.

Download kosa8 See pricing