Security as architecture: capabilities, scopes, origins, and isolation
Tauri's security model is the subject here: the policy that decides whether a parsed IPC request may reach a Rust command or a native resource. The key focus is contextual authority, not a flat list of allowed functions. By the end, you can examine a capability together with its origin, window or webview, platform, scope, content policy, and command logic, then judge whether those layers narrow the boundary or merely make it look narrow.
A capability is a context, not a permission sticker
Imagine an application with a main interface, a preferences window, and a page that displays content from an external service. All three may run inside one process. They may even appear in windows created by the same Tauri application. It would be convenient to give the process one global set of native permissions, but that would erase the distinction that makes the boundary manageable. Tauri's v2 access-control model starts from a different unit: a capability associates permissions with particular contexts.
A capability can identify windows by exact labels or patterns, and it can identify webviews separately. A window match can cover all webviews in that window; a webview match can narrow access to selected views. A capability can apply to local application content, remote URL patterns, or both when configured. It can also be limited to selected platforms. These dimensions answer different questions. The window or webview labels identify where the request originated inside the application. The origin identifies what page is asking. The platform determines whether a permission is meaningful for the target. The permissions identify which command families are available.
The remote-origin dimension deserves special care. Local application content and a remote page may share a native window without sharing trust. The capability format therefore makes remote URLs explicit and warns that granting local system access to remote sources has security implications. A page hosted at a matching remote URL can be authorized if the application deliberately configures that relationship. It does not acquire local command access merely because it is displayed by a Tauri webview.
Permissions describe commands and, where needed, scope data. An app command can be associated with an app permission; a plugin command uses the plugin's permission namespace. Permission sets can group other permissions, including permissions from other plugins. A capability then selects those permissions for its contexts. This separation lets a team reuse a well-defined permission while changing where it applies, or extend its scope for one capability without making every use equally broad.
The distinction between permission and capability is worth preserving. A permission answers, roughly, “which command or operation is represented?” A capability answers, “where and under which origin may that permission be used?” A filesystem or domain scope answers, “which values may the operation accept?” Treating all three as one allowlist makes it harder to see an accidental widening.
The build process resolves this model before runtime. It gathers app and plugin manifests, parses capability files, expands permission sets, validates references, and records the command contexts and scope data. The generated context carries resolved runtime authority. At request time, Tauri does not have to interpret an arbitrary directory of policy files from scratch; it evaluates the request against the resolved command and context data associated with the running application.
That resolution does not turn configuration into a security verdict for every future implementation. It verifies that the policy refers to known permissions and produces the structures needed for a decision. The native meaning of a command still belongs to its Rust or plugin implementation.