Stop sharing your credentials with agents — per-agent identity is here, and here's the order to fix things in.
Disclosure: some links in the original are affiliate links, and we may earn a commission if you buy through them — at no extra cost to you. It doesn't change our analysis, and the security advice below is the same advice we'd give with no links at all.
You gave an agent a job. To do it, the agent needed to log in somewhere — a dashboard, a cloud console, a bank, a SaaS tool. So you did what almost every developer has done this year: you handed it your password, or a key that works just like one. It is probably still sitting in a prompt, a script, or a .env file you meant to clean up later. That is the quiet security debt of the agent era. Your agents are logging in as you, everywhere — and the institutions on the other end have started to notice.
How we put this together
We based this piece on vendor launch materials from 1Password and IDENTOS, reporting by Axios on bank responses to agentic activity, and 1Password's Developer Pulse survey of developers. Where a claim comes from a vendor — launch features, plan inclusion, partner lists, survey results — we label it as a vendor claim or cite the source by name. We have not hands-on tested 1Password for Agents or IDENTOS PolicyArc; this is researched analysis, not a product review.
Verdict
Stop sharing your own credentials with agents, starting now. Give each agent its own identity, scoped to one task, for a limited time, with a log you can read and a revoke button that works. Per-agent identity is becoming the default — 1Password for Agents and IDENTOS PolicyArc, both launched this week, are early, concrete versions of it. Fix in this order: inventory what your agents can reach, kill shared passwords, then add scoping, expiry, and audit.
Why banks are suddenly interested in your agents
Start with the bank's point of view, because it explains everything else.
According to Axios reporting, US banks are detecting unverified agentic activity on customer accounts. Chase has warned customers not to share their credentials with third-party agents. Read that warning carefully. The bank is not making a philosophical point about AI. It is telling you that when an automated agent signs in with your username and password, the bank cannot verify who — or what — is actually on the other end.
Mechanically, the bank is right. A legitimate agent using your password and a criminal using your stolen password produce nearly identical signals: correct credentials, an unfamiliar device or location, odd hours, rapid navigation, no human typing pattern. Fraud systems were built to flag exactly that shape of activity. Your agent does not look like innovation to a risk engine. It looks like account takeover that happens to be polite about it.
That distinction matters for you even if you never automate a bank login. The same pattern is now playing out across cloud consoles, payment dashboards, ad accounts, and production SaaS tools. When something goes wrong — a bad transaction, a deleted resource, a leaked export — the audit log will say you did it. Because as far as the system is concerned, you did. You gave the agent your identity, so every action it takes inherits your name, your permissions, and your liability.
And developers are doing this at scale, under real pressure to keep doing it. In 1Password's Developer Pulse survey, 65% of developers said they are expected or encouraged to use AI agents. Only 33% said they have a secure way to let agents sign in. That gap — between "you must use agents" and "here is a safe way to give them access" — is where passwords end up in prompts. It is not carelessness, mostly. It is a missing piece of infrastructure. This week, two companies shipped attempts to fill it.
The five ways agents sign in today, compared
There are really only five patterns in use right now. They are not equally good, and we are not going to pretend they are. Here they are, worst to best, with the two launches from this week placed where they belong.
1. Your shared password — the worst option, and still the most common
How it works: You give the agent your actual username and password. It stores them in a prompt, a script, a config file, or its own memory, and signs in exactly as you would.
Strength: It works with everything, immediately, with zero setup. That is the entire list of strengths.
Weakness: Everything else. The credential has your full permissions — no scoping, no expiry, no way to tell agent actions from your actions in a log. If the prompt leaks, the password leaks. If the agent is compromised, you are compromised. Rotating the password breaks every agent using it, so nobody rotates it. If you are doing this today, you are not alone — but you should treat it as an incident waiting for a date, not a workflow.
2. Long-lived API keys — better than a password, worse than you think
How it works: Instead of your password, the agent carries an API key — often created under your account, often with broad permissions, often valid until someone remembers to delete it.
Strength: At least it is separate from your human login, and most platforms let you revoke a key without changing your password. For machine-to-machine calls to a single API, this is a reasonable baseline.
Weakness: "Long-lived" is the problem. Keys get copied into repos, CI logs, screenshots, and chat transcripts. They rarely expire, rarely get scoped tightly, and rarely have a human in the loop when they are used. A leaked long-lived key with broad scope is a password with better branding.
3. Scoped, short-lived tokens — the right shape
How it works: The agent gets an OAuth-style token limited to specific permissions, for a specific service, for a short window — minutes or hours, not months. When the window closes, the token dies and a new one must be issued.
Strength: This is the pattern security teams actually want. Least privilege by default, automatic expiry, and a much smaller blast radius if a token leaks. A stolen token that expires in an hour and can only read one project is a bad day. A stolen password is a bad quarter.
Weakness: Support is uneven. Plenty of tools your agents need still do not offer fine-grained, short-lived tokens, and wiring up issuance and refresh for every agent and every service is real engineering work. The pattern is right; the ecosystem is still catching up.
4. Per-agent keys with human approval — 1Password for Agents
How it works: Each agent gets its own identity instead of borrowing yours. 1Password for Agents, launched October 22, 2026, is the clearest consumer-and-developer example so far. As 1Password describes it — a vendor claim, based on its launch materials — each AI agent signs in with its own unique digital key, you approve every sign-in attempt on your own device, and the actual password never reaches the agent. 1Password lists the feature as included in its Individual and Family plans via 1Password.com.
1Password names its launch partners as rolling out, including Meta's Muse and Grok Bot, with Claude Duet, ChatGPT Work/dots, and Townie listed as coming soon. It also says integrations are being built by Browserbase, Browser Use, Perplexity, and Ramp. Treat that partner list as a vendor roadmap claim until each integration is live and documented — but note the shape of it: browser agents and finance tooling are exactly where credential-sharing risk is highest.
Strength: The password never reaches the agent, every sign-in needs your approval on your device, and each agent is distinguishable from you and from every other agent. Revoking one agent does not mean changing your password everywhere.
Weakness: Human approval does not scale forever. Approving every sign-in works for high-value logins; it will chafe for agents that authenticate constantly in the background. And you are trusting one vendor's vault and approval flow with the keys to a lot of doors — convenient, and a concentration risk you should choose with your eyes open.
5. Policy and audit engines — IDENTOS PolicyArc
How it works: Instead of managing credentials agent by agent, you define policy in one place: who and what can access which resources, for which tasks, for how long — and you get an audit trail across all of it. IDENTOS PolicyArc, which reached general availability on October 23, 2026, is positioned exactly there. As IDENTOS describes it — a vendor claim from its launch materials — PolicyArc is one place to define, enforce, and audit access policy for people and agents, with task-specific, time-limited access grants.
Strength: This is the enterprise-grade answer to the real question, which is not "how does this one agent log in?" but "what is every agent in this organization allowed to reach, and can we prove it later?" Central policy, time limits, and audit in one system is what compliance and security teams will ask for.
Weakness: Weight. A policy engine is infrastructure to evaluate, buy, integrate, and operate. For a solo developer or a three-person team, it can be more machine than the problem needs today. It also only governs the systems you connect to it — an agent with your password typed into a prompt is outside the policy no matter how good the engine is.
Our ranking, plainly: shared passwords are last, and it is not close. Long-lived keys are a distant fourth. Scoped, short-lived tokens are the baseline every developer should aim for today. Per-agent keys with human approval rank first for individual developers and small teams right now, because they fix the worst failure — password exposure — without a platform rebuild. Policy and audit engines rank first for organizations managing many agents across many people, where the audit trail is the point. Pick based on your scale, but do not pick option one.
What to do this week
You do not need to buy anything to start. You need an inventory and the willingness to delete some credentials. Work through this in order — and if you want a structured pass, run our Agent Access Readiness checklist on Pick a Tools alongside it, then read the broader background in our AI Agent Identity hub.
- Inventory every agent and what it can reach. List every agent, assistant, script, and automation that signs in to anything on your behalf. For each one: what service, what credential, what permissions, who else has that credential. You cannot fix what you have not listed. Most developers find at least one agent they forgot was still running.
- Kill shared credentials first. Anywhere an agent uses your personal password, stop — this week, not this quarter. Rotate that password, and do not hand the new one to the agent. If the agent breaks, that breakage is information: it tells you the workflow had no safe sign-in path, which is the thing to fix.
- Scope to least privilege. For every remaining key or token, cut permissions to what the task actually needs. Read-only where read-only works. One project, not the whole account. If a platform only offers an all-or-nothing key, note it as a risk and shorten its life.
- Make grants time-limited. Prefer short-lived tokens where they exist. Where they do not, put a calendar date on every long-lived key and rotate on schedule. Task-specific, time-limited grants — the model PolicyArc describes — are the target even if you implement them manually for now.
- Keep audit logs you actually read. A log nobody opens is decoration. Once a week, scan sign-ins and agent actions for the services that matter: anything you do not recognize gets investigated the same day. Separate agent identities make this possible; shared passwords make it pointless.
- Make revocation one click, and test it. For each agent, know exactly how you would cut its access in under five minutes — and actually test the revoke path once, before you need it during an incident. If revoking one agent means changing your own password and logging yourself out of everything, you still have a shared-credential problem.
When the inventory is done, score yourself honestly with the Agent Access Readiness tool and fix the lowest-scoring area first. The goal for this week is not perfection. It is making sure no agent anywhere is signing in with your personal password.
The honest limits
Some restraint is warranted, because this category is three days old in its current shape and the marketing is running ahead of the standards.
The standards are unsettled. There is no single, widely adopted protocol for agent identity yet. What 1Password ships, what IDENTOS ships, and what the browser-agent platforms build may converge — or may leave you migrating between incompatible approaches in a year. Early adoption buys you safety now at the price of some rework later. For the password-sharing problem, that trade is still worth it. For a full platform commitment, go in knowing it.
Platform lock-in is a real risk. If one vault holds every agent key and one vendor's approval flow gates every sign-in, leaving that vendor becomes a project, not a settings change. That may be an acceptable trade — password managers already hold that position in most of our lives — but count it as a cost, not a footnote.
Small teams may not need an enterprise policy engine yet. If you are two developers with four agents, a written inventory, scoped tokens, and a calendar reminder to rotate keys will carry you further than a policy platform you have not finished integrating. Buy the layer that matches the number of agents and people you actually have. PolicyArc-class tooling earns its keep when "who approved this agent's access, and when does it expire?" becomes a question you cannot answer from memory.
And this is a developer story first, a consumer story later. The Developer Pulse numbers describe developers because developers are the ones wiring agents into real systems today. Consumers handing agents their banking passwords are the next wave of the same problem — which is precisely why the Chase warning matters. The tooling will follow the developers down-market. Your job is to not still be sharing passwords when it arrives.
The bottom line has not changed since the first paragraph. Agents are useful, agents are not going away, and agents need to sign in to things. All of that can be true while "sign in as me, with my password, forever" is a bad answer. This week gave developers the first mainstream alternatives. Use them — starting with the unglamorous work of listing what your agents can reach, and taking your own password back.
FAQ
How do AI agents log in today?
Most agents today log in with credentials borrowed from a person: a shared password, a long-lived API key pasted into a prompt or .env file, or a broad OAuth token. Newer approaches give each agent its own scoped, short-lived credential, or a per-agent key that requires human approval for every sign-in.
What is 1Password for Agents?
1Password for Agents, launched October 22, 2026, is a feature where each AI agent signs in with its own unique digital key instead of your password. You approve every sign-in attempt on your own device, and the actual password never reaches the agent. 1Password lists it as included in its Individual and Family plans.
Why are banks flagging agent activity?
According to Axios reporting, US banks are detecting unverified agentic activity on accounts. An agent signing in with your password from an unfamiliar location or automation pattern is mechanically indistinguishable from account takeover fraud, which is why Chase has warned customers not to share credentials with third-party agents.
What is an agent identity?
An agent identity is a distinct, revocable identity for a single AI agent — separate from any human user — with its own credential, limited permissions, and an audit trail. It lets you grant task-specific, time-limited access and revoke that one agent without changing your own password or breaking other tools.
What should a developer do first?
Inventory every agent you run and what it can reach, then kill shared credentials first. Move agents to scoped, short-lived, or per-agent credentials, add time limits and audit logs, and make sure you can revoke any single agent in one click.
What is IDENTOS PolicyArc?
IDENTOS PolicyArc, which reached general availability on October 23, 2026, is described by IDENTOS as a single place to define, enforce, and audit access policy for people and agents, including task-specific, time-limited access grants.
Originally published on Pick a Tools.#security #ai #programming #devops #software #coding #development #engineering #inclusive #community
Your AI Agents Are Logging In With Your Password. Banks Have Noticed.
