Permissions & security

Installing an app on Kiki is safe by design. Every app runs with exactly the permissions you approved — and the system physically prevents it from doing anything else.

You approve what each app can touch

When you install an app, Kiki shows you precisely what it's asking for — a folder, the microphone, part of your vault, the ability to reach the network — and you approve it. These are scoped: an app asks for a folder, never "all your files." You can review or revoke any of it later in Settings, and across a whole fleet from the dashboard.

An app can never quietly reach something you didn't grant. If it tries, the action simply fails.

This check sits in front of every action, every time — so what you approve at install is the whole of what an app can ever do.

Each app is boxed in

Beyond permissions, Kiki isolates each app so a problem in one can't spread. The riskier the code, the stronger the wall around it:

App	How it's isolated
Everyday apps and tools	Run in their own locked-down space, walled off from the rest of the system.
Apps that show a window	The same, plus a filter on what they can do to the screen.
Externally-written agent code	Runs in its own hardware-isolated virtual machine — the strongest boundary Kiki has.

That last row matters: code an AI generated or that came from outside is treated as untrusted by default and gets the strongest possible boundary, so it can't touch the rest of your device.

For developers

If you're building an app, declare the minimum it needs — a tight permission set is approved faster and fails safe. Permissions are validated at compile time and enforced at runtime:

#[kiki::app(id = "io.kiki.player", type = DesktopApp)]
#[kiki::requires(Capability::AudioOutput)]
struct Player { /* ... */ }

Capabilities cover the filesystem, the network, hardware (audio, GPU, USB), the screen, and agent control — each scoped to a specific resource. See Build apps for the full model.