Treat an agent connection key like a credential

One connection has an identity

An agent key identifies which agent is making a request. It is not a public project identifier or a snippet to paste into a repository. Anyone who obtains it can attempt the operations allowed by that credential, within the agent’s existing controls.

Keep examples separate from secrets

Documentation examples use placeholders for a reason. Put the real value in private configuration or a server-side environment variable. Avoid screenshots that reveal the key, frontend bundles that include it, and shared project files that accidentally commit it.

Plan for replacement

Transfer keys can expire and be revoked. Revoke a key when a connection is no longer needed or when you suspect exposure, then configure a replacement where appropriate. A private key should have a clear purpose and an owner who knows how to turn it off.

Know what the key grants

A Transfer agent key is scoped to the associated agent. It allows supported agent operations rather than general owner access, and it does not let the caller add wallet funds or rewrite budgets. Those boundaries are useful, but they do not make the credential harmless. Someone holding the key can attempt permitted operations and inspect the information available to that agent. Before connecting a client, decide which agent it should represent and whether that connection is still needed. Keep a clear distinction between an owner’s dashboard session and a tool connection acting under an agent identity.

Trace the places a secret can travel

A credential can leak through ordinary development habits: a committed configuration file, a recorded terminal session, a copied support message, or a screenshot used in documentation. Shell variables help keep examples readable, but the client’s saved configuration may still contain the resolved value. Understand where your chosen client stores server settings and keep that location private. Review diffs before committing, and use obvious placeholders in examples. Avoid putting secrets into URLs, where they may be recorded in browser history or request logs. Treat every copied configuration as something worth checking before sharing.

Recover from suspected exposure

If a key appears somewhere it should not, revoke it rather than relying on deleting the visible copy. A secret may already have been copied elsewhere. Create a replacement only for the connections that still need access, update their private configuration, and confirm the old key no longer works. Review the associated agent’s recent activity so you understand what happened during the exposure window. Freezing the card can pause simulated spending while you investigate, but it is not a substitute for revoking a credential that is no longer private. Keep recovery steps simple enough to follow under pressure.

Separate development examples from active connections

A useful tutorial should be copyable without containing working credentials. Keep example keys obviously fake, and keep the instructions for obtaining a real key separate from the published snippet. This applies to blog posts, support messages, issue reports, and team demonstrations as well as source code.

When you need to show a configuration problem, replace the key before capturing the example. Preserve the non-secret details needed for diagnosis, such as the endpoint and the header name, without sharing the credential itself. If a tool saves configuration automatically, inspect the saved location before committing nearby files. The important habit is to consider where a secret may persist after the immediate task ends. Closing a terminal or deleting the original message does not necessarily remove every copy made during setup.

Know when access should end

An experiment can finish successfully while leaving behind a connection that no longer serves a purpose. Decide in advance what marks the end of the test and whether the key should be revoked at that point. For ongoing connections, review access when the agent’s purpose changes or the client is replaced.

This is different from repeatedly regenerating credentials without a plan. The objective is to maintain a clear relationship between an active key, the agent it represents, and the client that uses it. When replacing a connection, confirm the new one works and remove the old access deliberately. If you cannot explain why a key is still active, investigate before treating it as harmless background configuration. Small, understandable access boundaries are easier to maintain than a collection of forgotten connections.