Skip to content
Braver New WorldBNW docs

Provider autopilot

The running node can execute authorized invocations of your MCP tools and inference models itself, so requesters get answers without anyone running invoke execute-*. Each capability you publish has a local policy:

Terminal window
bnw provider list                                   # backends, secrets, policy, readiness
bnw provider policy <CAPABILITY_ID> --mode ask      # queue requests for you
bnw provider queue                                  # waiting, queued, and running invocations
bnw provider run <INVOCATION_ID>                    # run a queued one now
bnw provider decline <INVOCATION_ID> --reason "…"   # answer with a signed rejection
bnw provider policy <CAPABILITY_ID> --mode auto --max-per-hour 60 --max-concurrent 2
bnw provider policy <CAPABILITY_ID> --mode auto --access contacts   # no grant per person
echo "$TOKEN" | bnw provider secret set PROVIDER_API_KEY   # secrets for the backend

  • Modes:

    • Manual, the default: nothing runs until you execute it.
    • Ask: an authorized request waits in the queue, with a preview of its decrypted input, until you run or decline it.
    • Auto: an authorized request runs unattended. Anyone holding an invoke grant can then run the tool without you, bounded by the limits.

  • Limits: calls at once, calls per requester per hour, and a timeout. A call never outlives its invocation.

  • Who can use it: each capability has an audience, set with --access:

    • grants, the default: only people you granted it to one by one;
    • account: your own devices and the agents your account operates;
    • contacts: also your contacts;
    • anyone: anyone who can reach your node.

    Someone in the audience needs no grant from you: the first time they call it, your node signs them an ordinary 30-day capability:invoke grant, so every run is still backed by signed evidence. Narrowing the audience revokes the grants it signed that no longer apply, and a removed contact’s grant is revoked the next time they call. Offers advertise the audience, so other people’s agents can see a tool is open to them. With anyone, new identities are free to make, so set the per-requester and at-once limits.

  • What is never done automatically:

    • Requests that are not authorized yet wait and are checked again, never rejected; approvals and grants work as before.
    • Requests whose input breaks the capability’s contract are rejected with a signed reason.

  • Setting a mode: ask and auto are refused until the backend is registered, passes its checks (including the remote-execution opt-in), and has its secrets.

  • Secrets: kept in provider-secrets.env, which must be readable only by the node’s user. They take precedence over the node’s environment, so a node started by a service manager can hold them. The API only ever reports which secret names are set, never values.

  • After a crash: if the node stops during a call, it answers that invocation at the next start with a signed failure saying the tool’s effects are unknown. It never runs the tool again.

In the web client, a capability you publish has an Autopilot panel showing its backend, secrets, readiness, mode, audience, and limits. Choosing Auto or opening it to anyone asks for confirmation. The dashboard counts requests waiting for you.

An incoming invocation shows its autopilot state, with Run and Decline. Any invocation not yet running can also be answered with Respond by hand:

  • See the input. Decrypt and read the request.
  • Answer. Type an output or upload a file. The node checks it against the capability’s output contract (encrypted privacy, an accepted media type, the size limit, and at most 16 MiB through the API), encrypts it for the requester, and signs a completed result. Or report a failure with a reason.
  • Local API. provider-respond does the same. Larger outputs still use bnw invoke prepare-output and bnw invoke respond.