Don't hand the agent the key. Let something between the agent and the service hold it: the agent says which call it wants to make, and the go-between checks the call is allowed, adds the key, makes the call, and hands back the answer with the key taken out. A key pasted into a chat sits in that chat's history, in whatever the model reads next, and in anything the agent writes down or repeats.
What works
Keep keys out of anything the agent can read. That's chats and prompts, and also its notes, its files and its environment: a key moved into an environment variable is still readable by an agent that can run commands. What it can read, it can repeat into a message, a log or another agent's chat.
Put the key behind a tool that runs where the agent can't look. The agent's side of it is a request without the key: "POST /v1/orders, with this order". The tool's side adds the key, sends it, and returns the service's answer, with the key's value replaced wherever it appears.
Approve what the key is for, not only that it exists. "Add confirmed orders to the order book" is narrower than "use the order-book service", and much narrower than "use this key". The narrower the approval, the less a confused or misled agent can do with it.
Use the narrowest key the service offers. Many services offer keys limited to reading, to one part of the account, or to one project. Start there; the go-between's limits come on top, not instead.
Decide how long it lasts. Some keys are for standing work and stay until revoked. Others are for one job, and should expire after some hours or after one use.
Record uses, and be able to revoke it. When something looks wrong, you want to see which agent used the key, for what, and when, and to stop it in one step.
Rehearse with a fake key first, then try the real one on something harmless.
Know what this doesn't cover. A service that sends the key back in its answer, especially in a changed form, can still expose it. A key approved for every action on a service can still be misused through the go-between. And some services have no keys at all, only a login page where a person types a password.
Doing it in Mind Made Many
A secret in Mind Made Many is a key or password an organization keeps for its agents to use. The agent gets a handle for it, not its value: Mind Made Many puts the value into the requests the board approved, on the agent's behalf. At Harbor Lane Bakery, Orders needs the key to the bakery's online order book (a made-up service here), to add each order once it's confirmed.
-
Rehearse with a made-up value. In a chat with the agent filling Orders, ask it to request a made-up secret named order-book-test, for trying how secrets work, with its request going only to Mind Made Many's test address. On the Board, the request says it's a made-up test value: type one of at least 4 characters that isn't a real secret, such as bakery-test-key, and choose Provide. Ask the agent to make one test request with it. Mind Made Many answers that request itself, without sending anything out: the answer shows the request as it would have been sent, with the value replaced by a placeholder. That tries how secrets work, not the order book.
From Harbor Lane Bakery, an organization made up for these pictures. -
Ask for the real one under another name, such as order-book-key: asking again under the test's name brings back the test secret. Have the agent say what it's for in plain words, the service, and the exact kinds of request it will make, from the service's own documentation: here, adding an order. You don't fill in anything technical: the agent proposes, and the narrower its proposal, the better.
-
Read the request on the Board before you provide it. It says where Mind Made Many will send the key and for how many kinds of request, with a warning when they're broad or can change or delete things there, and Details lists each kind: those are what Mind Made Many enforces. The why, such as "to add confirmed orders", is the agent's own account of what it will do, which nothing enforces. If the kinds of request are more than the work needs, decline, and say why. Otherwise type the key and choose Provide.
-
Once provided, only the role that asked may use it, and it's kept until it's revoked. Under Share, in Secrets, you can change both, and limit it to a set time or to one use. A limit counts from when you set it, so ask the agent to wait while you set it, before its first request. One use is one more attempt, which counts even if the request fails.
-
Each use is a request Mind Made Many makes for the agent. It checks that the role and the kind of request are ones the board approved, puts the value into the request, sends it without following redirects, and replaces the value with a placeholder wherever it appears in the answer as it was given. Try it on one real order first, and check in the order book that it was added once. If a request gets no answer, it may still have reached the service: check the order book before the agent tries again.
-
Under Share, in Secrets, you see each secret, who may use it, how long it's kept, its last attempts, and Revoke.
What doesn't work yet
- A secret is used only in requests Mind Made Many makes: HTTPS calls of the kinds the board approved, with the value in one header, and a text body of up to 16 KiB. There's no way to attach a file, and a login that needs a password typed into a web page isn't supported yet. An answer's body comes back only if it's text, within the same size.
- The value could still be exposed by a kind of request the board approved that sends it back in its answer, for instance in another form than it was given, which the placeholder can't catch. That's why approvals should be narrow.
- A secret is limited to roles and kinds of request, not to what's inside each request: an amount, say.
- Secrets shows a secret's last 10 attempts, refused ones included; Mind Made Many keeps the last 100.
- Revoking stops further requests through Mind Made Many. It doesn't undo a request already sent, or cancel the key at its service: do that there too.
- Uses of secrets are limited to 30 a minute, an allowance that several agents in an organization can share, and an organization keeps up to 50 secrets.