When an AI agent needs to access your CRM, retrieve records from your database, and send emails on your behalf, whose identity is it using? What happens when no one knows the answer? Corridor’s Chief Product Officer Alex Stamos and 1Password’s CTO Nancy Wang joined the VB AI Impact Salon Series to explore the new identity framework challenges that come with the benefits of agent AI.
"At a high level, it’s not who that agent belongs to or what organization it belongs to, but what authority that agent is operating under, which then translates into permissions and access," Wang said.
How 1Password ended up at the center of the agent identity problem
Wang traced 1Password’s path into this territory through its own product history. The company started as a consumer password manager, and its enterprise footprint grew organically as employees brought the tools they already trusted into their workplaces.
"After those people got used to the interface and really enjoyed the security and privacy standards we provide to our customers, they brought it on-premise," he said. The same dynamic is now happening with artificial intelligence, he added. "Agents have secrets or passwords just like people."
Internally, 1Password navigates the same tension it helps customers manage: how to move engineers quickly without creating a security mess. Wang said the company is actively tracking the ratio of incidents to AI-generated code as engineers use tools like Claude Code and Cursor. "It’s a metric we monitor closely to make sure we’re creating quality code."
How developers are exposed to huge security risks
Stamos said that one of the most common behaviors that Corridor observes is developers putting credentials directly into instructions, which is a huge security risk. Corridor flags it and sends the developer back to managing the appropriate secrets.
"The standard thing is that you just take the API key or your username and password and just paste it in the request," he said. "We find it all the time because we are connected and take command."
Wang described 1Password’s approach as working on the output side, scanning the code as it’s written and removing any plain text credentials before proceeding. The penchant for a cut-and-paste method of logging in directly affects 1Password’s design choices, which is to avoid frictionless security tools.
"If it’s too hard to use, to download, to run, it’s not going to be secure, because frankly, people will bypass it and not use it." he said.
Why can’t you treat an encryption agent like a traditional security scanner?
Another problem in creating feedback between security agents and coding models is the false positives that very friendly and agreeable large language models are prone to. Unfortunately, these false positives from security scanners can break an entire code session.
"If you tell him it’s a flaw, yes, sir, it’s absolutely a flaw!" Stamos said. But he added: "You can’t give a false positive, because if you say that and get it wrong, you’ll completely destroy its ability to write correct code."
This trade-off between precision and recall is structurally different from what traditional static analysis tools are designed to optimize, and significant engineering is required to achieve the required latency of a few hundred milliseconds per scan.
Authentication is easy, but authorization is where things get tricky
"An agent typically has more access than any other software in your environment," Spiros Xanthos, founder and CEO of Resolve AI, mentioned in an earlier session at the event. "So it’s understandable why security groups are so worried about it. Because if that attack vector is used, then it can both result in a data breach, but even worse, maybe you have something in there that can act on behalf of the attacker."
So how do you give autonomous agents comprehensive, verifiable, time-bound identities? Wang pointed to SPIFFE and SPIRE, workload identity standards designed for containerized environments, as candidates are tested in agent contexts. But he admitted the fit was rough.
"We kind of stuck a square peg in a round hole," he said.
But authentication is only half of it. What is an agent allowed to do once they are credentialed? Here, the principle of least privilege should be applied to tasks, not roles.
"You wouldn’t want to give one person a key card to an entire building with access to every room in the building." he explained. "You also don’t want to give the agent the keys to the kingdom, the API key to do whatever it needs to do forever. It should depend on the time and also the task you want the agent to perform."
In enterprise environments, providing comprehensive access will not be enough, organizations must know which agent is operating under what authority and what credentials are being used.
While dismissing the product of private solutions, Stamos pointed to OIDC extensions as the current leader in standards negotiations.
"There are 50 startups that believe their proprietary patented solution will win," he said. "By the way, none of these will win, so I wouldn’t recommend it."
At a billion users, outliers are no longer outliers
On the consumer side, Stamos predicted that the identity challenge will coalesce around a small number of trusted providers, most likely platforms that already integrate consumer authentication. Referring to his time as CISO at Facebook, where the team was handling around 700,000 account takeovers per day, he re-explained what scale does to the edge case concept.
"When you’re the CISO of a company with a billion users, the corner box means a real human toll," he explained. "So identity, for normal people, for agents, is going to be a big challenge going forward."
Ultimately, the challenges CTOs face on the agent side stem from incomplete standards for agent identity, improvised tools, and enterprises deploying agents faster than frameworks designed to manage them. The way forward requires building identity infrastructure from the ground up around what agents actually are, not improving what’s built for the people who create them.
