Security

Iro is built so a stranger's app is safe to install. The kernel owns trust: signature checks, consent, install, credentials, permissions and routing. Stores and catalogs only ever request.

What the kernel guarantees

• No Electron in the kernel. Shell things go through the HostAdapter.
• Credentials never leave the kernel. ctx.http is performed by the kernel, tokens go only to the credential's own API origins, redirects are never followed, and known secrets are scrubbed from responses.
• Caller identity is the channel, never an id the caller sends.
• Fail closed. An unanswerable permission check denies; an un-loggable call never returns its result.
• Service code runs in a hardened Deno subprocess inside a deny-default OS sandbox. Workers get no file permissions — host.fs is brokered by the kernel with realpath + O_NOFOLLOW_ANY checks.
• App views are isolated: per-app session, iro-app:// handler, per-app egress proxy, no DNS outside the kernel proxy, CSP without unsafe-eval.
• Consent is Iro UI only, hanging over Iro's own title bar with every app view hidden. Runtime prompts show in Iro's prompt window over the window that asked.

Packages

Signed .iropkg files (Ed25519, key rotations, publisher pins that outlive uninstall). Only the kernel downloads (https only, ≤ 5 redirects, ≤ 100 MiB, checked in memory, unpacked from the same bytes). Updates need a newer version from the pinned key; anything else is refused, never shown. Rollback restores the kept version without granting anything new. Catalogs are static signed JSON; revocation disables the app but keeps its data.

Reporting a vulnerability

See SECURITY.md in the repo (disclosure address) once published. Do not open a public issue for a suspected vulnerability. The full threat model lives in the docs.