Give an agent access without handing out keys.

How to connect an MCP server so a credential stays a secret, an OAuth token stays short and bound, and nothing that writes runs without a person.

Store it as a secret, not a copy

A token you paste into Knotbind is encrypted with the application secret and never shown again — not on a page, not in a log, not in the Audit Record. If your deployment keeps its own secrets, name the environment variable instead of pasting, and Knotbind reads the value from the process. Either way, treat the stored credential like a password: rotating it means saving a new one and revoking the old one at the provider.

Prefer OAuth over a pasted token

When your server supports the MCP authorization spec, press Connect with OAuth instead of pasting. Knotbind acts as a public client with PKCE and no client secret: it discovers the server's authorization details from its published metadata, and sends the RFC 8707 resource parameter, so the token it receives is valid for that server and nowhere else. The access token and refresh token are then sealed like any other credential. A token bound to one resource is worth less stolen than a universal key.

Publish only what an agent should touch

Annotate honestly. The read-only hint is what lets Knotbind schedule a Check or bulk-approve a suggestion for a tool; a tool marked read-only that actually writes gets run unattended and the damage is yours to explain. Tools that change data stay human-gated: a one-time call needs the Owner's consent for that exact call, and an agent-requested action needs a person to release it. See Governing agent write actions.

The address itself is checked

Knotbind refuses to reach private or internal addresses on your behalf: https on port 443 only, no credentials in the URL, and every address the hostname resolves to must be public. The check runs again at connect time, so a DNS record that answers publicly and then points inward is refused as well. Timeouts and response sizes are bounded, so a server that hangs cannot hold Knotbind's poll open forever. What this gives your side: an MCP URL you hand Knotbind cannot become a way to reach your metadata service or intranet.

Rotate deliberately

• Server credential: save the new value on the server card; it replaces the old sealed one. Revoke at the provider too — Knotbind cannot un-leak a token.
• A relay URL for your own MCP server: treat it as a credential; rotating invalidates the old URL immediately, so update every assistant using it.
• An OAuth grant: reconnect to issue a new consent; revoking at the authorization server takes effect on the next call attempt.

Model traffic is a different door

Everything above is about Knotbind calling your MCP server. Your assistants' model calls go through the Gateway and the credential vault, where an execution grant is short, operation-bound and consented by the Owner: see the credential vault.

Verify what you are sent

Knotbind's webhooks are signed: check the HMAC and reject stale timestamps before trusting an alert's content, as described on Alerts and monitors. An alert that looks like Knotbind's but fails verification is not Knotbind's.