> ## Documentation Index > Fetch the complete documentation index at: https://dsrs.herumbshandilya.com/llms.txt > Use this file to discover all available pages before exploring further. # Capabilities > Named permissions: programs declare a ceiling, tools and holes declare needs, hosts grant, and load checks the subset A capability is a named permission: `orders:read`, `net:search`, `fs:read`. Nothing more mysterious than that, a short label for one kind of access to the world. Three parties each state their side in writing, and the statements are checked against each other at load, before a single step runs. ## Three statements, one check | Party | Statement | Where it is written | | ------------------ | ----------------------------------------- | -------------------------------------------------------------------------- | | The program | Its ceiling: the most it could ever touch | `caps { ... }` in the artifact, `#[module(caps(...))]` in source | | Each tool and hole | Its needs | `#[tool(caps("..."))]` in source, `caps [...]` on the printed tool or hole | | The host | Its grants | `--allow` on the `dsrs` host, `RuntimeEnv::grant` in an embedding binary | **The program declares its ceiling.** At the top of the artifact: ```text theme={null} caps { kb:read orders:read } ``` This is not what the program will do on a given run. It is the most it could ever do. Because the declaration is a line in a reviewable text file, it is diffable data: a program that never declared network access cannot quietly grow it, because the file would change and the change would show in review like any other line. **Every tool and hole declares its needs.** A host tool names them in its attribute: ```rust theme={null} /// Look up an order's status by id. #[tool(caps("orders:read"))] async fn order_lookup(order_id: String) -> Result { // your implementation } ``` A tool or hole that touches nothing declares `caps []`. Each piece's needs must fit under the program's ceiling as a subset, and this is checked at load: a ceiling that says only `kb:read` cannot contain a tool that needs `orders:read`, and the violation is a load error, not an incident in production. **The host states its grants.** Whoever runs the program has the final word. Serve the file but grant only the FAQ capability: ```bash theme={null} dsrs serve frontdesk.dsrs --allow kb:read ``` ```text theme={null} program caps exceed host grants: missing ["orders:read"] ``` The program's caps must be a subset of the host's grants or loading refuses, up front and by name, before a token is spent. In an embedding binary the same grants come from `RuntimeEnv::grant(cap)`, and the same subset check runs inside `Interpreter::load`. ## The empty sandbox Permission systems usually fail by omission: a deny list forgets an entry, or a check gets bypassed by a code path nobody audited. The DSRs sandbox inverts this. When a sandboxed hole or a [Code Mode](/docs/components/code-mode) script starts, its environment contains only what the host granted. An ungranted capability is not a blocked call inside the sandbox; the function for it does not exist there at all. Ungrant `orders:read` and the sandbox simply contains no `order_lookup`, so no script, however creative, can invoke it. There is nothing to bypass. Deny lists require perfect memory; empty sandboxes do not. This is why a model writing JavaScript in the sandbox is not being trusted. It is being contained by construction: the sandbox starts empty, and only grants get placed inside. ## Local modules and loaded files When you run your own `#[module]` directly, nobody asks you to `--allow` anything. The native parts are already in your binary, compiled from your own source, and a gate between you and code you wrote yourself withholds nothing. The module's generated `env()` therefore grants its own declared ceiling, and the declaration serves as documentation plus the fence around any sandboxed parts. The moment the same program travels as a `.dsrs` file, trust resets to zero. A host loading the file re-checks the program's caps against its own grants, and the program gets exactly what the host allows. Same declaration, two enforcement postures, both consistent with who wrote what. ## Declarations are data Every capability statement lives in the artifact as plain text: the `caps { ... }` ceiling at the top, and `caps [...]` on each printed tool and hole. That makes the permission surface reviewable with the same machinery as any other change. A pull request that widens a program's ceiling is a visible diff on one line, and a load failure names the exact missing set, as in the error above. ## See also * [Tools and agents](/docs/components/tools-and-agents) for declaring needs on host and sandboxed tools * [Holes](/docs/components/holes) for the `caps []` printed on holes * [Runtime](/docs/components/runtime) for `RuntimeEnv::grant` and the load-time subset check * [The .dsrs file](/docs/components/dsrs-file) for the caps grammar * [Code Mode](/docs/components/code-mode) for the sandbox that scripts run inside