18:22
Welcome to the third day of Disrupt and welcome my guest. Thank you very much for being here. Gabriel Cohen, the last 6 months have been truly crazy. You founded your company a few months ago and rode the first wave of agent software. Nanoclaw, your software has already achieved great success thanks to the principle that autonomous agents should be safer than their predecessors. Why is this principle so important to you? When I started Nanoclaw, I started developing the project at the end of January, I was working on an AI-based marketing agency. And I started using OpenClaw. I've been using AI tools for a long time, and
OpenClaw was a pivotal moment when we did an experiment: "What happens if I plug advanced AI agents into everything?" Is n't that right? "Putting security aside, putting AI protection aside and plugging it into everything." And I found that I benefited immensely from it. It did the job like a real worker. But there were serious security gaps. So I set out to develop a solution that would give me the same value without compromise, without the security issues. And.I see a big challenge today in making AI safe for everyone. This shouldn't be something only available to experts, and it shouldn't require compromises in security. So, Rick Smith, thank you very much for being here.
I think everyone knows Okta as the single sign-on provider that almost everyone here uses at work. But now we have agents in a corporate environment, which creates its own set of challenges. Has the business of verifying user logins become more difficult recently? There are two sides to the coin here. Let's look at the aspect of agents, which is now mostly an insider threat, which we see today. When we hire an employee, we go through an onboarding process that gives them access to specific programs, data, etc. And when implementing agents, we generally do not use this practice. However, we personify agents just as we do human workers. And I mean, we're even talking about replacing them in that capacity. So, for us in business, things
have changed dramatically because clients are coming to us with the question: how do we provide the same kind of governance that we provide for our employees, but at the scale and speed that AI requires? So I think this is very useful for many businesses , because we live in times of some confusion. And I think we get too carried away by the technical capabilities of these things, without addressing the fundamental principles of their protection. We forget basic things, like the fact that identification has always been the last line of defense. So we're really implementing this, and it's really accelerated a lot of the discussions that were mentioned.
Yes. If I may, I want to add and fully support what Rick said. We talk to some companies and hear from them that they now view AI spending and headcount as interchangeable. That is, a department in an organization receives a certain budget and can use it both for AI and for hiring new employees for the team. AI agents are actually becoming such employees. They are connected to accounts, they have identification. We need to protect ourselves from the internal risks of these agents exploiting our systems, but we also need to protect the agents themselves. We need to be sure that the tools they use are safe. If the agent has a browser, that browser must be updated. Otherwise, someone could hack into the agent's environment, use the accounts they have
access to, and steal data from there. Earlier this year, you published a blog post that said, and I quote, "Don't trust AI agents." The logic seemed to be that AI agents are inherently prone to misbehavior. So how do you and other startups balance the need for autonomy and ensuring that your agents, or anyone else's, don't get out of control? This is truly a key challenge. To benefit from agents, they need to be connected to everything. And Okta did a tremendous job of enabling this with XAA, and we joined that standard. They need to be connected to systems and they need to have some autonomy. If you sit and approve of something every second, you are not getting any real benefit from it.
This creates too many obstacles. The phrase "don't trust AI agents " is not about not using them. This is not about treating AI with suspicion. It means, "Use it, but approach it where there's no trust. It's not about instructions, where you tell an agent to behave well and hope they do. It's about verifiable execution that's outside the agent's training, outside their instructions, outside their environment. So that's how Nanocloud is built, and Nanocore, the agents that we provide to enterprises, are built on the principle of putting the agent in an isolator, right? Lock it down. And then purposefully connect it to data sources, to tools. And then enforce actions and policies outside the agent's environment. And by doing that and considering where you put
the approvals. Most of the time, an agent can do a long workflow. Look up information, pull it out of an email, populate a spreadsheet. You typically only need approval at one point, when they're going to send that spreadsheet to someone else or send an email to someone else. And we help enterprises set the right policies so that you can let agents do their job, run around in their own little world. And then only apply controls to those actions that really require human judgment and approval. Got it. And Rick, where do you think that balance is? What exactly do you think solves these problems?
Well, we're actually solving this problem. We're solving very similar problems, looking at them from a different angle. So when I look at Nanoco, you're very much isolating the agent, and if we talk about security, we always think of it as an onion. There are many layers to how we work with these practices. We take a broader approach to ensuring that agents only have access to certain tools. If they're acting on behalf of a human, we take that human's rights and allow them to be activated for that agent. So those access boundaries ultimately allow the same level of access as a human. All of these requests that we see about what they have access to are audited and are tracked so that we can audit or detect abuse, but the principles are pretty much the same,
although we're applying it to a broader enterprise scale. So what do you see in the broader Okta ecosystem in terms of common security mistakes that companies are making as they build their infrastructure around AI? I think the first thing we see is that they're looking to get value. So by that I mean they're trying to ultimately spend a lot of money on AI. They're looking to get mostly performance gains. And as they start to bridge that gap, they start to realize their security vulnerabilities. And for the most part, it comes down to very basic elements. So what data do they have access to?
What toolsets do they have access to? What applications do they have access to? What are their roles and responsibilities? That mapping doesn't usually happen upfront, and we're often asked to come in and help them with that process, and of course provide them with the infrastructure to do that. So can we talk about the notion of intent and trying to ensure, essentially, that the human intent actually gets implemented and becomes the desired outcome. So again, how do we find that balance so that agents do what they need to do and don't go beyond the Yes. The approach that we take is that we have control over specific tools and also specific actions within those tools. And those are the outer limits of those policies about what people in the organization
can allow their agents to do on their behalf, which are set by the IT department, the security department, and the AI director. And within those limits, individual employees can tighten those limits. And by default, agents are given the principle of least privilege, so they only get the tools that they need. And then you set specific policies for endpoints, for sending emails, for searching mail. But the alignment of intent is really necessary. And if the outer limits of security are supposed to be deterministic, then today, with the advent of judge models and the general improvement of models, it has to be there should be an additional layer of validation: what is the user's intent and is this action consistent with that intent? Part of this is to
automatically approve actions that otherwise wouldn't be allowed. Part of this might be to block actions that might be allowed. And the approach that we take is to force the user to specify an intent, or more precisely, to force the agent to specify an intent. So when I ask an agent to do some work in our product, the agent responds and says, here's what I'm going to do. Here's the plan. I'll look at the spreadsheet. I'll look at the email. I'll pull the information from Jira and check it against GitHub. And then I'll create a pull request. You approve the plan, and then the model judge checks each action and compares it to that plan. And it's not about whether it's safe at all. It's about whether it's consistent with
the plan that the user approved. So what advice do you have for founders and developers who want to create a similar technology or expand yours? What should they think about? We talk to large corporations, some of the largest in the country and the world. And we hear over and over again that they feel like they're falling behind. Right? They can't all be falling behind, but somehow they all feel that way, at least the vast majority say they're falling behind. They're trying to move very quickly. The people who are leading the AI implementation, many of them haven't spent a lot of time in the company they work for or in large corporations in
general. You talk to them-they're very optimistic. But then they're faced with internal processes within the company: security reviews, procurement, legal issues. They're trying to shorten processes that used to take 12 months. But at the end of the day, security reviews are impossible to avoid, and they shouldn't be. Right? So those processes really do take three, four, six months. I think it's important for those who are building today to make sure that if you work for a large corporation, you're not solving your own problems. Make sure you're solving their problems. But also make sure you're working on the challenges that will arise in 4-6 months, not the challenges of today. By the time you go to market, the challenges of today are
probably not going to be relevant anymore. You know, the newest model or the newest agent toolkit is just going to make them obsolete. Rick, I'd love to hear your thoughts on that. I'm going to take a step back and go back to intent-based authorization. So we're taking a step forward in that direction: when you look at start with deterministic granular access, and then the intent aspect narrows that down. And so in many ways, you have to actually define the semantics of accessing specific tools, performing specific actions, and what data is left at risk after that. And that's what we're working on right now. It doesn't require
human judgment to be involved in that process. It requires a real detection mechanism that allows us to make these decisions at runtime. Now, I think people should look at the history of the risk register in their organization, which is probably terrible. because all the CVEs that you haven't fixed are time bombs waiting to happen because of what's happening in the marketplace. I mean, you could be Pavel from St. Petersburg, run a rack of Mac minis with an open scale model, and just take down that infrastructure today. And it's an ever-increasing risk. Every six months, it gets worse, and the threat becomes more real. So when you really ask what needs to be done, you need to look back at 5 to 10 years of debt that's accumulated in your enterprise
and start actively getting rid of it, because there's a storm coming. So to what extent is agent-based security today going back to those security fundamentals like containerization, isolation, and just making sure that the fundamental security is real. Well, it speeds things up. I think the introduction of Mithos is the final nail in the coffin of this problem. There are a couple of factors: one, we can identify these vulnerabilities and do some penetration testing with these models, but there's a tyranny in the system, right? Only large enterprises and product companies can afford to enable these things, identify them, provide secure services to customers, and also implement AI to ensure timely patching, automation, and
software updates. So when we start talking about on-premises infrastructure, it becomes a spectacle of madness, because it's unclear how customers are going to keep up with all the updates that need to be made to that infrastructure. And if you look at it from a human perspective, you know, if we're talking about a regional hospital somewhere in the Midwest that's constantly being attacked by ransomware, they don't stand a chance. So those are the things that I'm most concerned about. So, I would say, in addition to what Rick said, that uh. from an infrastructure perspective, principles like least privilege, right? And building a system with least privilege, based on the premise that we don't trust agents, you're going to see uh
container egress, you're going to see uh even VM egress, and there was uh one such vulnerability recently disclosed by Vercel where someone reported a zero-day that allowed full uh VM egress. So you need to implement least privilege in your infrastructure, not just in terms of worker access, but also asking the question: what is this uh agent going to be able to do if it exits the container, if it exits this VM, what is it going to have access to? What can this pod access? What can this node access? What can this VPC access or this entire account access? And consider this uh scenario. And, Ultimately, it comes down to fundamentals. Uh, CVEs that have been ignored for years, uh, that
may have been sitting in the backlog because they couldn't be exploited from the outside. When you take agents, and increasingly a whole swarm of agents, and you point them at it, they look at your infrastructure like Swiss cheese and can just jump from one vulnerability to another, looking for a way out. So we really need to go back to basics and add an extra layer of thinking about that highly skilled insider in my infrastructure who's going to poke and prod every hole. There are certainly employees who are already using agent software on the corporate network today, and the corporate network itself may not even know about it. What advice would you give to balance the need to use agent software and experiment without
compromising the security of the enterprise? I think a lot of sensible security teams, uh, CISOs, uh, are saying that there's still It's too early, it's too scary, there are no ready-made solutions, so we have to restrict access. We can't let employees connect their agents, their AI to, uh, well, you know, their data, their spreadsheets, their data lakes. It's well-intentioned, it seems right, but in many cases they can actually compromise their security. I was talking to an employee at, uh, a big company, right? A big enterprise that prides itself on its security. And they were telling me how they were using their agents, and their agent couldn't connect to a data lake or a business intelligence system, but they wanted to create dashboards,
and the agents, you know, cloud agents create great dashboards. So they're going to their data lake. They're exporting massive amounts of customer data, right? Tens of thousands of records. They're uploading it, then they're sending it to Claude through a web interface, right? And they're asking him to run an analysis to create a spreadsheet for them. And they're doing this every week to maintain their dashboard up to date. It would be much more secure if that agent was connected through Okta, with the rules that we have in place, through the governance systems; so that the entire data access chain is audited; and so that the agent can only download the metrics that they need, instead of exporting huge amounts of data. So, on the security side, if you want to keep
the system secure, you have to find a way to provide access in a secure way. Rick, same question, where is that balance and how do you provide that advice? I really like that you gave me the opportunity to speak on that. That's exactly, exactly my area. So, yes, you should have policies about what data agents and employees should have access to Make sure that their actions are limited to the specific applications that they're given access to. But the reality is that even if you lock everything down, people are smart. So they export something in a spreadsheet, they'll give it to Claude, and now Claude has a new understanding of that data.
I've actually seen a case where that kind of action resulted in the company's SOC compliance is compromised. So it's a slippery slope, right? You're less concerned about those issues, although they are risky, and more about what could happen if one of them turns out to be an attacker or acts maliciously. So you have a new kind of insider threat as a result of this. Someone is trying to do something malicious, using the capabilities of tools like Claude for their own purposes. That's where you need to go back and look at the bottlenecks in your infrastructure. For example, is everything running over a VPN so that you can shut down network access no matter what's going on?
You know, are the most sensitive things in the data diodes if it really has to go that far? But these are the heightened security standards that need to be implemented today given the events, and we're still stuck in a world where security is secondary. We've started this process, and we have a lot of debt that needs to be cleared up so that these things can operate safely in our environments. So what happens when something goes wrong? Does agent software need a kill switch today? 100%. And I think it needs to be at different scales. Of course, we offer a kill switch so that we can terminate sessions for everything that an agent has access to, but you have to look at the broader enterprise
. That's one of the reasons why we work with a number of vendors in the Blueprint Alliance, which helps customers understand the relationship between all the security vendors and how to set up the enterprise to use AI safely. But I think we get too caught up in the idea of, " Oh, I have this on my laptop, I'll sandbox it, and everything will be fine." That's just not true. Gabriel, I'd love to hear your thoughts on that. Yes, absolutely. You should have a kill switch in our platform. We're integrated with Okta.
We have that level of security, but at the infrastructure level where agents are running, if they manage to get outside the virtual machine and they start probing your software or infrastructure, you need to have kill switches at many levels. So , it's not just blocking access to data. You need to block access to model inference. You need to be able to shut down your infrastructure. We have the ability to revoke access for a specific employee, change a policy, or block access to a tool. And we have a global kill switch. Just turn everything off, right? Not allowing everything that we've deployed in that account or VPC to have access to anything. And with the risks that we're seeing with OpenAI, Hugging Face, and swarms of agents learning to circumvent the
restrictions that you put in place, that becomes extremely important. But I think for most enterprises, for most companies, the conversations that we're having are a long way from an emergency stop button, because agent systems are running on laptops, in environments where there's no isolation. They're a long way from even starting to talk about implementing an effective emergency stop button. stop. So, looking ahead to the next few months or a year, what are your customers asking for in terms of features and what are they trying to achieve with your software? AI is moving from being used by one person to do their job. And it's moving to being a team function, right? People on a team are working together. And they're providing the flow of information
through the organization. Our position, our principled position is that every agent should have an owner-someone who is fully accountable for it. We're trying to build a system that's very similar to, and a little different from, what Rick mentioned, where the human is in the decision-making loop. We're trying to build solutions that are human-centric, where the AI is helping people, and ultimately the people are making decisions, setting goals, setting direction, and the AI is delivering that. Companies are asking for AI that works for the team. I think in the next few months we're going to get to AI teams, right? You could call it "swarms." It's a little bit It's scary. I think it's better to call it " teams." We know
that labs are working on this. Everyone who's at the forefront of AI is working with a team of agents or has a team of agents built for them. And that's the next big thing in the next 3 to 6 months. It seems like this is the new law of scaling. You scale training, you scale compute during testing, and now we're scaling teams of agents. From four to eight, you know, I have I think if we look ahead a few months, we 'll be talking about teams, you know, hundreds, and the leading labs seem to be launching thousands already. What are your customers looking for I like how you try to move away from pejorative terms to positive ones when you talk about agents.
You're asking, "Are you preparing for the future? Like, when will you have to work for one of them?" Stay on their side. Well, that's certainly the view of some labs that say agents are better than us at making decisions, and they're going to get better, and they probably will. So I think that's probably even the most likely outcome: agents are making decisions, and we're working for them. And half the time we're working for them, saying, "Oh, I need you to give me access to this account. Well, you know, turn on this API." So they've already made us work for ourselves, but if we talk about what kind of future
we want to build, I want to build a future where I still manage agents, not work for them. We're in the same boat. From our product perspective, our journey started with how to help enterprises enable agents to act on behalf of the end user. And that's evolved into now they want agent-to-agent interactions. We're talking about what the new commerce of agents looks like. And what's our position in that, and it's a whole new opportunity. Personal agents are emerging that we are now being asked to protect. So there are a lot of use cases that we have to help our customers with. I mean, these are incredibly exciting times. And we've been very fortunate to be able to help them solve a lot of the
security problems that they have so that they can realize the value of this investment. But it's been a crazy journey. Do you have any final thoughts or best practices that startups should be thinking about above all else with Agent-X software? Obviously, I'm in the camp of those who think that all of this should be regulated from an access perspective. But if I were to put on my security hat, the first thing I would say is, are you using an N-1 patch program in your organization today ? And if I were to look around this room and ask people to raise their hands whether they are doing it or not, I guarantee I would only see one. But this is a vital opportunity that every organization should be implementing right now. Because that's where
your gaps are, and there's a new way to do research very quickly to leverage each of them. And Gabriel, you know, you're six months to almost a year into your journey with the company. If you could go back and change anything, having experienced it, would you I think we're in an incredible position today. We were in this niche of personal agents for work. That's where I started. I sat down in February and started building my personal agent for work. And that's obviously the space that I think is getting the most attention right now. We have an enterprise platform that's being deployed to companies. And we're very close to launching a free version that anyone can access.
We have great investors, and Okta is actually an investor and joined our seed round. Full disclosure, I'm a big fan of theirs. Not biased at all As are we. And I wouldn't change a thing. Except to be more ambitious. And I think that's really important for anyone who's doing something right now. builds. Models and agents are getting better at a very fast rate. Things that you built a month or two ago now take half the time to build. And it continues to do that. So instead of building incrementally and trying to say, " Well, first if you're building for large enterprises, if that's where you want to go, " instead of saying, "We're going to build for small startups first, then we'll go to the mid-sized enterprise market, and then
we'll go to large, " "Well, you know, we're going to start with simple authentication, and then we'll integrate with IDP." You have to go straight to the end goal, because you have to be more ambitious. You have to take on bigger challenges. Technology today allows that. We're extremely ambitious now. I would have taken a few bolder steps four months ago. I think we can stop there, which I think is a pretty good ending. Thank you very much for your time. I really appreciate that. Thank you. I appreciate that
