Every time I tell someone that Claude Code and Cowork touch real accounts of mine — real logins, real automations, real work — I get the same reaction: a slight flinch, then the question. “Wait. Doesn’t that mean the AI has your passwords?”
No. And the reason why is the actual subject of this post.
I run five different things. None of them would survive me hand-typing passwords into an AI chat window, or copy-pasting an API key into a script “just to get it working.” That habit is how real damage happens — not from some exotic hack, but from a secret sitting in plain text somewhere it never should have been, waiting for the wrong thing to read it. The fix isn’t complicated. It’s a password manager, sitting between me and every AI agent I use, doing a job it was already built for long before AI showed up.
The Naive Way (And Why It’s a Trap)
Here’s the shortcut everyone’s tempted by at some point: you’re building something, you need it to log into a service, and the fastest path is to just paste the password or API key directly into the script, or type it straight into a chat. It works. It’s also exactly how things go wrong.
Once a secret is typed into a chat window, it’s in that chat’s history. Once it’s pasted into a file, it’s in that file’s history, and probably in a backup of that file, and possibly in a log somewhere you forgot existed. None of that requires anyone to “hack” anything — it just requires someone, or something, to eventually read what’s already sitting there in plain sight. I’ve had a real scramble because of exactly this kind of shortcut: a key that ended up somewhere it shouldn’t have, that had to get rotated fast before it could be misused. It’s an embarrassing lesson to learn once. It’s a genuinely bad one to learn twice.
What a Password Manager Is Actually Doing Here
Before AI ever entered the picture, the whole point of a password manager was simple: one strong vault, unique credentials for everything, and autofill instead of memorization or reuse. You already trust it to sit between you and every login you have, so you never have to type — or even know — most of your own passwords.
Extending that same idea to AI agents turns out to be the natural next step, not a special new system. Instead of an AI knowing a password, the AI asks the password manager to handle it — and the password manager fills it in directly. The AI sees that the step completed. It never sees the actual value. That’s not a metaphor; it’s the literal mechanism I use every day, and it’s a hard rule I hold to on principle: I don’t let an AI agent type a password by hand, ever, no matter how much faster it would be. If a login needs to happen, it goes through the password manager’s own interface, or it doesn’t happen at all.
How I Actually Use It
For anything automated — a background script, a scheduled task, an AI agent running unattended — I don’t hand over my own login at all. I set up a separate account that exists only for that purpose, with only the access it actually needs. That account doesn’t get my real password either; it gets a scoped, short-lived token instead. If that one token ever gets compromised or a script goes rogue, I revoke that single token and nothing else in my life is touched. My actual accounts were never in the blast radius to begin with.
The credential itself only gets pulled at the exact moment something needs it, used, and released — it’s never sitting written down in a file somewhere in the process, which means there’s nothing lying around for a mistake, a leak, or a nosy piece of software to stumble onto later. And the rule from the section above still applies here too: nothing gets hand-typed into a script to save thirty seconds. That thirty seconds saved is precisely the moment real damage gets created.
The Practical How-To: Passwords vs. API Keys
These aren’t the same kind of secret, and they don’t belong in the same kind of entry.
A password is something you (or your browser) type at a login screen. In 1Password, that’s a standard Login item: the service name, your username or email, and a generated password you never actually see or memorize — 1Password suggests a long random one, saves it, and autofills it at the real login page. You never type it, so it’s never in your clipboard history, your chat history, or a sticky note.
An API key or token is different. It’s not something you type at a login screen — it’s a raw string a script or an AI agent uses to authenticate itself. For those, use an API Credential item (or a Secure Note if your version doesn’t have that type). Paste the key into the credential field once, give it a clear label and a description of what it’s for, and stop there. From then on, anything that needs it — a script, Claude Code, Cowork — references it by its path inside the vault instead of having the raw value pasted into a file. That’s the difference between “the key lives in one locked place” and “the key is copy-pasted into six different files, half of which you’ll forget about.”
The rule of thumb: if a human types it into a login form, it’s a Login item. If a machine reads it to authenticate itself, it’s a Credential item, referenced, never hardcoded.
Label Everything. Rotate on a Schedule.
An unlabeled credential is a liability, even sitting safely in a vault. If you can’t tell what a key is for, you can’t tell whether it’s safe to delete, what breaks if you rotate it, or whether it should still exist at all. My convention is simple: [Service] – [What it’s for] – [When it was created]. Something like “Stripe API – checkout automation – Jan 2026” tells you everything you need to know at a glance, six months from now, when you’ve completely forgotten the details.
Rotation matters even more than labeling, and it’s the step people skip. A key that leaked quietly a while back and was never rotated is still a fully valid key today — the leak doesn’t expire just because nothing bad has happened yet. Two rules cover almost every case: rotate anything high-value (payments, admin-level access, anything that touches money or real customer data) on a fixed schedule regardless of whether you suspect a problem, and rotate immediately, no exceptions, the moment you suspect a key was ever exposed. “Probably fine” is not a rotation policy.
How This Shows Up in Cowork and Code
Cowork is the surface I hand file and task work to — the stuff that used to mean digging through folders or wrangling five apps by hand. When one of those tasks needs to log into something on my behalf, it requests that credential through the password manager’s own approval flow. I see the request, I approve it for that use, and the credential itself never becomes something Cowork is holding onto or could accidentally expose later.
Claude Code works the same way under the hood, just for building instead of organizing. If a script or workflow needs a real API key to run, it pulls that key from the vault at the moment it’s needed, by reference, rather than having the key written into the code itself. That matters more than it sounds like: it means the code stays something I can share, back up, or hand to someone else without a live secret baked into it waiting to be found.
Different jobs, same underlying rule: asking a human to unlock something is the safe default. Remembering it — or worse, writing it down somewhere convenient — never is.
What to Watch Out For
Letting convenience win, just this once. The moment you’re most tempted to paste a secret directly instead of doing it the proper way is exactly the moment it costs you. There’s no such thing as “just this once” with a leaked credential.
One login doing double duty. If an automation uses the exact same login as you personally, you can never revoke just the automation’s access without locking yourself out of your own account too. Separate accounts for automation aren’t paranoia, they’re the entire point.
Forgetting to actually rotate after a scare. If a key was ever exposed — even briefly, even if you’re pretty sure nothing bad happened — treat it as compromised and rotate it. “Probably fine” is not the same thing as fine.
Skipping the approval step because you trust the process now. The safety of any of this still depends on you actually looking at what’s being requested before you approve it, not clicking through on autopilot because it’s usually fine. Usually isn’t a
Grab the Checklist
I put the rules from this post into a one-page printable checklist — the habits that actually matter when you’re letting AI agents touch real accounts. It’s free, grab it below.
If any of this makes you want to double-check your own setup, that’s the right instinct. It’s worth thirty minutes.
— Warren