Credentials without the jargon: what owners need to know

A credential is a key you can take back

Forget infrastructure for a moment. Every connection your agent uses is a key: it opens specific doors, it belongs to someone, and it can be handed back. Owners do not need to know how the lock is built—only those three facts for each key they hold.

That reduces the whole topic to five small habits, and the rest of this note is detail on each:

• Name the key. Know what each connection opens and who owns it.
• Connect through the service. Use its own sign-in screen instead of pasting a secret.
• Grant the narrowest access. Approve only the scope the task needs.
• Expect expiry. Treat a lapsed connection as routine, and reconnect—never widen.
• Rotate after risk, keep one owner. Replace access when people or devices change, and never let a key outlive its owner.

The failure this prevents is the orphaned key: a connection nobody can name, still open, quietly working until the day it isn’t. The trade-off is honest—this is bookkeeping, and bookkeeping is dull. But the ten minutes of writing it down is what turns that empty-report Tuesday from a scramble into a two-click fix.

How to judge it: pick any connection and try to say out loud what it opens and who would revoke it. If you cannot, that key is already drifting.

Connect through the service, don’t copy secrets

When a service offers a “Connect account” or sign-in screen, use it. That flow shows you exactly what access is being requested, hands the agent a limited token instead of your password, and leaves a revoke switch on the service’s own security page. The same screen is where you set scope, so approve only what the task actually needs—if the agent only reads a report, look for view-only and decline write access.

Why it matters: granting the minimum keeps the damage small if a key ever leaks, which is the whole point of least privilege. It also means you can pull one connection without disturbing anything else.

The failure case is pasting a long-lived password or API key into a field to “just make it work.” Now the same secret lives in two places, nothing expires on its own, and rotating it becomes a manual chore you will forget. The trade-off: some services only offer coarse, bundled permissions, so the connect screen may ask for more than you would like. When it does, the decision is not how to grant it faster—it is whether the task is worth that much access at all.

How to judge it: after connecting, open the service’s own security settings. You should see the new access listed there, with your own button to remove it.

Treat expiry as routine, not an emergency

Connections are meant to lapse. Short-lived tokens are a safety feature: they limit how long a leaked key stays useful, and reconnecting simply refreshes consent. So when something expires, reconnect through the same flow you used the first time. Do not respond to expiry by granting broader or never-ending access to stop the prompts.

Why it matters: the reconnect is cheap, and it keeps the blast radius of any leak measured in days, not forever. A good dashboard makes this easy by naming which account needs attention and offering a plain reconnect step.

The failure case is the owner who, tired of a weekly nag, shares a full admin login or flips on a permanent, wide-open key—trading a minor annoyance for a large standing risk. The trade-off is real but small: shorter-lived connections mean the occasional reconnect click. That friction is the price of a leak that expires on its own.

How to judge it: when a connection lapses, the fix should restore the workflow without changing its scope. If “fixing” expiry keeps widening access, the gate is being defeated, not passed.

Rotate the moment risk appears

Rotation means replacing a key with a fresh one and cutting off the old. Do it after a teammate or contractor leaves, after a device or account is compromised, or after a credential turns up somewhere it should not—a chat message, a screenshot, a shared doc. Pause the affected workflows until access is safe again.

Why it matters: rotation is the only thing that actually revokes what an old or leaked key could still do. Changing a password is not enough on its own, because a token issued under the old sign-in can keep working.

The failure case is exactly that half-measure: the owner resets a password, feels safe, and never revokes the existing connection—so the agent, and anyone holding the old key, still has a live door. The trade-off is a brief pause in the workflow while you swap keys, which is far cheaper than leaving an unknown holder with access.

How to judge it: after rotating, confirm on the service’s security page that the old access is gone, then check the workflow runs on the new connection. Both must be true before you call it done.

Give every connection one owner

For each connection, write down four things: the business owner, the workflows that use it, the scope it was granted, and the date you last reviewed it. Then review the list quarterly, and sooner after any role change or security event.

Why it matters: expiry and risk notices have to reach a person who is accountable and able to act. A connection with no clear owner is the one that survives a departure unnoticed—and orphaned connections are precisely the keys attackers and audits find first.

The failure case is the connection tied to one person’s personal login. When they leave, nothing looks wrong until the account closes or the token expires, and then a workflow breaks with no one obvious to call. The trade-off: a shared business account is slightly more effort to set up than a quick personal sign-in, but that setup is what buys you continuity when people change.

How to judge it: every connection maps to exactly one named owner, and the count of connections with no owner is zero. If it isn’t, start there.