How our team passes vendor credentials around

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

Agdir isn't one integration — it's dozens. Government reporting, an accounting sync, soil-sensor vendors, payments, weather providers. Every one of those comes with its own credential: an API key, a client secret, sometimes a private key or certificate.

(You'll notice we're not naming which vendors go with which credentials. Publishing a public map of exactly which live keys we hold for which named production systems would be its own tidy little security-hygiene own-goal — a bit rich in a post about handling secrets carefully. Practice what you preach. 😉)

Those live where they should — in a secrets manager, in environment variables, locked down. The storage problem is solved.

The handoff problem is not.

Where credentials actually leak

Credentials don't usually leak from the vault. They leak in the ordinary moments between people:

• A new engineer joins and needs the sandbox key for a vendor to start working.
• Someone rotates a soil-sensor vendor's password and has to get the new one to the teammate deploying the connector.
• A key gets set up on someone's laptop and needs to reach a colleague configuring a new environment.

In every one of those moments, the temptation is the same: drop it in a Slack DM. "Here's the key, delete this after." Paste it into a ticket "just for now."

But a Slack message doesn't get deleted after. It's retained, searchable, and synced to every device that account touches. "Just for now" is how a live vendor credential ends up permanently sitting in a chat history that outlives the person who sent it.

What our engineers do

For the handoff itself, the credential goes through SecretDrop as a burn-after-read link:

1. Paste the vendor key, secret, or connection string into SecretDrop.
2. Send the one-time link over Slack or email — the link isn't the secret.
3. The teammate opens it once, moves the value straight into the secrets manager or their environment, and the link self-destructs.

The credential lives in exactly two proper places — the vault it came from and the vault it's going to — and never in the chat that carried it between them.

Why this matters more for an integration company

When you integrate with government systems and financial software, a leaked vendor credential isn't just your problem — it can expose customer data and break trust with the vendor whose access you're responsible for. The blast radius of "one key left in Slack" is a lot bigger than it looks.

The rule we settled on is simple:

Secrets managers are for storing. Burn-after-read links are for moving.

Never let a live credential rest in a channel designed to remember it. If it has to travel between two people, it travels as a link that reads once and disappears.

The takeaway

• Store credentials in a secrets manager — always.
• Move them with a one-time link — never in a chat, DM, or ticket.
• Rotate anything that ever touched a persistent channel, just in case.

The vault protects the secret at rest. SecretDrop protects it in transit — during the one risky moment it's out in the open.

---

Next in the series: How an integration partner sent us a private key — safely.
Previously: How a farmer sent an API token to their developer.