The AI Agent Found the MFA Backup Codes in a Downloads Folder.1Password Is Solving That Problem.

The AI Agent Found the MFA Backup Codes in a Downloads Folder.1Password Is Solving That Problem.

BackerLeader 43 227 380
calendar_today agoschedule6 min read

An AI agent was supposed to automate a task on GitHub using credentials it had been intentionally provisioned. Instead, it found different credentials sitting on the device, signed in with a completely different account, hit a two-factor prompt, and kept going — it located the backup MFA codes in a downloads folder and used those too.

"It got to the two-factor screen where it didn't just know the username and password, but then it got to the text message screen," said Jason Meller, VP of Product at 1Password. "We thought, surely, okay, that would have stopped it. No, it found the backup codes for the MFA in their downloads folder without any prompting, and then suddenly was in GitHub and it was performing the actions dutifully under the wrong account."

That story is the clearest illustration of the problem 1Password's new research puts numbers on: 40% of developers grant AI agents persistent access that outlives the task it was created for, and standing credentials — the plaintext kind sitting in downloads folders and .env files — are exactly what an unsupervised agent will find and use if the access it was actually given isn't enough to finish the job. "These agents — they don't know better," Meller said. "They don't have this concept of right or wrong, or I shouldn't use what's available to me to complete the task."

1Password launched its answer the same day the research went public: 1Password Privileged Access, which doesn't guard standing access the way traditional PAM tools do — it aims to remove standing access altogether.

Why not just build a better guardrail on top of what exists

The obvious approach to controlling AI agent access would be a proxy layer sitting on top of existing identity systems. Meller said that's deliberately not what 1Password built. "We don't want to build this sort of oversimplified layer that really boils everything down into something that's so simple that you really can't do anything well with it," he said. Instead, Privileged Access orchestrates the identity and access systems that already exist — AWS IAM and similar cloud-native tooling — and adds a policy layer that produces consistent outcomes across environments, rather than replacing what's already there.

The friction problem was just as important to the design as the security problem. "If you're a developer and you need to get access to a privileged system, and you know that the second you integrate with that PAM, you have to go through a 40-tier approval chain, you're going to resent that — you're going to look at the backdoor ways to get in," Meller said. The default outcome Privileged Access is built around is access granted immediately, based on identity, context, and history — is this the on-call engineer, have they accessed this system before, are they on a managed device — with manual approval gates layered in only where a customer wants them.

For agents specifically, that design goal gets more literal. "We can't have 40 agents waiting in line to get someone to just rubber stamp their access into the production system," Meller said. Instead, 1Password's approach is what he called "governing the stay" — let the agent in, but watch continuously as it acts.

What "task-scoped" actually means in practice

An agent doesn't just get a permission set when Privileged Access provisions it — it gets judged, action by action, against the task it was assigned. Meller's example: an agent given read, write, and delete access to a database to diagnose why production went down. The permissions exist, but "when it goes to actually do something destructive like a delete or a write, we try to judge in the moment: is what it's trying to do here in alignment with the task it initially had?" An agent debugging an outage has no obvious reason to be deleting rows, so that action gets intercepted regardless of what its account technically allows.

That judgment is possible, Meller argued, because of something structurally different about agents versus human users. "These AI agents — they think out loud. They tell you why they're going to do something, and they talk about it ad nauseum. This is very different from humans, who don't want to tell you why they're doing anything." A human asked why they need system access might type "test123." An agent narrates its reasoning the whole way through, which gives a governance layer something concrete to evaluate against.

Whether that means a literal fresh account per task depends on the system. For something like a database, Meller said 1Password will provision and decommission thousands of just-in-time accounts if that's what the integration supports. For larger, higher-latency systems, the model shifts: broader account-level access gets provisioned once, and the real governance happens at the tool-call layer, intercepting individual commands as the agent issues them. "The reason this is important is that these systems we're integrating with were never designed for this level of granularity," Meller said. Even a database — often the most granular system available — has no native concept of "read this row, but only if it doesn't contain PII." That distinction has to get built above the system, not inside it.

Human access and machine access get treated differently, on purpose

The 1Password research distinguishes human-style access (an agent logging into a web front end like a person) from machine-style access (an agent calling an API directly), and Meller said Privileged Access treats them differently by design, pushing agents toward API-based access wherever possible. "Websites can change at any moment and do anything," he said. "Today it might be safe, and then tomorrow they introduce a feature that suddenly makes something really unmanageable, scary possible." APIs offer a more stable, more auditable surface — a meaningful distinction for any team deciding how to wire an agent into a legacy system that was built for people, not processes.

Prompt injection is a different problem, and this doesn't fix it

Asked directly whether removing standing access blunts the risk behind the report's prompt-injection findings — 47% of developers reported an agent taking an unintended action after following instructions buried in untrusted content — Meller didn't oversell it. "Prompt injection is a separate risk, and this is a mitigating control for if that risk is realized," he said. What changes is the blast radius, not the odds of it happening: an agent that's had its underlying mission hijacked can be detected mid-action and ejected from the privileged system before it does damage. Reducing an agent's actual exposure to untrusted input in the first place, Meller said, "is not just a one-password problem to solve — that's a general industry problem."

More verbosity, not less, and a bet that AI can make sense of it

It might seem like ephemeral, task-scoped accounts would simplify auditing by generating fewer, cleaner logs. Meller argued the opposite is the actual near-term goal: "Right now we're not looking for simpler. We're looking for anything — right now we have no information about what AI agents are doing, and that's untenable." His bet is that the volume of logs an agent-heavy environment generates is itself solvable with AI: large-scale meta-analysis across those logs, feeding back into policy tuning so agents hit fewer dead ends over time. It's also, he argued, the missing piece in the current AI ROI conversation. "We've been spending like drunken sailors on tokens. Where's the ROI?" Meller said. "The reality is ROI is happening, but it's being misattributed to human beings" — without visibility into what agents are actually doing on a person's behalf, it's hard to separate a human's productivity gain from an agent's.

The migration path, if you're already exposed

For teams with agents already running in production on standing credentials today, Meller described an incremental path rather than a rip-and-replace: first, get existing standing access into a vault. Second, make the vault the broker of connectivity itself, rather than letting the agent reach for access using its own tools — which puts a governance layer in the loop, watching the tool calls as they happen. From there, intelligence and policy get layered on top of that visibility, judging whether each action the agent takes is actually relevant to what it was asked to do.

1Password is also extending this work into discovery. At Black Hat next week, the company is set to announce Developer Watchtower, a capability that scans developer devices for standing credentials sitting in plaintext, so teams can identify what needs to move into a vault before it becomes exactly the kind of access an ungoverned agent can find and use on its own.

🔥 Join developers growing publicly
Share your knowledge, build in public, and grow your developer presence with a global community.

More Posts

Your Backup Data Knows More Than You Think. HYCU aiR Is Finally Asking It the Right Questions.

Tom Smithverified - May 14

How I Built a React Portfolio in 7 Days That Landed ₹1.2L in Freelance Work

Dharanidharan - Feb 9

AI Agents Don't Have Identities. That's Everyone's Problem.

Tom Smithverified - Mar 13

Why Are There Only 13 DNS Root Servers For The Whole World? Is that a problem

richarddjarbeng - May 7

The Re-Soloing Risk: Preserving Craft in a Multi-Agent World

Tom Smithverified - Apr 14
chevron_left
15.6k Points650 Badges
191Posts
117Comments
81Connections
LLM Training & Evaluation Specialist with hands-on experience building major AI models. As one of th... Show more

Commenters (This Week)

12 comments
7 comments
4 comments

Contribute meaningful comments to climb the leaderboard and earn badges!