Securing AI Agents: Identity, Authorization, and the DPACT Framework

Transcript

Olimpiu Pop: Hello, everybody. I'm Olimpiu Pop, an InfoQ editor. And today we are discussing, well, probably not surprising, about AI and agents and the way how they act in our name or they should act in our name. And we are having that conversation with Sahil Agarwal. I will not add too many accolades on his shoulder because he can do it on his own.

Sahil Agarwal: Thank you so much, Olimpiu, for having me here. My name is Sahil Agarwal and I am an area engineering leader at the leading cloud collaboration and content platform company where I'm leading the identity and authorization stack of the company. And basically what we're trying to build is also very closely related to how do you separate human identities from agents? And I think, through this conversation, we can unwrap a lot about what agent identity means, what are the pitfalls of it, and how should we think about it if you are somebody who is building agents for either your own fund or for your enterprise?

Olimpiu Pop: Based on our initial conversation, we touched a bit on how the things are working. I think probably towards the beginning of the year when people are saying things like, "AI will not replace you, but people that are using AI will do." Now, most of the people that were very keen coders are just discussing about what are you doing when you're remaining without tokens on Claude. And then it seems that the perspective moved from the point where we are discussing about having pricing per user or per seat on software as a surface tool, because in the end, most of the tools that we're currently using as AI or agents are in the cloud. There are not that many companies that are actually having a server under the desk. And that's where our conversation started.

The Shift to Agentic Systems Problem: Identity, Accountability, and Trust [02:30]

How does the landscape look like at this particular point of time? And what's the problem that we are creating? I started with the part with the token, but it's strangely connected to what you see as a problem. Can you frame the problem that you identified?

Sahil Agarwal: My take is that we are shifting the value from this purely raw coder skills that's been the most important thing in the software industry and a software builder to who wields agents and how. So the shift is from, can you write a good line of code to can you work with agentic systems very well, cloud hostess agents. Basically, all the metered and tokens per user concentration is a topic, token maxing is a thing, but primarily, the shift is evolving from can you write good code individually to, can you be that software orchestrator where you have agents accompanying you to help you build that? So that's the thing. But one of the real problem where I see it as a real problem is a position where teams race to capability and pretty much forget that identity, accountability and trust are the risky bits of it.

So my instinct is always to design delegation first, have the right scopes and grants and policies in place so that before we are wielding the agents, before we are thinking to do anything with the agents and before we know what the power of the agent is, we know how to use it appropriately. We know how to use it responsibly and we know how to build it responsibly.

Olimpiu Pop: So what you're saying is that before we give knives to the kids to run around with them, we just have to make sure that the kids actually know how to use it and be in the safe environment so that they cannot injure themselves or others. So can we look into that? Because in the end, it's already three, four years since the ChatGPT moment, the epoch of the new way of writing code or just getting started. And for a long period of time, AI was a plain chat window in a browser. Now things evolved and then we hear other stuff as well. So probably it's a paradigm shift in the terms of search.

So for, I don't know, 20 years already, we were used to Google search or whatever search engines that we had out there. The shift to chat bots is the shift from searching to finding. And that's my exact point because you just look into that and you ask for something and that's the chat window. But now we are discussing about agents that have some capabilities that are running twenty four seven or at a given moment of time and they're doing tasks that we can do it. The scary part is even on the personal level, when you have access to credit card data, private data, they know pretty much everything about us. And then it's about the point that you mentioned. It's about its authorization. It's about its access and each agency, how does it do it? It's about how these things are happening operationally.

So how do you see it? How do you split it from your perspective?

Sahil Agarwal: That's a good question and a point. My quick creed is that AI definitely started as a browser chat window, a very informational, low effect, low barrier to entry. But as humans and builders, we started getting creative and started building wrappers around those LLMs and started calling it agents and then the agent ecosystem evolved. But as agents moved into operations, they've started gaining real world effects without corresponding identity and authorization. So as you mentioned, these agents can have access to sensitive information. How are they going to use it? What actions are they going to take with the data that they have? And how do they practically treat the principles is an important distinction that we have to create. We're no longer just having a Q&A with a chat interface that just gives us answer. We are moving to what we call as a delegated autonomous actor territory.

In fact, I should correct myself and say we are already in that autonomous delegated actor territory where agents are these first class citizens trying to not just act autonomously, but also act as humans or on behalf of humans. And that's where the clear distinction and guardrail needs to happen. How do you ensure that you're giving the right set of permissions and access to the agent while not putting those agents into two buckets? One is a very over-privileged agent, which is dangerous and pretty much can do anything that you ask it to do, an over-restricted agent, which pretty much means these agents are worthless. You're just asking for questions and permissions and nagging the humans over and over again.

So as the ecosystem of agents are evolving, it is really, really important to understand that we are in a shift or we have already achieved the shift from searching to finding, and that is where the exact risk surfaces. If you do not control or provide the right guardrails, you might as well be in a position where you're betting the company to achieve the level of autonomy you would want to achieve with agents.

Olimpiu Pop: So we have to be careful, in terms of company, how we provide the access to all the sensitive information. We know that on top of all the data leakage, there is legislation in place. I'm talking from Europe. GDPR is known for the sensitivity of data and not only for its pop-ups. So we have to see how we can address those points. But back in the day, we used to have these racing matrixes in the companies to just share the information. And my feeling now is it would be, well, a vintage tool probably, but it'll be quite useful to understand exactly how the tools are acting on our behalf.

What's the difference on when an agent is working on behalf of somebody or when the user is actually doing that? There should be a difference between these points.

Sahil Agarwal: That is a great point. The core principle, and one of the theories that I'm working on in a framework that I'm building on highlights this very neatly with guided steps, but one of the core principles is that agents should always act on behalf of a human user and should never ever impersonate a user.

For example, if I'm building an army of agents that's working in production or working in an environment, it should always be a delegated autonomous actor. It should not act as Sahil anywhere in the system, anywhere in the world, because that is the dangers of things. And we've seen some real world case studies and examples of real world products where this has happened and has created a security nightmare. Eventually, those were all evolved and fixed and we famously know the tool as OpenClaw today, but the first rendition of OpenClaw is an amazing case study to understand what is delegation, why it matters, and why it should be the basis of everything we do from an agent perspective.

Policy time audits are something that follows later on, but the primary key is if you let agent just represent and act as you and not on behalf of you, that is a recipe for disaster because that's where a lot of the policy violation and security violation happens. And agent just gets a lot of information that it's not supposed to get and falls under the trap of overprivileged agents.

Olimpiu Pop: So let me see if I get that correctly. An agent should be more of a Jenkins, a bottler that works for you and says that I'm representing Sahil and I want to do that for him rather than just impersonating you and just trying to be a copycat that tries to be in your shoes, right?

Sahil Agarwal: Exactly. One of the good ways to think about this agent tech ecosystem and the security controls around it or the identity and trust controls around it is to take a step back into the pre-AI era. Back in the day, let's just call it life was simple from a software perspective, we had humans and we had apps and we had resources. So humans had access to a bunch of apps and those bunch of apps had access to a set of resources. And through some hierarchical decisions that, no, I am a member of team X and my manager who granted me access to app Y, I get access to a set of resources. Humans were always in the loop. The permissions were always controlled. The intent was always known.

And that fundamental theory breaks as soon as we introduce agents into the mix because they are not acting in terms of vet control human in a loop fashion. They're an autonomous delegated actor. They can think about situations and scenarios in the system. They can act autonomously. They can make decisions. They can chain and call other tools within the ecosystem and draw on all the information to make decisions further. And as the frontier models are improving, the autonomy and intent of the agent itself in the ecosystem is changing as well.

So with all of those being considered, the traditional identity model or the access model that were built and matured over the decades for humans are fundamentally getting challenged and the same thing cannot be applied one-to-one to any agent.

Olimpiu Pop: As you mentioned, you are working on a framework. So if I think about it, several of my previous companies, they had different standards. SOC 2 was one of them that was quite famous in terms of information security. There are several others in the ISO space. As you mentioned, one of the points that was quite important is who has access to what, who has the authority, and then an audit log that allows that. One of the points that if you look at other frameworks in terms of security or best practices, tells you that you have to assign responsibilities to clear persons and everybody should know what they should do. And if you look at Zero Trust, it says that, continuously, you have to ask and doubt who's doing what and so on and so forth. Even if you're inside of the company, that doesn't mean that you have to have access to everything and there are different layers of security.

I know that you are cooking something, so maybe let's start by seeing the vision that you have as a framework for this.

Acting on Behalf of vs. Impersonating [13:30]

Sahil Agarwal: What I'll say is that now my exploration into this space of trying to build a framework that works for different cohorts of professionals in the agentic space started when I personally started using LLMs and started building agents out of it and started noticing all the pitfalls around it, exploring and experimenting with all these famous GitHub repos that were out there claiming themselves to be self-serving agents. And I immediately noticed a pattern. The pattern was that every time I'm trying to build something, I'm accidentally or unintentionally giving too much access to the agent than it requires.

So I started noticing about all of these different patterns and these different patterns kind of fell into four or five categories or buckets. One is the delegation authority. The second thing is policy management, explainability of these agents and what actions they're taking, why and under what circumstances, what context are they operating under, and when does their authority end?

So when I started thinking about all of this and started applying and questioning each of the tool, agentic tool that I'm using, I came up with a scoring rubric and not a lot of them were trying to meet that, honestly, in the best terms. There were a few tools that started to meet that. And based on all the learnings, I created this framework called DPACT framework, D-P-A-C-T, and it stands for delegation, policy, auditability, context and time. And delegation in a nutshell means the agent should be, or we should be able to clearly say on whose behalf is this agent acting on? And policy is what is the policy? What is a restriction? What can it do? And most importantly, what can it not do? What can this agent absolutely not do?

Auditability or explainability is today, 30 days later, whenever, you should be able to take a look at the audit logs and say why an agent took an action. And if your customer is asking for why did the agent give 50% discount to 10 of my customers, you should be able to go back and take a look at those logs and say, this is the context and this is why the agent took those action. It also serves a multipurpose thing where the audit logs becomes the input to some sort of a feedback loop where you can take the learnings from the auditability and basically feed it back to the agent to retrain it and help it be better in terms of making decision.

And see context. What is this boundary that you're drawing for the agent to operate within? What can it absolutely not do and shouldn't be doing? Draft an email, but don't send it. That is the context. And time is when does authority end? I can grant my agent to go read a database table and just stop it at that, but that grants the agent perpetual authority to keep reading that database table forever. But instead, if I make it in a way that no, hey, you can go read this particular database table for one time or for one minute, that is time bound. And I'm adding explicit mechanisms, whether through TTLs, whether through task-based, I'm adding explicit guardrails to end the agent's authority.

And in combination of this becomes a framework that engineers can use to implement authentic guardrails. Product managers can use that to figure out product readiness and production push. Executives can look at that to make sure the agents and the ecosystem is safe and secure and it's not betting the company in order to move fast. So it's applicable to different cohorts and then anybody can use this who is in this space and building or trying to interact with agents today.

Olimpiu Pop: We are calling it the framework, but to just make sure that everybody's aware, currently, it's more or less a concept. You work on a concept, there is no tool associated with it for now. So it's more of a framework from the policy perspective and that's the way, a blueprint, that people can use in doing that, right?

Sahil Agarwal: That is absolutely correct. It's a blueprint. It's a positional framework that can be applied in several different ways. It does not go into tooling or implementation detail. One can apply the delegation model in several different ways, depending on your own situation, depending on your own tech stack. The policy engines can happen everywhere. This framework just tells you that these are the must haves in order to put the right set of guardrails to an agentic system.

Olimpiu Pop: Okay. Just putting the product hat on, how do you envision a potential implementation from the point of view how D-PACT would map to product decisions? Autonomy tiers, one would be the review moments. How would you like to see it? I don't know. We discussed... Maybe shopping. That's probably the easiest spot, where you have an agent that is scrolling. Do you have different tiers of costs? If it's up to $10, call me. If it's above that, just ask for permission and stuff like that. Or how would it translate from that point of view? Because if we think about it, as you mentioned earlier, you mentioned big numbers, like one million agents army. If you're bombarded by notification, then you'll stop reacting to them. If you're just having an audit, then you get into reactive mode and you're not able to do anything. So what's the sweet spot of granularity that you envision to make this effective?

Mapping DPACT to Product Decisions [19:23]

Sahil Agarwal: If I look at it from a product hat, and if I'm either trying to build a chatbot or a customer service agent, I think customer service agent is a great example, I think I'd map the decisions or I'd use this concept to map the decision based on the effects and the autonomy tiers. Now, it can be proposed only, read only, reversible actions, shortlived, escalated to a human if you need to make decision around certain things.

And to give you a concrete example, let's just assume that you have a customer service representative for an e-commerce company who's trying to serve the customer. A customer was double booked or double charged on their credit card for a purchase. Naturally, what you do today is you pick up the phone, you call the customer care line, and there's a human on the other end who will receive the call, get your order number, look up the context and say, "Okay, yes, you were double charged. So we'll refund the double charge for you, close the ticket life scare." But the real risk happens when the same human is now an AI agent, an autonomous delegated actor who is servicing the same problem.

I have the same double charge issue going on with an order. I call in, either I'm chatting, I'm calling in, there's an agent answering on the other end, agent recognizes and pulls up the ticket, sees the double charge, it gives the refund back, but the agent with improper guardrails can also pull up similar incident for 10 other customers and start issuing all of them refunds. And on top of it, email all of these customers saying, "I am sorry," or, "We are sorry, we messed up your order. We double charged you. Here is a 60% discount coupon for the next time you place an order."

So you see the difference of how a human was handling and how an agent with poor guardrails was handling the same situation. It was thinking it was making decision based on the data it had. Now, when you start applying the Deepak guardrails around it, you strictly mention things that it's not allowed to do. So when you establish the policy, the policy is that you can only read and summarize the situation and not make a decision of issuing a 50% discount coupon or a refund to the customer. That is where you escalate it to the human. That is where your authority ends. You can only look at the one ticket in context, this one particular customer. You cannot take the same pattern, apply it to the broader customer database and identify the same pattern and start issuing refunds or summarizing all of those issues without consent or without authority.

So Deepak allows you to put the right policies in place and right context in place so that the agent doesn't go rogue and it's bound by the task and bound by the time and not just acting over privilege and trying to do what we call is the best thing that the agent can do.

Olimpiu Pop: So to just put it simple, context and time, it's important for agents, right? And then that's something that we have to enforce and create the proper guardrails. And then we can start from this point and then just take them one by one.

We did mention, at least sporadically, that there were situations when things happened, but let's maybe make some kind of a short recap of what incidents happened. You choose the time horizon looking back, evolving agents that could have been avoided if something like Deepak would be applied to just create that... Again, context for our listeners and understand exactly, how these things can be applied.

Sahil Agarwal: Maybe take an example from a case study that I was recently trying to do. Without mentioning the company name itself, there was this famous company that utilized the power of AI for its hiring decisions and it was autosorting the candidates and trying to make some quote intelligent decisions around how the hiring process should go for this company. It was a nice and easy chat interface, semi-agentic where the applicants could interact with and it does some sort of an initial set of interviews before they're graduated to the next round of interviews and whatnot.

And all of a sudden their token builds and agentic info builds started to go haywire. They're just paying too much money to run those agentic system. It was getting out of control. And when the engineering team started to audit of why that's happening, the issues were nailed down to a few meme users of that particular feature. What they were essentially doing is some of the applicants were just literally, for fun, coming into the website asking this chat interface that is supposedly its only task is to do interview style vetting, they're prompt injecting into the chat interface to go write a Python code or a script, just for fun. And now the agent, since it does not have the right guardrails, is writing Python code. It's doing things that the end user is asking it to do.

That is a great example to say that the agent in this context is operating beyond its context, beyond its authority and beyond its policy. If there were the right set of policies defined, if there were the right set of context defined for this particular agent, the company wouldn't have suffered what it suffered and they did not have to shut down those agent capabilities for their hiring workflow. And when the engineering team investigated that deeply, they understood, okay, this is how the customers are using it. They're just having fun with the agent. They're just having fun breaking the agent.

Several similar incidents were noticed across many large companies. For example, there was a chat bot interface, agentic chatbot interface for ordering your food. Again, people are just asking the agentic bot to tell them a joke or write a Python script again as an output. That's just token maxing for that company. End users are going to use your interface the way they want to. It's completely your responsibility to define what the agent can do and most important to what it cannot do.

Olimpiu Pop: It's funny when you read them like anecdotes, but at the point when you are the one that is involved, the anecdotes are not that fun anymore. So how would you look at it from the perspective of implementing it? Because obviously a framework and the policy, it's a good target to have, but we know that you cannot do it at that particular point of time. So how can we think about of a timeline how teams can adopt agent governance in an incremental fashion so that they don't disrupt the status quo and then don't expose the team to maybe lack of knowledge so that everybody is on the same steps?

Incremental Adoption of Agent Governance [26:50]

Sahil Agarwal: That is a very important thing that I think everybody should be paying attention to because we are not very mature in terms of our whole agentic infrastructure as an industry. We are still learning. We are still figuring things out. And the first best thing that people could do today is to go back and find a path that is incremental. And when I say incremental, it's not just, oh, I have this agentic system that's running in production, but now what do I do? Could be missing things, but take a step back and do an inventory. Start with an inventory with understanding what agents do you have running in your ecosystem, which agents exist, what tools can they call, what credentials they use, and most importantly, what data can they access? Can you go back with that inventory and identify who owns them or what is the visibility levels that these agents have? And from then, start adding visibility to the agents that lack visibility, like agent ID, task ID, trace IDs, do the basic audit that you can for the agentic system that are currently live.

Once you can have achieved that second step, then separate the agent identity from human identity. You cannot just be passing the same human tokens to an agent or an API key and just YOLO your life into it and just say, "Okay, here is my token. Here's my API key. Just make it work in production." That is very dangerous. Agent can leak your token, and once your token or your API keys are leaked, it can lead to further disaster. It can lead to a lot more other stuff. So it's really, really important to separate your agentic identity from your human identity. And then you start getting tools and add review for the highest impact effects.

Going back to my chatbot customer representative example, when it's time to issue a refund, do not just issue a refund, pull human in the loop, escalate that to a human, ask for an accept or deny, and based on whatever the human responds, you respond back to the customer sort of a thing and then move forward towards continuous authorization. And continuous authorization is a key here because that is a mechanism that allows you to continuously authorize your agents and make a decision based on the policy at each step. If the scope is increasing, reevaluate. If it's getting into a dangerous directory, downgrade it or revoke the access, so on and so forth. You can create a super loop that is very much catered to your workflow and your company and that's how you start incrementally getting towards a more secure agentic situation.

And to avoid making the whole governance a giant upfront program, teams can experiment while gradually removing the highest risk factors. As I was saying, the bottled human tokens, the long lived keys, broad service accounts that are just hooked up or attached to an agentic service, lack of auditing, lack of revocation strategy and lack of task boundaries. So if you have all of those, if you can clearly audit that for every single agentic system that is running your production, you should be able to go back and start knocking one thing at a time incrementally. And in my experience, the first maturity step is not a perfect policy. It is knowing which agents can act and what authority they can currently have.

Olimpiu Pop: So like most of the enterprise corporate actions, we start with an inventory, understand exactly what we currently have in terms of agents. And more than that, it's important to understand on whose behalf these agents are working and start from there. And once we have that, we can just start putting the policies in place one by one to just ensure that the things are going in the right direction. We spoke hypothetically on this. So if you'll take your magic wand and just point products and vendors in the right direction, what would you like to have available for you as an engineering leader that wants to make his organization safe?

The Future of IAM Vendors and Agent Infrastructure [31:04]

Sahil Agarwal: I think if I'm looking at it from IAM vendors and ready-to-go agentic framework perspective, I would definitely like to see more exposure on the task and the identity of the agent itself, the capability to trace the tool calls, the review hooks and the policy integration points. You could have nice gateways that make the decision, but that gateway's decision should be driven by strong policy integration that these vendors should be able to support. An IAM provider should support first class, and first class is the key word here, agent on behalf of grants. That agent on behalf of grants are key here because that is basically taking a human identity or a token and attuning it further to give the second layer of tokens that is only applicable and valid for the context of the agent.

You cannot draw any conclusions on behalf of grants back to the user. You cannot reuse it to do anything malicious, but it is a short-lived piece of information that works in the context of the agents. And that short-lived authority combined with the revocation strategy and the principle and task intent is something that the IAM provider should just make it as a first class feature that's available out of the box.

I also think that the tool provider should validate grants and emit structured audit events because these structured audit events is what helps the builders and the consumers of the agent to understand the decision making that is happening under the hood. Now, if a week later somebody up the chain in your organization comes back and asks, "Why did the agent do what it did?" Or your customers are asking, "Why did the agent do what it did?" you should have enough evidence to go back and answer those questions. And without the proper audit channels, you cannot ever, ever do that. And you'll just be guessing and your answer could perhaps be, "Oh, it's AI and it just did it." And that is a bad answer. That is how you quickly lose trust of your customers and you quickly get into a position where you're betting your company or your security.

So to close this out, the next platform perimeter should be delegated agent authority, not another place to just paste a long lived API key is what I would say.

Olimpiu Pop: So what I hear you saying is the software as a service landscape is changing. And the first ones that are changing are the big providers of agents and AI models and so on and so forth, because they moved from a pay per seat to pay per token, given that now we're discussing about 24/7 availability. And in this landscape, it's important to start having the identity model that mimics that. And that means that we'll move from just having access and authorization and authentication to a place where we delegate or probably impersonate. Somebody can impersonate us on some point and not use only tokens. So probably we'll have tokens that we are using, but then it's about having delegation, some kind of tokens that we can use from that point on. Is that more or less the perspective?

Sahil Agarwal: That is more or less the perspective. And I think to summarize this in a nutshell, I would say that the ecosystem collectively needs to move from saying give the agent a key to issue the agent a bounded task grant. So if we get to a situation where we say you can issue the agent a bounded task grant, that automatically covers every single thing underneath us, policy, context, time, yada, yada, yada, yada. But right now, I think we are somewhere in between issuing the agent a key and issuing the agent a semi-bounded task grant. And eventually, the way I see industry will be headed or should be headed already, and this applies mostly for the legacy system that we're built for humans, they are the companies that'll have the most challenging piece to go modify their infrastructure, is to completely move to a situation where the tasks of the agents are completely bounded and granted.

Olimpiu Pop: Great. Is there something that I should've asked you but I failed to? A topic that we should have covered, but we didn't?

Sahil Agarwal: Yes, absolutely. Everybody who's building, using the agents and thinking about agent system should think about as a real world scenario. Most of us have had a situation in our life where we have seen, for example, a babysitter or a nanny for our kids or a friend's kids or whatever. And we have applied strict guardrails and policies when we hire a caretaker for our kids, where we hire them for a time period, they're only allowed to buy pizza or food worth $10 or whatever. The bedtime is 8:00 PM and the caretaker's authority ends as soon as we are back from dinner at 11:00 PM or whatever. And we do not grant the caretaker our bank accounts or Social Security numbers or credit card details and all of that stuff and even house keys for them to come back again tomorrow.

So if we are doing all of those things very, very naturally in a very important aspect of our day-to-day life, why are we handing over full authority to our agents when we are building that for the industry, for the tasks that we are doing?

So the preliminary thing is a lot of the things that we are talking about today is not a net new thing. It's already known. We apply that naturally in our day-to-day life. It's just extrapolating that into a technical terms and applying that to our agent system today. And that is going to be my number one guidance that while people are focusing and will be focusing on the model quality and the prompt quality and everything, the number one failure mode today in the production systems is not just purely because of the model quality, it's also because of the lack of identity systems. And this was proven by some of the most recent frontier models like Claude Mythos, Fable 5 and all the other stuff where the agent system built on top of those frontier models can not only just operate in a system, they can figure out what they can do and break the system. And it's under your control and intentions on how do you provide the right guardrail so that any net new frontier model is not challenging your assumptions at the infrastructure level.

Olimpiu Pop: So what you're saying is that there are a couple of things. Even though we are discussing about AI and we're discussing about large language models, actually we are discussing about applications because each of them, ChatGPT, Claudes, you name it, all of them are actually models behind the scenes or a zoo of models. And those have a couple of layers, caches, so on and so forth, guardrails that are putting fences around what can happen. On top of that, we have to make sure that we are going in the right direction, also the identity systems. And we do have things that we actually apply in our day-to-day life also applying to models because that will be a whole ecosystem that is being built out there. Thank you for that.

So to just sum up all the pools that we had, we are moving in a space where we'll have more agentic robots working for us. At this particular point of time, I think we are discussing more about software rather than real robots because that's a whole different point. But what we need to make sure is that we have the proper tools to create the safe space, both for us and for the people that are interacting with these robots, to know that on the other side there is a robot. And we as a landscape, we need to take responsibility for everything that is working to just ensure that we create a strict difference between what's a human and what's a robot or a bot, agent, whatever, acting on our behalf.

I suppose this sums up what you had in mind, right?

Sahil Agarwal: It does. And the only thing that I'd say is the barrier or the line between a real human and an agent acting on behalf of human is going to get blurry and blurry. At some point, and we are kind of already there already today, it's hard to say who's responding from the other end, whether it's a human or an agent. So exercise caution, be paranoid and just make sure, at least when you're building, you have the right DPAC controls in your agentic system.

Olimpiu Pop: Thank you, Sahil. And on that point is probably the most mind-blowing thing that happened recently is I was playing around with Notebook LLM, just doing some research. And because I was driving, I said, "Okay, let's see what it means to just generate an audio overview." And it sounded just like us with a lot of uhums and a lot of ums, and it really felt real. So yeah, it's harder and harder to distinguish these borders.

Sahil Agarwal: Absolutely.

Olimpiu Pop: Keep safe out there, right?

Sahil Agarwal: Keep safe out there and be paranoid.

Olimpiu Pop: Thank you, Sahil.

Sahil Agarwal: Thank you so much, Olimpiu.

Mentioned:

• DPACT Research Paper
• Open Claw