Use Nymbrink with your agent

Your agent does the looking up and the paperwork. A person makes every decision, and the signed record names them.

Connect your agent

It can

  • check an agent before relying on it: use, do_not_use or unknown, with reasons, and any open reports about it as context
  • read your list, one supplier in detail, and your alerts
  • add and remove suppliers, if you allow it
  • prepare an approval, then find out whether a person confirmed it

It cannot

  • approve anything: only an owner, admin or approver can
  • file or answer reports, claim passports, or change billing
  • see another company’s list
  • stop an agent from running: Nymbrink records, it does not block

  1. Make a key for it

    In Settings → API (any paid Monitoring plan), make a key just for this agent, and tick only what it needs: read to check and look; manage to change your list; propose to prepare approvals. Name it after the agent, so your activity log says who acted. You can revoke it at any time.

  2. Keep the key out of the chat

    Put the key in your agent’s settings or your environment, never in a message: anything typed into a conversation may be kept in its history.

    export NYMBRINK_KEY=nym_…   # in your shell profile or secret store

  3. Connect it

    Nymbrink is an MCP server. Any agent that supports remote MCP servers over HTTP connects with two things:

    Server address:  https://nymbrink.com/api/mcp
Header:          Authorization: Bearer <your key>

    In Claude Code, for example:

    claude mcp add --transport http nymbrink https://nymbrink.com/api/mcp \
  --header "Authorization: Bearer $NYMBRINK_KEY"

    Agents without MCP can use the same key with the HTTP API. Adding the header X-Acting-Agent: <its name> puts that name in your activity log, as stated by the agent, not proven.

  4. Try one harmless request

    Ask it to read, not to change anything. If it answers with your own suppliers, it is connected to the right company.

    List the suppliers on our Nymbrink list and tell me which have open alerts.

  5. Then give it real work

    Before we use support.example.com for customer support replies, check it in Nymbrink.
If it is "use", go ahead. If not, tell me the reasons and prepare an approval for a person to review.

    A prepared approval waits on the supplier’s page, and in your list, for a person to confirm or dismiss. Your agent can ask later what became of it: waiting, confirmed or dismissed, and whether the supplier changed since it was prepared. It works for suppliers without a passport too: their pages and cards are approved as last retrieved.

Let your coding agent draft the passport

A passport is a public promise your company answers for. A coding agent can gather the facts your code shows; the promises, and the key that signs them, belong to a person. None of this needs a Nymbrink account.

  1. Let it draft the passport

    In your project, the agent runs the open tool with your company’s domain and --yes. The domain is the passport’s identifier: without one, nobody can tie the passport to your company. A project on GitHub can leave --domain out, and its repository becomes the identifier. The tool writes and signs a draft PROVENANCE.yml from what the project shows (name, version, AI providers, MCP servers, and capabilities implied by a short list of libraries) and makes no promises. Nothing leaves the machine.

    npx provenance-protocol init --domain yourcompany.com --yes

    The tool reads libraries and settings, not your code. So the agent then reads the code itself and lists every capability the tool missed, such as fetching web pages with plain fetch or reading an inbox, for a person to confirm.

  2. A person decides the capabilities and the promises

    Promises (never trains on customer data, needs approval before sending email) are decisions, not facts the code can show. The promises the tool offers mean only that it found no library for them, so add only the ones you stand behind, and the capabilities the agent found. Load the file in the browser form, which runs in your browser so the key never leaves your computer, or edit the file and sign it again. Signing reads the key from .provenance-key in the project, or from PROVENANCE_PRIVATE_KEY in your secret store, so the key is never typed into a command.

    npx provenance-protocol sign PROVENANCE.yml

  3. Keep the key with people

    The tool saves a new key as .provenance-key and keeps it out of git. It is needed to change the passport later, and nobody, Nymbrink included, can recover it. Move it to your secret store as PROVENANCE_PRIVATE_KEY, and don’t paste it into an agent’s chat. A service that serves its own passport reads it from there at start-up.

  4. Keep it true on every build

    The agent can run the check as code changes. It reports what the passport no longer says, and never drops a promise for you, because that is a public weakening. A clean result covers only what the check compares, and says so: a capability added by hand still needs a person.

    npx provenance-protocol check
npx provenance-protocol validate

    In CI, provenance-action runs the same check on every pull request; set check-code: strict to fail the build while anything is outstanding.

  5. Publish it, then check it here

    One of these, whichever fits how the agent runs:

    • On your domain: the same content as JSON at https://yourcompany.com/.well-known/provenance.json. The signature still verifies.
    • In a GitHub repository: commit PROVENANCE.yml at its root.
    • From the agent’s own web service: provenance-middleware serves it and signs it at start-up.

    Then check it here: from then on, every change is recorded for the customers watching it, and they are alerted to the ones that weaken a promise or break their requirements.

To paste into your coding agent’s instructions

In the file it reads for project instructions, such as AGENTS.md or CLAUDE.md.

This project publishes a Provenance passport (PROVENANCE.yml).
- After changing capabilities, AI providers or MCP servers, run `npx provenance-protocol check` and report what it finds.
- The check reads libraries and settings, not code: when you add a capability by hand (fetching web pages, reading an inbox, sending data out), tell a person so they can add it.
- Never add, remove or weaken a promise (constraints, data, oversight, notice) yourself: ask a person.
- Never read, print or commit the private key.