Your AI Agent Is Not the Risk. Its Authority Is.
Autonomous agents are already making operational decisions, and most governance programs are still pointed at the model. Yogita Parulekar argues the real exposure is delegated authority: what an agent is permitted to do, under whose identity, with which credentials, and who is accountable when it acts. She explains why identity and permissions belong at the center of agent governance, and what secure-by-design architecture looks like for enterprises deploying agents at scale.
Key takeaways
• Agents inherit the probabilistic nature of the LLMs they run on, so oversight has to scale with context rather than apply uniformly
• Accountability cannot be delegated to an AI. It stays with the person or company the agent acts for
• Human-in-the-loop oversight fails when reviewers lack authority, time, or expertise. One report found reviewers given 1.2 seconds to approve an output
• Agent identity and permissions are the control surface, not the model
• The blast radius sits at the agent level, so containment has to be architectural rather than retrofitted
• Boards should work a four-part loop: goals, strategy, risks, oversight
About Yogita Parulekar
Yogita Parulekar is the founder and CEO of Invi Grid, a patented platform for secure-by-design cloud and AI infrastructure. She has built security and governance programs for nearly three decades, including as one of the first five people in EY India’s cybersecurity practice and as Oracle’s first technology auditor. She helps enterprises deploy AI with built-in governance, security, and compliance from day zero. She was recently named to the Silicon Valley Business Journal’s Power 100 and advises private company boards on AI governance through the Private Directors Association.
Yogita joined us previously to discuss AI governance fundamentals — start there if you are new to the topic.
In this episode
| 00:00 | Welcome and guest intro |
| 01:47 | Why govern agents |
| 02:19 | What makes agents different |
| 06:03 | Context and risk tolerance |
| 08:51 | Guardrails and policy controls |
| 09:56 | Human-in-the-loop reality |
| 10:56 | Accountability and risk layers |
| 23:09 | Agent identity governance |
| 25:53 | Designing blast radius |
| 29:57 | Board-level governance model |
| 35:27 | Two starting points for production |
| 39:03 | Resources and leadership takeaways |
| 42:58 | Final message and wrap-up |
In Yogita’s Words
“Agents are inheriting the probabilistic nature of the LLMs.”
“Accountability cannot be transferred to AI. It is on whose behalf AI is acting is finally responsible for the action.”
“Whether you are giving the agent the authority to change infrastructure or in healthcare settings to suggest a diagnosis — these are all very different.”
“If you haven’t used AI, use it. Your expertise and your wisdom doesn’t go away because of AI. It actually increases the need for your expertise.”
Resources
• Yogita Parulekar on LinkedIn
• Invi Grid — articles on secure-by-design cloud and AI infrastructure
• MIT AI Risk Navigator — tracks AI-related attacks and incidents
• AI GovOps Foundation — co-hosted the executive roundtable this episode builds on
• Private Directors Association
Cases discussed
• Moffatt v. Air Canada (2024) — the BC Civil Resolution Tribunal held Air Canada liable for misinformation given by its chatbot
• Replit AI agent database deletion (July 2025) — an agent deleted a production database and its backup during a code freeze
Related AI Realized episodes and events
Yogita Parulekar on AI governance fundamentals: Yogita's earlier conversation on the fundamentals of AI governance. Start there if you are new to the topic.
AI Governance as Code: From PDF Policies to Pipelines: Ken Johnston and Bob Rapp on making governance executable inside the deployment pipeline.
Governing Agents at Scale roundtable readout: The executive roundtable on governing agents at scale.
Frequently Asked Questions
-
Yogita Parulekar defines it as controlling the space between the AI model and the actions an agent takes on your behalf. Because agents inherit the probabilistic nature of the LLMs they run on, the level of oversight should vary by context: creative tasks need little control, while high-stakes domains such as healthcare or infrastructure require strict guardrails.
-
Accountability rests with the human or company on whose behalf the agent acts. As Parulekar puts it, accountability cannot be transferred to AI. The 2024 Moffatt v. Air Canada ruling established that a company bears liability for misinformation its chatbot provides to a customer.
-
Oversight fails when reviewers lack real authority, sufficient time, or the necessary expertise. Parulekar cites one report in which reviewers were given 1.2 seconds to approve an output. Effective oversight means matching the level of human involvement to the actual risk if the AI fails, defining who holds kill-switch authority, and giving reviewers enough time and expertise to exercise judgment.
-
Parulekar offers a four-part framework: establish goals for the AI deployment, define the strategy to achieve them, identify risks across people, process, technology, data and reputation, and implement oversight to confirm those risks are mitigated. The business defines the goals; technology determines how they are implemented.
-
Parulekar notes that non-human identities are nothing new, since software services have always run under their own identities, and over-permissioning them is a forever problem. What changes with agents is predictability: deterministic software behaves the same way the first time and the millionth time, so you know exactly how it will use its credentials, whereas an agent can produce a different output each time. The practical risk is that agents inherit human access tokens without the scoping and rotation discipline applied to human accounts.
-
At the agent level, not the model level. Agents reach tools, memory, and infrastructure, so containment has to be built into the architecture from the start rather than retrofitted. Parulekar’s secure-by-design approach means deciding up front what the agent’s goal is, which actions it may perform, what access and tools it receives, and what data it can reach, then embedding those controls continuously through development and deployment.
-
Asked for a three-item starter list, Parulekar offered two. First, modernize the deployment and operating process itself: development has become fast because coding agents build agents, so deployment and operation at scale is where the bottleneck sits, and that process needs to be hyper-automated. Second, embed controls frictionlessly from day zero to day Z, so they apply automatically at machine speed rather than through manual gates that cannot keep up.
-
[00:00] Christina Ellwood: Welcome to AI Realized, the podcast for enterprise executives leading AI adoption. From tackling security data and operational challenges to navigating organizational transformation, AI deployment offers a unique opportunity to redesign our organizations from the inside out. I'm Christina Ellwood, your host for today's episode. We're talking today with Yogita Parulekar, the founder and CEO of Invi Grid. Yogita is back on AI Realized. She joined us previously to talk about AI governance fundamentals, and since then, the conversation's moved from what to govern AI to how to govern agents operating autonomously and at enterprise scale. Yogita recently participated in the AI Realized executive roundtable on governing agents at scale, which was co-hosted with AI GovOps Foundation. And today, we're going deeper into what she and her peers are seeing on the ground. Yogita, welcome back to AI Realized.
[00:50] Yogita Parulekar: Thank you. Thank you, Christina. It's always lovely to be here and talking to you.
[00:54] Christina Ellwood: Yes, it's always nice to have you, and you have been building security and governance programs from scratch for nearly three decades. Starting as one of the first five people to build EY India's cybersecurity practice, then as Oracle's first technology auditor. And in those roles you were deeply involved in the first GRC products before anyone even ter- coined the term. Today, as the CEO and founder of Invi Grid, your patented platform for secure-by-design cloud infrastructure, you are talking consistently with executives in the space about how to manage and govern their infrastructure and their deployed systems properly and responsibly. You were recently named the Silicon Valley Business Journal's Power 100, and you also work pri- with private company boards through Private Directors Association on AI governance and cybersecurity. We'll talk a little bit about that later in the show. But with that as background I just wanna highlight that at the roundtable, there was a big reframe in terms of the f- the observation that we need to stop governing the model, the AI model, and start governing the delegated authority of the agents. If you will, the space between the model and the action. And from your experience building governance at, all the way back at your O- Oracle days but also now at Invi Grid, what does governing delegated authority actually look like in practice?
[02:19] Yogita Parulekar: So let's, even before we jump into whether we govern the model or govern the agent let's understand the lay of the land, right? We have-- So where did we start? We started off with machine learning, neural networks, AI, then it became GenAI, which were trained on our huge corpus of human historical records and data and la- and became large language model with transformers and attention and all of that. We started using those GenAI models, which are primary language-oriented, and to perform actions on our behalf, to take decisions on our behalf. So those are our agents. So on our behalf, so they get our agency. They act on our behalf. They do what we tell it to do. But they are primarily understanding our instructions using the LLMs, the using the language models, and those language models are highly probabilistic, right? So agents are inheriting the probabilistic nature of the LLMs. In that process, we are trying to make the agents work and output more and more deterministic, concrete, and responsible and safe because we are using it to make decisions on our behalf, using it to take specific actions which can have repercussions and consequences For us as a human and us for the company.
[03:57] Christina Ellwood: One thing that I just wanna, before you move on, make sure that we highlight here is that agents are also talking to agents and are acting- Yes ... and are making changes to themselves and sometimes to other agents based on the context they're operating in. So that is not operating on our instructions, that's operating beyond our instructions.
[04:17] Yogita Parulekar: Totally agree. Exactly. I was... That, so the simple way to think about or how you define an agent is and you can have an orchestration agent and a multitude of agents working with other agents, with other MCP servers, with APIs, with tools that you give it ac- access to and what, or everything that you are connecting agents to, which could be other agents as well, which can result into a variety of cascading effects through the whole thing. So you're absolutely right. But fino- but fundamentally, those agents, they are... And the difference between a piece of agent, which is also software and instructions, and the, between our other traditional software is that it uses LLMs in the background. LLMs to understand human intent, whether that intent was written in advance as a form of instructions for the agent that, "Hey, you are a customer service agent, so this is how you will behave. You are a marketing agent, so this is what you will do." So whether it is those instructions and guardrails we give the agent in advance or the oversight and observability and evaluations we put in a- over time, across throughout its agent's lifespan and journey it is still fundamentally using, we cannot forget that, it is using LLMs to understand whether it is those intent, that instructions or anything, so which is what makes, That agency that we give it very fundamentally different from having a software operate on our behalf and on our instructions.
[05:57] Christina Ellwood: So with that, how do you recommend governing that delegated authority?
[06:03] Yogita Parulekar: That comes down to, again, how good your instructions are and the nature of it, right? So for example, in order to make our agents reliable and for us, because they're acting on our behalf, it all depends on the context in which the agents operate. If it's to generate, "Hey, give me pretty pictures, infographics," for something that I'm writing or, "Hey suggest a blog article," or, "Hey, modify this article that I have written," these are all very creative plays. It can give you a variety of options. You don't need a whole lot of oversight. But if you are giving the agent the authority to, whether it is to change your infrastructure or in healthcare settings to suggest a diagnosis for a patient or life and death situations like that. So I'll give you a recent example. There is a case of a nurse who caught the agent. A agent recommended to give fluids to a dialysis patient.
[07:09] Christina Ellwood: Oops.
[07:10] Yogita Parulekar: Exactly. Oops, right? So can you have a fully autonomous agent in in life and death situations? No, probably not. So because we are finally... agents are, because they work on LLMs, they're, they are, they work, they are probabilistic in nature. You can now, to make them more reliable, to make them more deterministic, you have a variety of different ways. Obviously, one, the model itself is, models themselves are improving dramatically over time to make them better and more reliable et cetera. You can use small language models context-specific language models instead of the frontier models, the large language models. You can do context engineering, prompt engineering, fine-tuning, RAG, database, specific APIs, specific area agency only, small multiple sub-agents taking care of each every aspect, checking its own work, double-checking. So you can do a whole lot of that engineering, agent engineering in the background in order to make it as reliable as you get. But where, what is your comfort level? What is your risk tolerance for the agent to be not reliable depends on the context in which the agent is used. In a life and death, life sciences, healthcare situation, you will probably not want it to be autonomous at all. You will want a doctor and a nurse to take those final decisions for you on your life.
[08:51] Christina Ellwood: So the idea of policy as code was discussed at some length, and the idea of using a knowledge graph, or excuse me, not a knowledge graph, of using a graph as a source of authority for the agent. The agent can only do whatever is in the graph database was another suggestion. There was some other specific cases of here are things you can do between the model and the agent, inside the agent, and as oversight to the agent. Do you have experience in those that you those three areas that you can share a- approaches that people can use to govern at those three layers?
[09:30] Yogita Parulekar: Yeah, those are the examples I had offered up between the model and the agent, and these are all your guardrails, right? And the point I'm trying to make is you can put all of those guardrails in place But yet not have a fully 100% reliable system with agents.
[09:50] Christina Ellwood: Yeah. And in your case the example you gave of the healthcare, for example, a human in the loop is essential. And human in the loop was also discussed at some length in how to make human in the loop effective, because obviously there's a lot of ways in which human in the loop oversight can fail. And so there was some discussion about that as well. And that might be worth spending a few minutes on too. So there's the issue, the human in the loop issue of the human not having actual authority to be able to stop what the agent is doing or stop the agent, period. There's the problem of review fatigue, of it being difficult for a human to evaluate the outputs. There's also ba- basically in- the inexperience too. As we get further and further away from doing the work ourselves, we have less and less intuitive understanding of whether something is correct or not correct when we see the output from the models. So do you have any thoughts on how to use the human in the loop to be more effective and overcome some of these inherent limitations?
[10:56] Yogita Parulekar: Let's step back a little bit. You cannot replace human expertise, human wisdom, and you cannot replace the fact that the human will feel... AIs doesn't feel consequences of their action. The accountability of your action still remains with the human or the corporate, which is also a legal entity, right? As if you consider what entity is finally responsible for the actions that the agent takes, the the entity that it is, it lies somewhere on the spectrum, depending on the situation, the human itself whose agent it is, the corporate entity whose agent it is, right? It lies in, in the the, in, in that spectrum. Accountability cannot be transferred to a, to AI. It is on whose behalf AI is acting is finally responsible for the action. So where, how, what kind of human in the loop you need is something that you have to decide and w- what expertise level of human you need, whether the, it is in the loop, on the loop, inside the agent itself in terms of instructions in terms of what you tell the agent, how you make it better and more deterministic. All the guardrails that I talked about earlier, whether it is in the model l- layer, whether it is fine-tuning them or pre-training, fine-tuning, what kind of model you choose to the instructions you give to the agent, to the datasets you give to the agent, to the tools you give to the agent, the APIs, ev- the context engineering, the prompt engineering, the harness engineering, everything that you do which will make it more and more deterministic. And again, the context in which it operates. Is it for creating images, blog articles, or is it life and death? The extent of work you do and the reliability, if you say the reliability meter you need and that will determine the effort you put in to make that agent itself as much reliable as possible, right? So it's the the... So what particular technical action you take depends completely on the context in which your, you will use your agent. What layer of human in the loop you will add. Is it pre-approved auto-healing? Hey, I'll give an example. When it comes to deleting a database, there was a a recent case again, an agent was able to delete- The entire database and the backup database, production database and the backup database in 90 seconds flat or nine seconds flat or something. I don't have the number right. But before the human could do anything. That was an excessive agency problem. Ex- the full autonomous agent where it was just completely able to delete a production database. So where do you put that kill switch, right? Where do you put that, "Okay, these are the actions you cannot do, period." Okay? You cannot delete a database. You cannot delete its backup database. What is it that you absolutely cannot do? Now, I was I gave you healthcare example autonomous agent for just corporate production infrastructure example. Now let's take another example whether it comes to weapons using AI in that, right? Where is, Let's take that, the human societal level decisions that we have to make. All of that, so that's why the context is very important. And it's an int- it's going to be a very rock solid interplay of what are you going to use that agent for? What is the reliably me- reliability meter you need, which will decide on all the technical controls that you will put in place, and what additional human oversight you are going to need, and at what point in time? Before, during, after, or specific actions, after specific actions? What is it? So it is very contextual,
[15:09] Christina Ellwood: So wherever you put the human oversight- ... wherever you choose to put it, because obviously it's always needed but exactly where, as you said, is one of the decisions you have to take. How do you make that oversight real instead of performative?
[15:26] Yogita Parulekar: Define performative for me.
[15:30] Christina Ellwood: Think of it as the how do you overcome the human part of the human in the loop? The I've re- I'm reviewing lots of things, and it's easier for me to say, "Yeah, this looks okay, it looks okay," than it is to stop and figure out, is something wrong here? Especially there are so many layers of this issue of being performative. One is just not being rigorous. Another is actually not having the expertise necessary to actually judge it. A third is not having sufficient time. Some of these people were given 1.2 seconds in one of the reports to review and approve an output. That's just too s- short for any human to be able to do justice to it. There are a lot of elements. I'm not gonna ... I don't, I can't list them all, but what I can say is they're all tied back to humanity, to humans being human. So if you wanna make sure humans can perform their job correctly and consistently and correctly and how do you make that oversight real and effective?
[16:27] Yogita Parulekar: Okay. To make the oversight real and effective, again let's look at what risks AI possesses. Every corporate and everybody should be looking at what is the risk if this AI fails? And then you decide what level of oversight you need, what level of expertise you need, and what level of what time you give that expert, right? You can't give them 1.2 seconds and-
[16:55] Christina Ellwood: Clearly. Clearly. And by the way, this came out too about this issue of you gotta know what the catastrophe looks like. Exactly. If you're gonna r- limit the blast radius, you gotta know what the a bad outcome looks like. That... Th- those are two o- more obvious things but the real issue I think that we need to press on is how do you make it possible, how do you create a situation in which the humans can be effective in their role, and how do you make sure they have the right authority to be able to stop it? That's two things. That's, of course the delegated authority, but it's also the technical ability to stop the, what, what's going on, particularly in a situation where you're using a system of agents and not just a single agent. The more these systems are built, we don't know the consequences necessarily of stopping something when it's in flow. So we have more hesitation as a human to, to take drastic action like stopping something when we don't know what the fallout is gonna be. These are just humans being people, right? That they're trying to do the right thing, but they don't necessarily do it, and they don't necessarily know whether what they're doing is the right thing, and they are f- afraid or hesitant to take action. So how do you create a context? I hate to use the same term on both sides of this equation. There's context for the agent, but there's context for the human. How do you create an environment in which the human is able to be effective in their role in the human-in-the-loop situation? The, when they're in that role.
[18:27] Yogita Parulekar: Let's start. I think we need to step back a little bit, right? And we understand... Let's understand the risks of implementing or deploying that AI, and how do you govern the the AI, whether models to agents, everything, right? The, correctly. The risks is- If the AI agents you are building have risks at any of these three layers, at the top layer is the risks to society, right? The risk for them, it's risk to humans, right? We, whether it's our j- our jobs or whatever, and then it's the corporate risks. The corporate risk can be your risk to your reputation. It could be financial loss. It could be operational risk. So depending on what you're tackling, your answer will be different, right? The level of risk that you are engaging when you use a agent, what is the goal of that agent, correct? And what is the risk to achieving that goal, and what is the oversight you need? They all have to work together, and that needs to happen before you start your AI program. Your when you start your AI program, you need to understand what this AI is going to do for me, correct? And what its impact is going to be at the societal level, at the human level, and at the corporate level. And what its positive impact and what its risk are. And based on that, you can ... You have to decide what authority the human needs, right? Should this human be given a kill switch authority? How much time it should be given, and what is the expertise level? Now, let me give you that, another, the same example, very simple example. I can ask AI to give me the, ... And in fact, this was a stra- this was a, this is a very funny example. It's an H- HBR study, a Harvard Business review study. And they, a recent study, they basically asked AI to give y- give strategic advice Okay? And all they got in return was Trent's law. To understand that it is Trent's law- you have to have the expertise required.
[20:45] Christina Ellwood: That's right.
[20:45] Yogita Parulekar: So the nurse taking th- who caught that this cannot work, because if I give fluids to a dialysis patient, it will be life-threatening to this patient, or whether it is the person using that advice from AI on strategy for his company, if he is not well-versed and doesn't have the wisdom, then you are not going to you are not, y- you are putting your company and yourself or the human society at risk. So y- depending on what you're using that AI for, that expertise it doesn't take away the expertise, it doesn't... Because primarily it doesn't take away the consequences. The accountability still rests with us. However much autonomous you make that agent. And if the account- so long as you understand that the accountability, and there are court precedents now which state that the accountability rests with the human and the corporate, right? The company Air Canada, the ticket, it had to give it for the dollar, right? The accountability rests with the company. If it rests with the company, then you have to provide the necessary expertise, authority, time, everything for the human. You have to know when the human is in charge, when the ca- system can make decisions, and a- and all of that will depend on what you're using that AI agent for.
[22:05] Christina Ellwood: But there's a set of assumptions in there, Yogita, that whoever the human is that's in the loop has the expertise, the time, the attention, and whatever to make the whatever decisions are necessary. When we deploy systems, especially for a long period of time, if we deploy a set of agents, for example, for an extended period of time, where the human that is... take that nurse. It's not always that nurse, it's other nurses. It's not always a nurse. It might be a different role in the hospital, right? So we do not necessarily have equal humans that are making that are in the role of the oversight. And so I think there needs to be some things built into the system that accounts for the fact that humans are fallible, are, get tired, are not equally knowledgeable, are not equally trained or experienced, and so forth. And their expertise is a cumulative effect of having done the work themselves. And so when we have agents doing the work, the longer we have agents doing the work, the fewer agent- or fewer humans we have who know what that is to do that work, right? So their level of expertise about what good looks like in doing the work is changing all the time. Now, on the issue of identity, where the, This was one of the areas that was identified as an under-built area of governance, is the identity of the agents, that agents are still inheriting a lot of their human access... they... sorry, a lot of their access from the humans that were doing the work previously. So they inherit human access tokens with none of the scoping or rotation discipline that we impose when we're... for humans on those same tokens. So when you're talking about agents operating with their own identities, which is a fundamentally different architecture than what we've used in the past in automating systems, walk us through how an enterprise should set up identity governance for an AI agent from the beginning.
[23:53] Yogita Parulekar: Actually, it's Even today, software service services use their own identities. So a non-human identity is not a new thing, right? So agent... whether it's agent or another piece of software, 'cause agent is also finally pieces of software. Yeah? So whether it's agent or other software, everything operates today with non-human identities. The non-human identity problem and giving it excessive pri- permissions than what that software needs is a forever problem. The poi- the difference here is, in our case, the agents are making decisions and acting on our behalf, and those agents are probabilistic in nature. Software, on the other hand, which is not i-interacting, the agentic software interacting with LLMs, on the other hand, are not probabilistic. They have specific options, and they will respond in the s- the software behaves in the same way the first time and the thousand time and a million time. It is reliable. That's the difference, right? An agent, on the other hand, can give you a different output at different times. That is the difference. It's the iden- the difference is it is the reliability because of the lar- the language module we use. It's-
[25:20] Christina Ellwood: also the identity, when you give identity credentials to a piece of s- software that's deterministic, you know exactly how it's gonna behave forever.
[25:29] Yogita Parulekar: Correct.
[25:29] Christina Ellwood: When you give it to an agent, it's much more like giving it to a person- Correct where a person can do different things depending on what the context is they're operating in.
[25:37] Yogita Parulekar: Exactly.
[25:38] Christina Ellwood: So it is a different thing. It's not that it's brand new to give identity access, it's that the identity access we're giving them is more human identity access, not deterministic. And that's the real underlying reason for the question.
[25:51] Yogita Parulekar: You nailed it.
[25:53] Christina Ellwood: Are not it... the tools that we're using for the agents can access tools, they can access memory, they can access infrastructure, they can use different components in our systems. The blast radius exists because at the agent level, not at the model level. So the containment has to be part of the architecture from the start and not retrofitted later. How do you account for the a- architecting the blast radius?
[26:18] Yogita Parulekar: Architecting the blast radius. Okay.
[26:20] Christina Ellwood: It... Just think about it from a multi-cloud point of view. Yeah. When you're building your containment architecture in a multi-cloud environment, it's different than if you're doing it in a very simplistic environment.
[26:31] Yogita Parulekar: Correct. This is where what we have been talking about for a time now, and this is actually the premise of what we are building, right? Our security by design to reduce the blast radius. It is secure by design, governance by design, trust by design. You... This is also where you need stepping back and when you're architecting, when you're deciding what your agents will do, what actions it will perform, what is its goal, what a- what access you will provide it, right? What is what tools you will give it, what data it will access. All of that, architecting that, that has to be secure by design. So you need to start thinking about that way in the beginning when you decide on what agent you're building, and then follow through with it. So continuously embedding those controls through your entire process, the development process, the deployment process, right? Making sure that what you're, That is what is secure by design, and I have a lot of articles written on that, but that is exactly.
[27:44] Christina Ellwood: So- I understand the principles of secure by design, but in, in the actual deployment in a multi-cloud environment, what does that look like? What does that containment look like?
[27:59] Yogita Parulekar: There are different layers to it, right? The t- the t- tradition- the traditional layers don't go away just because it is agentic, but we have to add now agent the attack surface has increased, correct? With agentic. So the traditional lay- layers of identity, network, software, and basically infrastructure. So you have the software itself, the infrastructure it needs. So in case of agents, you it's going to be starting with the models, right? The s- then the a- the agent software, where that resides, it could be in a Kubernetes cluster, it could be in a serverless farm, it could be in on traditionally compute, or it could be in specialized managed services provided by cloud, like Bedrock or Vertex AI or any of that. The... Okay, so in the model, the agents, where they reside, which is your software code, the data it has access to and the tools and MCP servers, et cetera, that it has access to. Now, this entire infrastructure may sit in cloud, may sit externally in a different cloud environment. What governs it is, again, same layers, the identity layer, the network security layer that you provided, and when identity, it is identity, the permissions granted the connection... The network layer means the connections it can make the, to each other. So that doesn't go away, right? So you overlay that to the increased attack surface. The increased attack surface are all of these components that I talk- talked about, from model to agents software to data to tools MCP servers, all of these components and through all those layers, whether it's identity or network layers or the software layer itself.
[29:57] Christina Ellwood: Let's shift gears and talk about your work in i- in the Directors Association, the Private Directors Association. Governance obviously needs an organizational model and not just technology It's federated for speed, but with the unacceptable risks that are centralized, and every risk needs to be matched to an owner. What do you advise boards on AI a- agent governance? What's the operating model that you recommend?
[30:26] Yogita Parulekar: And this is where it's really funny, right? The governance word is thrown around and misused so badly. But let's understand what governance, actually is and what it means and how in the AI world how you translate that, right? For AI itself. And that is what boards are interested in. What are boards interested in? Boards are interested in making sure that the... they are the agents of the shareholders. Here's the classic agency, right? They are the investors and shareholders. They have to maximize shareholder value. The, that is the fiduciary responsibility of the board of directors. So that's a classic agency. Other agencies we know in the human world are power of attorneys one human gives to another human, right? So I look at even agency for AI agents as that I've given you the power of agen- agency power of attorney almost to act on my behalf, right? To do certain actions within certain parameters. So anyway, so let's come back to boards. Yeah. They are maximizing shareholder values. For them, it starts with strategy. Yeah. And that's the first is our corporate strategy going to help us achieve the corporate goals and corporate objectives for which the money, the shareholders have given us money? They've given us this money, whether it's revenue goals, product goals, it doesn't matter. So starting with those goals and objectives of the company and the strategy to achieve those goals and objectives. Then the next layer is the oversight layer. How am I mo- going to make sure that there is o- the oversight layer is to ensure that those goals are met, the strategy is executed well, so I have the right people, and I execute that strategy to achieve those goals, which means an understanding of even what risks will come into play so that the strategy may not get executed properly. That risk can be financial, operational strategic as well, legal, reputational, primarily. Into play. So now how does all of that translate into so strat- goals, strategy to achieve those goals, risks to those achieving those strategy, and oversight to make sure that we overcome the risks, mitigate the risks, transfer the risks, but yet achieve or implement the strategy to achieve the goals. Simple four four-point framework that I think about as governance. That's how they think, boards think. How do I translate that for AI? Let's start at the very beginning. What is the goal for w- while implementing AI? What are, what am I, what do I want to achieve? Which area? Is it marketing, operations, sales, finance, engineering, infrastructure? What are my agents going to do? What are, what is how am I going to use AI, right? And the, so that's what's your goal. Then your AI strategy, which follows that goal. How am I going to achieve all of this to achieve those goals? Then the next layer beyond that, again, so goals, strategy, risks to those goals. What are my risks? It could be people risk, could be process risk, it could be technology risk, it could be data risk. I don't have good data, right? The, my supply chain risk. What m- which model will I use? What am I... from that to what goes into my agent itself, what my agent interacts. So all of that falls in the all the risks, technology risks, right? Human risk. Do I have the right talent to make it possible? Are my people going to be anxious when I employ? Anxiety go about their jobs, right? The cultural aspect, all of that. So those are risks. And the reputational risks if something goes wrong. So based on those risks, I implement controls, I im- and then I have... And at the board level, I have oversight to make sure that my goals are achieved with the right strategy, the strategy is implemented, the risks are mitigated, proper controls are in place, and that's what your oversight will achieve. So that's my advice, my four-point advice to any board to think about it that way. Start with the right people and who understand from technology to how to think strategically, starting with the... And get the tech people and the business people together. But the business decides what the goal is with that AI. Tech decides how to do it.
[35:20] Christina Ellwood: So jumping from the board back to the execution layer, the operating layer. You've been building governance programs from scratch really your entire career. If you could hand an enterprise leader a three-item starter list for governing agents in production, what's on it and in what order?
[35:42] Yogita Parulekar: Governing agents in production. All right, let's see. Three-pointer list. Where would I have them start for operational? First things, agents operate at machine speed Okay? Developers, humans or other humans non-techies use that are also using agents to do their work, that is also happening at machine speed. In that context, if you start look how to op- how to govern those agents that are operating at machine speed and the humans now that are going to have to operate at machine speed because they're using the outputs given by these agents, so how do we, so think about it from, again, yes, those three layers. One is your governance model, if it is stuck today in the slow process. And again what I mean by that is today's way of deploying agents is actually the operational model today is very, is still slow, is still stuck in the old age, right? How do we deploy? Deploy is actually go- becoming more and more a bigger problem than developing the agent. Developing the agent is easier because you're using coding agents to develop agents. Developing is fast now. The deployment and operating at that scale is where the problem arises. So your question is superb, right? Because that is where the problem is. So one way is we need to modernize the process for doing that, the deployment and operation, right? That's number one. Smart process. Now, what does that smart process mean? Yeah? The process, that process itself needs to be hyper-automated. That process is not automated. So agents for agents, in a way. Automation, hyper-automation for doing that, which is what actually we are doing, Invi Grid is doing. Yeah? Second is embedding the controls, whether it is secure by design, right? That needs to happen frictionlessly. It's not happening frictionlessly today. And you, n-I, y-you have already talked about the examples I like to give, whether it's the Ring doorbell or the door that closes behind you. So yeah so I don't wanna reiterate those examples again. But that embedding the controls from day zero to day Z, is what we like to call it. So the controls themselves are automatically embedded. So hyperautomation or agents for agents, embedding those controls automatically at that pace, that's the only way you're gonna govern those agents which are operating at machine speed. Humans who can provide that oversight over this agentic layer as well. I really only I really only have two points for you instead of three. Those are the two points. You are going to need hyperautomation or agents to de- govern your agents with good oversight on it from from us, and you have to embed the controls right from the beginning, and that's also with oversight, right? Because that oversight decides what controls to embed when.
[39:00] Christina Ellwood: Great. Okay thank you. That was very helpful. So as we get close to our end of our time here together, let's talk about what resources you would recommend for our listeners who wanna learn more about you, about InvroGrid, and about managing agents in an au- in a, at scale, in a enterprise environment.
[39:21] Yogita Parulekar: I would urge people to actually go to our website. We have a lot of blogs and insight articles already. We and obviously please subscribe through the Contact Us form, and we keep sharing more or follow our LinkedIn page, and we keep sharing more blogs. And this is the hot topic. We're gonna see a lot coming from us. Other resources that I like to go to and fall back on when I'm learning are... is actually, MIT's Risk Navigator. I wanna give a shout-out to them and that team. They are also tracking all AI-related attacks or AI-based attacks or AI-used, attacks using AIU- AI. So just to keep tab on what is happening, I love that as a resource. What other resources do I use? Oh, gosh that I can point out to? AI, how about AI Realized?
[40:26] Christina Ellwood: Thank you. Yes, I think that's, I think that's right. It is a really good resource for enterprise executives who are adopting AI, deploying and managing AI. So in the, this AI era, you've been a manager, a leader a thought leader as well as a a corporate leader for a long time. It's a different time period to be a leader. In this AI era, what leadership skill do you find most valuable in your work today?
[40:55] Yogita Parulekar: If you haven't used AI, use it. Okay? And when you do, you will realize its strengths as well as its weaknesses. You will know exactly how the, how to govern people who are gonna be using AI. So get yourself knowledgeable in this area. It is highly important. But your expertise and your wisdom doesn't go away because ... And that's an important thing for you to remember. Because what AI throws out at you, the confirmation bias, and there are studies and studies on that, how AI comes up with confirmation bias. It will say what you want to hear 99% of the time unless you ask it no. Give me a counterpoint. Give me a counter-opinion." Then it will give you a counter-opinion. There is this case about someone thinking that he just discovered a new mathematical equation because AI said, "Yes, this is absolutely new," only to realize that it was all wrong. That confirmation. So you will also realize the weaknesses of AI and what, that your expertise, your wisdom doesn't go away with AI. It actually increases the need for your expertise, who can cut through any trends law, any confirmation bias that AI will throw at you. So that doesn't go away, and that itself is an immense amount. Of course, models will get better. We will get better at doing harness engineering with AI, and it will keep getting better and better. But finally, the other last thing to remember is the consequences of AI's actions are still with us at a corporate level and at the human and global level. So responsible use of AI is gonna be something that is going to define us as humanity and what legacy we leave behind for our children.
[42:56] Christina Ellwood: I think the Pope would agree with you. If our listeners remember just one thing from today's conversation, Yogita, what should it be and why?
[43:05] Yogita Parulekar: I think it's the last two things that I just mentioned.
[43:07] Christina Ellwood: Perfect. Perfect. Yogita Parulekar, founder and CEO of Invi Grid, thank you for sharing your experience with us today.
[43:19] Yogita Parulekar: It was lovely having this conversation with you