How an integration partner sent us a private key — safely

Part 3 of "How Agdir uses SecretDrop" — a series on where an agtech company and its customers actually share secrets.

Most of the time, you never send a private key. The whole point of a keypair is that the private half stays put: you generate it, you register the public half with whoever needs to verify you, and the private half never leaves your machine.

But every so often, a private key genuinely has to move between two companies. This is the story of one of those times.

The setup

An integration partner — a precision-ag company building a two-way data feed with Agdir — ran their API behind mutual TLS. Plain API keys weren't enough for them: to even open a connection, the caller has to present a client certificate that the partner has issued and trusts. It's a strong setup, and a common one when two businesses exchange sensitive data machine-to-machine.

To let Agdir's connector authenticate, the partner's ops team generated a client certificate and its private key specifically for us. That private key is the credential. Without it, the integration can't connect; with it, anyone can impersonate our connector to their API.

So now two companies had a problem that individuals face every day, just with higher stakes: how do you get a live private key from their side to ours without it leaking on the way?

The way it usually goes wrong

The default in B2B integrations is depressingly casual:

• Zip up the certificate and key, email it as an attachment.
• Put the passphrase in a second email ("for security").
• Or drop both into a shared ticket in whatever support tool connects the two teams.

Every one of those leaves a permanent copy of a private key in a system neither company fully controls — mail servers, backups, a ticketing tool's database, the inboxes of whoever gets CC'd later. A private key that ends up in an email thread is a private key you can never truly get back.

And unlike a password, you can't just "change it" quietly — revoking and reissuing a client certificate means coordinating a rotation across both companies. Far better not to leak it in the first place.

What we did instead

The partner sent the key through SecretDrop:

1. They pasted the private key (PEM) into a one-time link, and sent the passphrase as a separate burn-after-read link.
2. They shared both links with our integration engineer over the normal channel — email was fine, because a link isn't a key.
3. Our engineer opened each link once, loaded the certificate and key straight into our secrets manager, and both links self-destructed.

The private key made a single trip — from their vault to ours — and left no copy behind in any inbox, ticket, or chat on either side. If someone later digs through the email thread that set up the integration, there's nothing sensitive there to find.

The takeaway

If you're a partner who has to hand another company a private key, certificate, or any live credential:

• Never email or attach it. Attachments are the most permanent, most forwardable copy of all.
• Send it as a burn-after-read link, and send any passphrase as a second, separate link.
• Confirm the recipient opened it, then consider the transfer done — the secret no longer exists anywhere in transit.

Secure integrations are only as secure as the moment you set them up. A private key that only existed for the few seconds it took to load into a vault is one that no future breach — on either side — can ever expose.

---

Previously in the series: How a farmer sent an API token to their developer · How Agdir's team passes vendor credentials around.
Setting up an integration and need to move a key between companies? Use SecretDrop — one read, then it's gone for good.