Ryan first catches up with Dataiku co-founder and CEO Florian Douettea to chat serious agentic systems and why they require intentional frameworks, orchestration, governance, and reusable, documented data products. Then, 1Password’s CTO Nancy Wang returns to the show to discuss why current identity standards don’t fit the new world of agents, especially when ephemeral agent swarms make attribution to a single user difficult.
Dataiku orchestrates data stacks and lets you create analytics, models, and agents.
Florian previously appeared on this program in an episode recorded at the last HumanX conference.
1Password keeps your credentials secure through end-to-end encryption, zero-knowledge architecture, and more. You can learn more about building secure agent swarms at their blog.
Nancy Wang previously appeared on the pod in March 2026.
Connect with Florian on LinkedIn.
Connect with Nancy on LinkedIn.
TRANSCRIPT
[intro music]
Ryan Donovan: I'm here at HumanX with Florian Duarteau, CEO of Dataiku, and we're catching up. Last time we spoke, it was about the data. We've moved on to agents, right? Yesterday, in the opening video, they talked about moving to the boring version of AI, the agentic, safety, governance. How are you finding where the agent space is going right now?
Florian Duarteau: I think that compared to last year, the agent space became pretty much real. Last year, we were just launching our agent framework within Dataiku, and now you've got, yeah, a majority of our customers are building agents. And for them, it's new. But another thing is that agents is not just about building those fancy agents. It's not just about unpacking OpenClaw and having fun on your laptop. What we are seeing is agents that are replacing a more expert back-office type of task, agents for the supply, agents to optimize your manufacturing production, agents to accelerate credit risk assessments in banking, agents to accelerate clinical trials. It's like all of those back-office efficiency-driven things, well, arguably where the money actually is. I think that's where Agentic has the most impact now. And it's indeed the boring, high-risk, high-impactful part of Agentic.
RD: Right, yeah. Although those things are not always things people want to do, but also they are very data-hungry applications, right? What's the Agentic impact on data and data processing?
FD: The impact of Agentic in data and data processing is that the requirement of transforming the data, data quality, ability to putting their one umbrella structured data is just becoming a thing. It's not just about doing BI. It's about building reusable data products that are actually documented so that your agent can actually leverage it. It's about manipulating unstructured data and also put this semantic layer on top of unstructured data. And so indeed, most of our customers now are building a semantic layer, like as a description of the data set, as soon as they are building a new data product. And it's new. And it's becoming part of the lifecycle of building and manipulating data.
RD: And when you say part of the lifecycle, the part of the lifecycle of the data itself or the software development lifecycle in general?
FD: It's part of the lifecycle of an agent to actually manually build the data and so on. And I think that part of the challenge or the way we think there's a shift on the market is that one way to think about Agentic a couple of months ago only was, “let's build an agent and connect some MCP here and there and it will federate things magically and it will work”. I guess the issue is that in many use cases it's not working well enough and so you need to get back to more, let's say, control project use case-based environment where for a given use case, you are building the data foundations, you are building the system of agents that will be working on top, and you need to provide this consistency in order to actually get the results you want.
RD: Are these Agentic interactions with the data, is it changing how people are storing and managing data?
FD: A bit, meaning there is definitely more appetite for new systems. I think that our customers are also... considering lots of variants of ways to store the data using Iceberg and more open formats, making sure that the data they are leveraging is reusable, additional questions about security layers on top of the data, and how they can be instantiated in the Agentic world. And those toppings are top of mind, and they were less top of mind.
RD: So a lot of conversation lately about agents has been, what do you give them access to? Especially with the sort of internal proprietary data that's super sensitive, super important, valuable, especially when you're talking about a medical trial. What sort of paradigms are rising to make sure that data is protected?
FD: Yeah, I think that's part of the problem not solved currently by the market completely is having a end-to-end trust layer where you've got unified identity management between agents and human and access to data online. Meaning this is pretty much still an open problem. Why? Because it's not clear what type of data access you exactly want to give to an agent when it's accomplishing its task. That's the open problem. What we see being done is our customer replicating the existing data access and building the trust layers in order to build practical applications. When some of our customers leverage our platforms to accelerate sales automation, enable their sales team to have automatically the CRM updated using the transcript of the call so that instead of the salespeople doing the CRM action themselves, it was automated. Simple replicable use case. In that case, the security layer is pretty clear because the person doing the call has access to the call. The CRM update can be done on behalf of the salesperson himself or herself. And it's a pretty easy security mapping you can do. But you've got at the same time, sometimes more complex situations, especially in regulated industries and pharma where you've got lots of personal information and questions about what you should or should not do. And here, indeed, you have to be more careful in terms of understanding what should be the security mapping.
RD: Can you just do the security mapping as the same sort of user access control that the owner of the agent does? Or do you find that you need more granular security?
FD: More granular security, especially when you get into agents that do not necessarily have one owner or operate on top of something happening in the systems on their own, as their own kind of like persona. Because at this point, you want the agents sometimes to have access to all of the data in order to be able to build aggregates and so forth, but some other times the same agents or the same agentic systems to be way more narrow in terms of what they can access, who they should impersonate, especially if it's about answering a point question from a given user. So that's where you actually need to rebuild an intentional security layer on the agentic application itself.
RD: I've heard from some people building the agents directly into the data sources. Are you seeing that? Is that something you'd recommend?
FD: Now we see more and more the understanding that you can't really build the agents directly on top of the data sources, or not only, because most agents will end up manipulating live data coming from the application systems themselves, and more offline data coming from a data lake or a data warehouse, and they have to mix both in order to be relevant. Because you can't get the performance or the holistic view on data on the live systems, but you also cannot do the real-time analysis or check if you just use a data warehouse. So in order to get the best of both worlds, you need to have federated access to the data.
RD: And do you think you give a single agent federated access, or are you one of those folks who believes in this sort of like... smaller agent swarms?
FD: You definitely get to the point where you can use agents and subagents in order to package sub behaviors and kind of like, organize your code and organize your systems. Indeed, at the end, when you want to build the full learning systems, you end up to package a full use case as a multiplicity of agents that can be all tested on their own and can possibly chain in order to accomplish broader tasks. And so you have to build all of that together.
RD: I've heard of the the data applications for agents are one of the big touted applications for agents. But I've heard of some horror stories of agents hallucinating in the data analysis stage. Are there ways to guard against that?
FD: Yes, I know. I think that what we see is that our customers that want to build a serious application take it seriously. One of our customers is Rush, and they build an agentic system for their patent application process, and they take it very seriously because it's an important problem for them. So that's where you have to, meaning if it's a serious problem, hallucinations are an issue, and you cannot just put a prompt, put it in cloud, and hope for the best. Meaning it's not working like this.
RD: Yeah.
FD: The way to think about it is that every agentic system needs to be assessed around the three dimensions. But from my perspective, the, let's say the formula of agent success. You've got the people dimension, the orchestration dimension, and the governance dimension. People dimension is what are the skills the agent should have in terms of human skills that it actually replaces, and who are the people these agents should collaborate with. Do you understand that? The orchestration dimension is like, what are the different technologies or ways the agent should orchestrate its own decision, and what are the systems it should operate upon? And the governance dimension is, how important is it that the agents take right decisions versus not? And what are the regulated risks? The company risk, the regulation risk that the agent is operating into, like in terms of domains. And depending on the answer of those questions, the way you should think about agentic systems is very different. If you're building an agent that is doing fairly repetitive, but fairly low-level tasks in a non-regulated part of the business, if it fails, it's okay because it's ultimately just about, like, presenting information in a certain way. And if it doesn't really orchestrate or integrate into any complex systems, you're operating a low-risk agent. And there are many, many ways you do it. Maybe it's only something you can do on yourself on the enterprise ChatGPT and call it a day.
RD: Yeah, that's a good point. There's a lot of enterprises that have a very low risk tolerance, even from the supply chain. I know folks who have lost local administrative rights on their computers, their work computers, because they got some client, banking industry client, that has very low risk tolerance. How are those sort of low-risk tolerance organizations looking at agents, which have, like you said, a potential for a risk?
FD: Yeah. They look at it by building their agent and choosing their agentic framework intentionally. And why? Because from a people perspective, they build agents that encapsulate the skills of very highly skilled specialized individuals. Like if we've got one customer billing agents to replace some of their middle office in terms of credit risk and collateral movements in banking, so complex rules that you have to apply in order to understand why you had, like, some movements in your quality rules for risk because of like some trade happening versus not, or some change into inflation rates, like this type of things. Complex rules.
RD: Yeah.
FD: It's a complex orchestration because we've got like, lots of different steps to do things that you have to do in a certain order. And it's a highly regulated industry and process and domain, as in like if you get it wrong, you will be fined. And it could be like hundreds of millions. So high risk. So in that case, it makes no sense to build an agent the same way as you build any other agent. And you need this type of like, expert framework for agents, which is what we're focusing on because we believe you need large enterprise, need platforms tightly connected to their data and with high governance in order to build certain types of agents.
RD: Yeah. It seems like people talk about the frameworks. A lot of organizations, they run into things like numbers, finances. They say this is not a job for an agent.
FD: It is if you actually apply it properly. And it will be. Meaning, it's not a job for an agent if you try to do it on your own on blockchain and Pidentic and hope for the best without even knowing whether you're using Opus or Sone.
RD: When you mean job for an agent, you mean for the full framework and not for the LLM at the core, right?
FD: Yeah, the LLM at the core is ultimately a tool that will be commoditized.
RD: So it becomes another tool, part of the agentic workflow. Do you have opinions on the sort of open source versus closed source LLM?
FD: I think they're catching up. I mean, they're just, I mean, they've been consistently nine months, 12 months behind in terms of high-quality frameworks. I think that it's bound to stay the same for maybe still one more year, but definitely there is room for both, depending on the type of task you're having and your ability to deploy or you need actually to deploy locally. I think that we've got more and more customers in hybrid infrastructure where they combine cloud or on-prem for both their data and their LLM workloads. And I think it's for good reason. If you're a manufacturer, you've got factories. Ideally, you want your factory to be able to operate without the internet because production is expensive. If you operate into a IP, R&D type of industry, like pharma, like chemicals, like [indistinct], your cyber risk is elevated because state level type of actors may try to steal your process or your formula. And so a lot of your R&D needs to happen in very secure environments. And so indeed, again, maybe you're using open source models because you want everything to be enclosed into a physical perimeter.
RD: They want the additional security of on-prem, right? You know, when we talked last year, like that was the first inklings I think I heard of agents. It's the first time I heard MCP. Now it's all people want to talk about. If you want to look into your crystal ball, what do you think we'll be talking about next year?
FD: I think that we will be talking more and more about certain subtype of agents and that we will start having the notion of front office agents versus expert back office agents, for instance. I think that will become specializations. You know, at the same time as between ‘97 to ‘99, when instead of talking about website and HTML, we started to talk about blog and e-commerce and Ajax. Like you will have this. The front end, the back end. You'll have this specialization slash notion of like asynchronous type of things. And that will become front and center. And because indeed, when you look at what's the future, it's about having more and more expert-type of agents that will be running continuously in the background and interacting with human asynchronously. Like, you wake up in the morning, your agent is there, he done lots of work in the evening, you've edited dates, you work differently because your work from 9 to 11 will be about checking the task of the night and like challenging them and putting them back. It's a different type of work, like a different type of work day.
RD: We won't just be going to the beach having Mai Tais or... waiting for our turn into the, you know, the solar green machine.
FD: Hopefully not. I'm not sure if I'm into Mai Tais. And also sun is bad for you. More importantly, I think there will be a more creative and important work to be done. Just very differently because you will have like, agents working for you, indeed doing work at night. 9 to 11, you check the work, you challenge it. Then you go to, maybe people will have a longer lunchtime, to let the agent do the work between like 11.30 to 1.30, which is where maybe French people will have some edges.
RD: You have the advantage, yeah.
FD: Yeah, yeah, because we love lunchtime. And during lunchtime, we would have like iterated, and then you get back to it.
[music]
RD: I'm here at the HumanX recording on the floor. We're talking about identity and user access
controls for agents. And my guest today for that is a returning customer, Nancy Wang, CTO at
1Password. So welcome back to the show, Nancy.
Nancy Wang: Thanks so much, Ryan. Happy to be here in San Francisco.
RD: Yeah. So we talked about this a little bit before, but the profusion of agents, background agents, agent swarms is making the... scoped access control a lot more important. What are the things you're sort of seeing in this space?
NW: Yeah. So maybe just taking it back to first principles and fundamentals. So today, and I'm sure you're hearing about this in online forums, be it Reddit or X or LinkedIn, right? I think the industry is converging on the realization that existing identity standards are not sufficient anymore for agents, which act like humans and act at the speed of machines. And what that means is if you think about traditional human identities which are provision, they're usually in a system of record, maybe HRIS or identity provider IDPs. They take a long time to provision, to get started, right? They're usually managed within the context of organizations. But agents, well, they're ephemeral, right? They can be spun up now in the order of milliseconds, right? Especially as we think about agent sandboxes, as you mentioned yourself, Ryan, swarms, right? Hundreds of agents. In fact, recently we did an exercise internally at 1Password of: can we spin up a swarm of agents for the purpose of debugging production databases, right? For our incident response teams. And so in that world, when you have hundreds of agents acting together for a purpose or for a workflow, how do you know which agent did what, right? Especially if you're going to give, for example, sensitive credentials to these agents. Was it one out of 100? Was it three agents out of 100? How do you now attribute that action, just like you would, right, to a single individual developer to that individual agent? And this is where, for example, when you have, you know, these device– what we call signals, right, that speak to a provenance of an agent. That's really where we believe, as 1Password, what contributes to solving this issue. And given where, you know, we are today, which is on device, so we can contribute device signals, right? Device posture signals, which is: which device did this agent originate from? Or, for example, what browser session did this agent act upon, right? Now we can actually now start providing context and color to which human delegated this authority to which agent, who spawned this agent, where was this agent spawned, and most importantly, under what context or authority or purpose did this agent come to be? And all of that speaks to provenance and essentially this almost birthright of an agent, right? And so with that knowledge then comes, okay, what should this agent have access to based on what it was created to do? And so now this goes into our philosophy of no standing privilege, right? And so a lot of, I would say, similar to how this world of zero trust came to be, right? Now we're going to apply zero trust essentially to agents. But instead of zero trust in its traditional form, which is, well, what can be accessed via the network? What resource to resource, right? Now it's anything to anything, right? Because if you think about, you know, the proliferation of MCP clients, right? Like Claude, right, Cursor, the power really here is no longer in just orchestration alone, right? It's going to be in system records because if you're an MCP client, well, you can now simply make your own tool calls, right? Integrate with systems based on what the model thinks is correct.
RD: Make your own tools, too.
NW: Right, exactly. And so this is going to be now, well, what access can you grant, right, at the time of? And so this is going to be just in time, just for task, which all then ties back to provenance and also contact.
RD: I've seen a sort of discussion on whether, you know, you have a single agent that gets all the access or you have multiple agents, each with sort of specific access tasks. Do you have an opinion on that?
NW: Well, we're really going to see both, right? Because the world of a single agent that does a workflow end-to-end, sure, there's definitely going to be use cases, right? It all comes back to customer-driven use cases for those single types of agents. So, for example, for things that Romina and I work on around writer– writing blogs or coming out with points of view, right? Usually that's single agent workflows that I have running in the background. Now, for more complex workflows, so think about ERP, procurement, right, especially within the world of engineering. One agent might be, for example, submitting merger requests. One agent might be actually doing security reviews. One agent might actually be constructing the build, right, and the deploy. All of those, just like you would have separate microservices, you would have separate agents doing in order to scale maybe independently, parallelize tasks, but also, for example, to localize blast radius in case there are, you know, for example, the issue of prompt injection is still very real for agents.
RD: And I mean, you're talking about them accessing ERPs, which is, you know, things that enterprise businesses are run on. Are there points where, you know, you want to limit an agent to not do anything? Like... do you want to prevent an agent from spending money or, you know, moving resources towards an error would cause great harm to a business?
NW: Yeah. In fact, actually, I was just speaking with actually one of my friends who heads product for, let's just say, a pre-IPO company that does very sensitive tasks around FinOps. Right. Let's call it that. And what they actually found was one of their agents that was running in the background around managing large sums of money for investment firms almost actually sent the money to a different account than was intended. It actually reasoned about itself across multiple steps. and actually was stopped from doing so, not by humans, but because of multi-factor authentication, right? Because it didn't have the MFA, it was not able to actually wire money to an unknown account. But if we think about that, right, and this is one of the most reputable companies out there around FinOps, this is, I would say, the situation that we're finding ourselves in. Because of the great productivity gains that agents bring, right, you want to leverage, right, that opportunity, that step-up, 10x-er in productivity. At the same time, our security guardrails have not kept in place, right? And so this is where, you know, going back to principles of zero trust around access– this is where actually access does help provide guardrails around the last mile problem. As in, if you're not able to access credentials for a bank account, if you're not able to do MFA in this case, your agents actually stopped from doing, for example, very sensitive tasks that might run counter to your original intent.
RD: So we've talked about a lot of just-in-time access, temporary access. How does that work? Because I think a lot of access is sort of, you know, time-based tokens with a refresh on it or something. How do you limit that to, you know, just a single call or something?
NW: Yeah, so this is where, for example, the security guard rails have not kept up. In fact, many of our, I would say, OpenClaw users out there, they have organically started their own 1Password CLI integrations to enable OpenClaw. And so, for example, with any project, not just OpenClaw today, if you hook up, let's say, cursor or cloud code to our CLI products, we will prompt you every time, for example, the model or the agent needs access to credentials. And that could be done, for example, if you're on our laptop via like your biometrics, right? Fingerprint ID, touch ID. That could be one way, for example, where you have a human in the loop approving, essentially authorizing the request for the agent to have access to credentials. Now, in the future, you could also imagine if you provide very scoped down instructions, which is, you know, I have an agent that is authorized by, let's say, Ryan, right? To go make purchases for Stack Overflow. Maybe you need, you know, a fleet of new microphones for an event that's coming up. That's great, right? So the agent would be authorized to go make purchases of microphones. Perhaps you have like a certain dollar amount that you've authorized this agent to do, right? And if it meets all of that criteria, well, then essentially it's assuming that workflow is pre-approved by Ryan, right? So that could be an example where maybe we could remove a human out of the loop for that specific workflow. Now, for workflows where reasoning is more going to be on the fly– so for example: if giving higher level prompts to this agent, which is, hey, I have a wedding coming up, right? This is the, let's say, general concept for this wedding. Go make purchases on my behalf. Well, then that might require more on-the-fly reasoning, which is, well, what type of flowers, for example, what type of other arrangements, et cetera, right, for that. If you haven't provided, for example, specific guardrails for that workflow, well,
then when do you insert the human loop, right? Or do you want to trust essentially the model with reasoning what guardrails wants to police itself, right? And so that actually opens up a much bigger question. But look, one of the things that we've partnered with actually Anthropic on, especially for Cowork, right, which is a product that a lot of users have now come to use to make purchases, right? Or to, for example, sign up for things or to register for things. That is now partnered with the 1Password CLI products to be able to actually provide credentials via the browser session. For example, when the Cowork agent is doing things on behalf of human users. I definitely see that as one direction that is going to continue evolving.
RD: Are you saying it can take the credentials from the browser session?
NW: So not standing credentials from the browser session, but for example, it works very much in the same way that our autofill for, for example, Chrome or Safari works today, which is when you're in a URL and the URL asks for specific fields to be autofilled, we can do that, inject that just in time for that browser session.
RD: I wonder, there's some of this sort of passing the human loop stuff almost sounds like O Auth but with the human– do you think there'll be new authentication protocols that are standardized and arise to solve this problem?
NW: Absolutely. In fact, internally, that's one of the angles in which we are taking with Foundation Labs. Obviously, you know, can't share before it's all public, but I can say at a high level. So one of the, I would say, internal projects that we're actually announcing in a couple months will be using the OIDCA protocol, which the A stands for agents. And so there's actually a field in there that talks about delegator authorities, right? So which human or a delegated authority to this agent to do what action? And so we're going to take that into consideration when we're thinking about things like brokering credentials for access. Now, in the future, taking kind of a, I would say, what we've built upon for the last two decades, which is storing now over 1.3 billion credentials across humans, machines, and developers as well, and now agents, is using those credentials to be able to attest to identity. Let's say Ryan has a driver's license that he stored in his vault. Plus, Ryan has, you know, credentials to Twitter. With your being able to access actually different sites that only Ryan should have access to, we're actually able to then do cryptographic proofs, what we call verifiable digital credentials, to actually prove that Ryan is indeed Ryan and has these attributes.
RD: So I've seen some stories of agents taking liberties, let's say. Open claw agents talking to other open claw. to learn new skills. Or I think Anthropic Cloud realized it was being benchmarked and found the benchmark repo and decrypted it. How do we prevent these agents from accessing perhaps authorized credentials in the wrong instances?
NW: I mean, there's also other examples too, where, for example, if you forgot your OTP codes, you could actually go into the downloads folder, right, and find your codes that way. I've also seen myself actually, when I was vibe coding a project with one of the models, that the model actually was able to reach inside the session itself, in memory session, and actually retrieve the credentials from that case. Now, obviously, as I would say, these use cases themselves are expanding. One of the areas that we as a security company are also going to pay attention to is all of the surface areas, right, whereby credentials could leak, be misused, or to your earlier conversation, prompt injection to models or agents to, I would say, get them to leak credentials. So I would say one of the things that have come across, especially around organic projects, as I mentioned, OpenClaw, or just even others amongst the developer community, is actually using 1Password as the only way that agents can not get access. So the nuance there is we will never reveal credentials in plain text to the agents, right? But this is more injected just in time into the runtime environment, right? So the agent can actually get access to sensitive systems, for example, right? So that's a nuance there, is the only way access can be given is via 1Password references.
RD: But I mean, like you said, it can reach into a session. and get credentials there, it doesn't need the password, right? Are you thinking about how to protect the session itself?
NW: Yeah, so there's, I would say, parallel tracks, right? So one is if providing guardrails such that access can only be granted via 1Password, right, solves for, I would say, a vast majority of use cases in which credentials could be leaked, access could be given inadvertently to things that you probably don't want to give access to. The other parallel track, and this is where it gets really fun, is actually working with foundation model companies to train models on safety behaviors, right? And so this has to be inherently, I would say, baked into the model waste, which is... essentially this is reward hacking, right? Not rewarding behaviors such as reaching into running sessions, right? Or going into download folders, saying that that behavior is bad. And so disincentivizing the model from doing this. You know, one of the things that we're super proud of as 1Password to have been built over the last two decades is being that trusted, now we're calling it runtime, you know, access orchestrator, right? Across humans, machines, and now agents. And just having that surface area, having built enterprise software products now for almost two decades, is very rare, right? In that you'll see a consumer product actually make the pivot into enterprise, but continue its consumer identity. And now actually that combined consumer and enterprise identity is what has actually catapulted us into that conversation with model providers, with agent builder platforms, into being that default access broker.
RD: Where can people find out more about 1Password and connect with you on the internet?
NW: So, in fact, if you're curious about reading more details about the agent identity gaps and also opportunities that we see in issuing and managing identities, our VP of AI and developer, Jeff Malnick, just released a blog around this that you can read more details around. If you're also interested in seeing all the developer products that we have, check out developer.1password.com. And just generally we’re also out there doing a ton of demos with our partners. We mentioned Anthropic, OpenAI, but we've also done partnerships with Perplexity, BrowserBase for browser infrastructure agents. So definitely check us out.
RD: Well, thank you for listening, everyone. We'll talk to you next time.
[outro music]