# Agent Identity Governance: The DPACT Framework

**Podcast:** The InfoQ Podcast
**Published:** 2026-09-21

## Transcript

The decisions you're making right now about AI adoption, architecture trade-offs, and how your team works together will shape your systems for years.
Getting those calls right when the landscape is shifting this fast is hard.
QCon San Francisco has spent 20 years connecting senior engineers with practitioners who are a few steps ahead on the same problems.
This November 16th through the 20th, 60 plus speakers across 12 tracks will share what's actually working in production and what isn't.
No hidden product pitches, just senior practitioners helping senior practitioners.
Learn more at QConSF.com.
My name is Sahila Garval, 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.
Based on our initial conversation, we touched a bit on how the things are working.
I think probably it was the beginning of the year when people were saying things like, AI will not replace you, but people that are using AI will do.
Now, most of the people that are very keen coders are just discussing about what are you doing when you're remaining without tokens on cloud.
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 tools, 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.
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?
Yeah, my take is that we are shifting sort of the value from purely raw coder skills.
That's been kind of the most important thing in the software industry and a software builder.
to who wields agents and how, right?
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, and 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?
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.
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 a 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 chat GPT 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 20 years already, we were used to Google search or whatever.
search engines that we had out there, the shift to chatbots is the shift from searching to finding.
And that's my exact point because it's, 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 24 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?
That's a good question and a point.
And no, my quick read is that AI, Definitely started as a browser chat window, very informational, low effect, low barrier to entry.
But, you know, 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, like, you know, 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 is 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.
Like, you know, 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 overprivileged agent, which is dangerous and pretty much can do anything that you ask it to do.
And over-restricted agent, which pretty much means These agents are worthless.
They'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.
Okay, 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.
So GDPR is known for the sensibility 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 racy matrices in the companies to just share the information.
And my feeling now is it will be, well, a vintage school tool probably, but it will 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 this point.
Yeah, that is a great point.
So the core principle and one of the theories that I'm working on or 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 agentic 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 an agent just gets a lot of information that it's not supposed to get and falls under the trap of overprivileged agents.
So let me see if I get that correctly.
An agent should be more of a Jenkins, a butler 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?
Exactly.
And one of the good ways to kind of think about this agentic 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, right?
Back in the day, let's call it the 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 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 that controlled human in a little 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, make furthermore decisions.
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.
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.
Yeah.
So 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 authentic 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, right?
And I immediately noticed a pattern.
The pattern was that every time I'm trying to kind of 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, right?
One is the delegation authority.
The second thing is policy management, explainability of these agents and what actions they are 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.
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 the 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.
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 multi-purpose 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 with them?
What can it absolutely not do and shouldn't be doing?
Like, you know, draft an email, but don't send it.
That is the context.
And time is, when does the 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 the database, 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 anybody can use this who is in this space and building or trying to interact with agents today.
We are calling it the framework, but to just make sure that everybody's aware, currently it's more or less a concept.
You worked 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?
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.
Okay.
Just putting the product hat on.
How would you envision a potential implementation from the point of view, how Daypact would map to product decisions?
Autonomy tiers, what 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 part where you have an agent that is crawling.
Do you have like different tiers of cost?
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 1 million agents army.
If you're bombarded by notifications, 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?
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.
Right now, can we propose only, read only, reversible actions, short-lived?
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, like 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 four guardrails were handling the same situation.
It was thinking, it was making decision based on the data it had.
Now, when you start applying the DPAC 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 applied 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, right?
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 overprivileged and trying to do what we call is the best thing that the agent can do.
So to just put it simple, context and time, it's important for...
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 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, involving agents.
That could have been avoided if something like the Deep Act would be applied to just create that, again, context for our listeners and understand exactly how these things can be applied.
Maybe take an example from a case study that I was recently trying to do.
And without mentioning the company name itself, there was this famous company that utilized the power of AI for its hiring decisions.
And it was auto-sorting the candidates and trying to make some, quote, intelligent decisions around how the hiring process should go with 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 are graduated to the next round of interviews and whatnot.
And all of a sudden, they're...
token builds and agentic infrabills started to go haywire.
They're just like 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.
And 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, right?
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.
And several similar incidents were noticed across many large companies.
For example, there was a chatbot interface, a Gentic chatbot interface for ordering your food.
Again, people are just asking that agentic bot to tell them a joke or write a Python script again as an output.
That's just token maxim 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 importantly, what it cannot do.
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 funny anymore.
So how would you look at it from the perspective of implementing it?
Because obviously a framework and a 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 over timeline how teams can adopt agent governance in an incremental fashion so that they don't disrupt the status quo and they don't expose the team to maybe lack of knowledge so that everybody is on the same steps.
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.
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, 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 agent existent that are currently alive.
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 is my API key.
Just make it work in production.
That is very dangerous.
An 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 response, 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, re-evaluate.
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 borrowed 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, right?
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.
Okay.
So like most of the enterprise corporate actions, we start with the name Mandori.
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 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, 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?
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 know, you could have a nice gateway that makes 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.
Like, you know, that agent on behalf of grants are key here because that is basically taking a human identity or a token and attenuating it further to give this 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 and tenet is something that the IAIM 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 out of the hood.
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 were 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 vetting 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.
Okay.
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, LLN, so on and so forth, because they moved from pay per seat to pay per token, given that now we're discussing about 34-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?
That is more or less the perspective.
And I think to kind of summarize this in a nutshell, I would say that the ecosystem collectively needs to move from just saying, you know, 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, right?
Policy, context, time, yada, 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 were built for humans.
They are the companies that will have the most challenging piece to go modify their infrastructure.
This will completely move to a situation where the tasks of the agents are completely bounded and granted.
Great.
Is there something that I should have asked you, but I failed to?
A topic that we should have covered, but we didn't.
Yeah, absolutely.
Everybody who's building, using the agents and thinking about agentic systems should think about as a real world scenario, right?
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 p.m.
and the caretaker's authority ends as soon as we are back from dinner at 11 p.m.
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, right?
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 technical terms and applying that to our agentic system today.
And that is going to be by 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 agentic 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.
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, Clouds, 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 an bot, agent, whatever, acting on our behalf.
I suppose this sums up what you had in mind, right?
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, we'll...
kind of already there already today.
It's hard to say who is 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 D-back controls in your agentic system.
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 ahums and a lot of ums.
And it really felt real.
So yeah, it's harder and harder to distinguish these borders.
Absolutely.
Keep safe out there, right?
Keep safe out there and be paranoid.
Yeah.
Thank you, Sahil.
Thank you so much, Donfeet.