Krate
Read the permission request before execution
For a local bundle from a source you trust, inspect its capability information without executing the component:
krate run app.krate --dump-caps
Check the requested file scope, network destinations and media/device access against the app's purpose. A document viewer asking to upload data needs an explanation. The capability list is not a transcript of everything the code might do.
Review each grant when opening
krate run app.krate --prompt
The runtime checks host operations against session capabilities. Required capabilities that are not granted prevent the corresponding launch from proceeding; optional behavior and failure handling still need application testing. Avoid --auto-grant for an app you have not reviewed.
A grant can permit a damaging operation inside its allowed scope. Giving an app write access to a folder is not the same as proving it will preserve the contents. Use disposable copies of important data when evaluating software.
Where enforcement happens
The guest is a WebAssembly component. The normal app profile uses Krate's WIT interfaces rather than ambient host APIs; import validation and host-side capability checks are part of the boundary. File, network and UI implementations live in the native runtime, not in a permission dialog that the guest controls.
Explore the interface definitions, policy implementation and architecture guide. Packaging/import checks and runtime enforcement have different jobs: passing the first is not an audit of the second.
What is outside the guarantee
- Application correctness, data integrity and honest behavior inside granted access.
- The security of your machine, coding agent, dependency installer or build toolchain.
- Protection against every runtime, compiler, driver or host-adapter vulnerability.
- A claim of production hardening against deliberately hostile third-party code.
Building downloaded source is a separate trust decision from running a packaged guest: build scripts and external authoring tools are not automatically inside the app sandbox. Review dependencies and use an appropriately isolated development environment.
A practical review checklist
- Obtain the bundle and source from an identifiable publisher.
- Record its version and hash; a hash only helps when compared with a trusted reference.
- Inspect permissions before executing it.
- Try it with non-sensitive data and the narrowest useful access.
- Test what happens when access is refused.
- Recheck the artifact and permission request after changes.
See the current security limitations and the project's security reporting policy. Krate is not a reason to run unknown internet code casually.
Questions
Where does an app keep its data?
In storage of its own, kept per app, which it has to declare in its permission request. It does not get a folder on your disk unless you grant one or pick a file for it.
What can a Krate app do without asking?
Only harmless things: open its window, draw, play sound, read the clock and language settings, and show a dialog. Files, the network, the camera, the microphone and its own storage must be declared and approved.
Does a permission screen prove the app is safe?
No. It limits what the app can reach. Within what you allow, the code can still be wrong, so review what it asks for and grant only what the task needs.
Can an app ask for more access while it runs?
No. Everything an app can reach is declared in its manifest and shown before it opens. A new need comes in a new version, and you see that request before the new version opens.
Can I see what an app asks for without running it?
Yes. krate run app.krate --dump-caps prints the request without granting anything or starting the app.
Does Krate replace my operating system's protections?
No, it adds a layer. Gatekeeper and SmartScreen still check the Krate runtime itself; Krate then decides what each app inside it may touch.