Capabilities.

Capabilities live in rune.toml under [capabilities]. They're flat strings, namespaced by colon, and ordered alphabetically when packed (so two Runes asking for the same things produce the same manifest hash).

[capabilities]
required = [
  "host:bukkit",              # use the bukkit/paper API surface
  "host:plugin:vault",        # interop with the Vault plugin
  "host:plugin:papi",         # register PlaceholderAPI expansions
  "host:http",                # bind rune.serve()
  "host:store",               # persist data via rune.store()
  "host:net:outbound",        # initiate outbound network connections
  "host:fs:read",             # read files outside the script's directory
  "host:fs:write",            # write files outside the script's directory
]

Capabilities are graded by trust cost on the Runebook detail page. The grading is a property of the capability string, not the Rune, so two Runes asking for the same thing get the same color.

• standard — bukkit access, the store, scoped files. Approximately every Rune declares these.
• elevated — outbound network, named plugin interop, registering placeholder expansions. Reasonable for many Runes; should still raise an eyebrow.
• danger — broad filesystem access, arbitrary classpath reflection, running shell commands. Operators should expect a justification in the README.

Today, the runtime trusts every script in plugins/Rune/scripts/ equally — the operator already had to copy your code into their server. Capabilities are advisory metadata on the registry side. This is deliberate: we want the schema in flight before enforcement so the ecosystem stabilizes around real declared sets, not invented ones.

Tomorrow, capabilities will gate the same APIs they document. Declaring a capability you don't need is a forward-compat liability (your Rune will keep asking for things it doesn't use); omitting one you do need means future versions of the host will reject the operations.