From Compliance Theater to GRC Infrastructure: Why AI Breaks Traditional GRC ft Jasmine Kaur, Principal of Security & Assurance Engineering @ CoreWeave

In this episode of Security & GRC Decoded, Raj Krishnamurthy sits down with Jasmine Kaur, Principal of Security & Assurance Engineering at CoreWeave, to explore how AI-native infrastructure is fundamentally reshaping GRC.

Drawing from her experience at companies like SAP, Google, and now an AI hyperscaler, Jasmine explains why traditional GRC models are failing in high-velocity, ephemeral environments—and what needs to replace them. From “GRC as infrastructure” to the rise of agentic GRC, this conversation dives into how compliance must evolve from a reactive audit function into a real-time assurance capability embedded directly into systems.

Key Takeaways:

• Traditional GRC models break in AI environments because systems are ephemeral and disappear before audits can validate them.
• Compliance should be treated as a byproduct of strong risk modeling and control design—not the end goal.
• GRC must evolve into an infrastructure-level capability that continuously emits assurance signals.
• Agentic GRC is the next evolution beyond automation and CCM, enabling decision-capable systems with human oversight.
• Future GRC teams must operate more like engineering and reliability functions rather than audit teams.

What You’ll Learn:

• Why AI infrastructure makes traditional audits ineffective
• What “GRC as infrastructure” actually means in practice
• How to move from point-in-time audits to continuous assurance
• The difference between automation, CCM, and agentic GRC
• How to position GRC as a proactive, business-critical function

This podcast is brought to you by ComplianceCow — the smarter way to manage compliance. Automate evidence collection, eliminate screenshots, and scale your program with confidence. Learn more: https://www.compliancecow.com

Watch more episodes: https://www.compliancecow.com/podcast

Connect With Our Guest:
Jasmine Kaur | Principal of Security & Assurance Engineering | CoreWeave
Connect on LinkedIn: https://www.linkedin.com/in/jask31/

Rate, review, and share if you enjoyed the show!

Subscribe to Security & GRC Decoded wherever you get your podcasts:

Spotify: https://open.spotify.com/show/5pigcMwOrYIA6d9OOOsxqr?si=416b82ab5c474683

Apple Podcasts: https://podcasts.apple.com/us/podcast/security-grc-decoded/id1795144450

Transcript

Raj Krishnamurthy (00:00.626)
Hey, hey, hey, welcome to another episode of Security and GRC Decoded. I'm your favorite host, Raj Krishnamurthy. And today we have, I would say, a fearful cybersecurity leader, Jasmine Kaur with us. Jasmine has 20 plus years in cybersecurity managing security operations teams, GRC. She has worked for some fantastic companies like SAP, Google, and now she's at CoreWeave.

Jasmine, why don't we start with what is CoreWeave? Tell us our audience about it and what you do there?

Jasmine Kaur (00:36.28)
Hi Raj, thank you for inviting me here. So CoreWeave is, as people know it, it's an AI cloud hyperscaler. Now what that means is we are the backbone for the AI infrastructure. So it's a purpose-built high-performance cloud, which is designed very specifically for escalating the workloads. So we are backed by

very powerful companies, we are moving actively from experimentation to the production ready workloads. So that's what CoreWeave does. CoreWeave has a number of products, right? So some of them are related to infrastructure backbone, which we call CKS. And then some are where we're adding a lot of flagship customers for inference.

reinforcement learning, et cetera, et cetera. So we are increasing our product ecosystem. So that's what CoreWeave is. We are front and center, and we are actively competing with the big hyperscalers. There's a lot of traction in the market because of the way we approach security, the way we approach fundamentally the

performance of our infrastructure. So we have a lot of traction in the market.

the way it what it means to us right so as a GRC practitioner I would also like to tell you Raj working for AI hyperscaler what does it mean right it means that the traditional GRC models will not work for us it means that the GRC approaches that we have developed within core we have to be able to you know

Jasmine Kaur (02:38.772)
match the pace, the scale, and the high velocity of the business. We cannot make GRC or my team as a gatekeeper. We have embedded ourselves to become more like an enabler for the business because AI cloud or even AI world is so fast and growing and evolving every day.

that we need to change our fundamental thought processes the way we approach security. So that's what CoreWeave is. That's what the GRCs impact within CoreWeave is. And for me personally, I want to help push that agenda forward by ensuring the trust is scalable. It scales along with the performance, the way the company is growing.

The focus is on embedding GRC directly into infrastructure. And then we are able to make GRC a foundational capability within our AI infrastructure and not really an afterthought.

Raj Krishnamurthy (03:45.426)
I love everything that you said. I'm trying to pick and I think you said it beautifully. But maybe let's take a step back because I wanted to unpack what he just said. I think what he basically said is GRC, as we traditionally know it, will not work for at a very high scale environment. Two, you said GRC, as we traditionally know it, will not work in AI or AI sort of AI centric environments, which we are all becoming AI companies of some sort.

Three, you said that, I think you're basically making a claim that GRC is not a post facto, it's not a reactive thing. It can be, I don't want to use the word shift left loosely, but your idea is that we can shift GRC left, right, ahead of, as a proactive life cycle as well. So I want to sort of unpack all those things, but before we do that, Jasmin, let's take a step back. You've been in this space for quite some time. What is your definition of R?

C and G or whichever order you want to put it. What is risk? What is compliance? What is governance? And how have we been approaching this before, let's say the AI era?

Jasmine Kaur (04:55.694)
Yeah, so OK, let's decouple g, r and c. So let's put r, which is always in the middle, but it is essentially your top layer. Right. R is the risks your management cares about. They could be value at risk. You could come up with any frameworks to identify how you want to kind of

compound the risk definition within your organization. So for CoreWeave, the definition of risk is something that ties back to our threat model. We are in an era where AI is kind of relatively new. It's an evolving technology. So we cannot rely on the traditional or old school risk frameworks for us to materially come up with

the top risks we care about. in my definition, the risk management is essentially something that provides you intelligence that is tied to your threat model. Your control plane becomes measurable. You have a telemetry and from those telemetries, you are able to distill signals, thresholds, and based on those thresholds, you are able to track deviations. Right? So we

CG to be the R to be the first. Now your R is going to be driving a work driver for how rest of the C and the G will operate. Right. So if I were to define G is just putting some fundamentals together, some guardrails together on how you want to govern your risks for that threat model.

It could be policies, it could be processes, it could be a hybrid of both. And then you put some controls on top of that to make sure you are staying within that control plane. And for you to be able to measure the effectiveness of that control plane, you have the C. There are market standards, some regulations that drive your compliance, but they are all control centric.

Jasmine Kaur (07:14.912)
And those controls should always tie back to what risks you really care about. So as a GRC practitioner, if Raj I was to tell you, the G is how you govern your risk models. And risk is actually how you measure your telemetries around the risk intelligence and your threat model. And C, which is the compliance aspect of it is, becomes twofold where

You have to adhere to the regulations based off your industry, but also you need to get compliant with your internal risk posture. You need to make sure there are risk reduction goals in place for you to be able to properly do GRC within whatever business that you are supporting or protecting.

Raj Krishnamurthy (08:03.097)
I think one of the fundamental challenges that I've always seen is that I've always attended sessions where people talk about threat models, but I've rarely come across where people have done end-to-end threat modeling. And I'm not saying that we are hypocritical, but what I'm saying is it's actually very, very difficult, especially given the political boundaries within an organization, the knowledge that the teams have, right, and all that stuff.

So my question to you is that who is responsible for threat modeling? Is it the GRC team? Are you saying that the GRC team should take an active role in threat modeling? Or how do you sort of think about threat modeling and who's supposed to do that?

Jasmine Kaur (08:42.222)
So threat modeling is to come from within your security organization. Some sit under CSO, some sit under CSO, howsoever. The threats that your CSO or your organization cares about should be coming from there. But your GRC practitioners, whether they're your enterprise risk manager, whatever your title is, you should be having a seat on the table to influence the policies, the processes, and the model.

development. So it cannot be done in silos. You do not want to be in a situation where you are just an absorber of that threat model. You're just implementer of that threat model. It of defeats the purpose of you being a market

enterprise risk manager. So you need to be involved. You need to be contributing and influencing the way you want your company's threat model to shape up. Because in the end, that threat model is also going to be working for something that is for risk reduction goal. Threat model by itself brings no purpose. In the end, your security engineering leaders

your GRC leaders, assurance people in this whole ecosystem are eventually all working towards one common goal, which is to make sure your environment is secure, which essentially translate to that you do not have any critical risks that are not governed or not measured, or you don't have controls around those risks. So it's like entire ecosystem is tied, but

GRC practitioners cannot be left to live alone and just adopt that threat model. We need to be part of it.

Raj Krishnamurthy (10:32.657)
Got it. I think that's a brilliant point. So what you're basically saying is that in your world view, I'm sure there are people who listening to this podcast who may disagree because I think threat model has also come different, mean to mean different things to different people. what you're basically saying is that understand your threats, model your risks to sort of to solve for those threats, to address those threats, establish your control so that you can measure your risks, and compliance becomes a byproduct.

That's what I'm hearing you say.

Jasmine Kaur (11:04.11)
That's right, yes. mean, is always a byproduct, right? Our world has become so audit-driven and so compliance-centric that we feel that if we've successfully been able to complete an audit, right, then we are secure. We need to flip that thought process. Audit certifications is just a validation that you have a good threat model and you're able to put good controls in place to control that threat model. So yes, I agree.

Compliance is a by-product if top down threat modeling mapping to the risk sector is done right.

Raj Krishnamurthy (11:39.729)
And in your experience, Jasmine, what has been your conversation with the auditors, especially the auditors are very focused on evidence and pardon me for saying this screenshots, right? And assessing that to, know, sampling and things like that. How have you been able to sort of have this conversation with them? Because this could mean that they have to audit your entire process of what we are doing.

Jasmine Kaur (11:54.605)
Yes.

Raj Krishnamurthy (12:08.698)
because they're not necessarily used to the conversation that you're typically trying to have with them, right? Have you faced challenges? How have you overcome those challenges?

Jasmine Kaur (12:17.634)
So the auditors or you know our approach to getting audited is fundamentally based on you know you have a cadence you set up some samples

then you have some population requests. And as long as you are able to provide for the controls that apply to your business and you're able to prove that you have evidence, which could be point in time snapshot, it could be a real time monitored data, your auditor will bless that control to be working effectively, right? That's how typically the audit scenarios work. I have never experienced or

maybe limited experience of an auditor who actually goes deep into your product's infrastructure or your platform, or they really want to understand the nuanced offerings of that product that you have. The point I'm trying to make here is as a GRC practitioner, if you're able to manage the narrative of your controls, then you are able to manage your audit. Right? But the way the world is evolving,

This traditional way of managing audit will not work for us. coming to your question about how am I shaping up and how am I having discussions with the auditors about tying our audit to a threat model is essentially we are evolving our GRC model to be less point in time.

to be less focused on a certain cadence or a machine pulling some evidences from a certain source, to be more assurance-based, where we are going, you know, we're using these mechanisms like policy as a code, control as a code, or embedding GRC part of the infrastructure itself, so that we provide the auditors.

Jasmine Kaur (14:17.25)
with the signals that matter to a threat model, with the thresholds that our threat model wants to track, so that we not only focus on getting the audit point check mark, right? We also want to show how deeply we care about security and how deeply these controls that are not at surface level anymore, but how ingested they are within our...

products or services or processes depending on what kind of audits we are. So we are taking them along the journey of making GRC part of the platform and not just being in an application layer where I've put a web hook, I'm able to pull evidence and I'm able to show that control at a surface level is working. So it's a journey, we're not there yet, but this is how we are approaching it.

Raj Krishnamurthy (15:08.748)
I see, I see, got it, got it.

Raj Krishnamurthy (15:14.53)
You started the conversation saying that the traditional model of GRC is not going to work for the AI world. And I want to come back to that. think what we were discussing so far is that how would you have approached GRC, and maybe you continue to approach GRC that way, but what is in what you described not applicable in the AI world? How does that change?

Jasmine Kaur (15:39.48)
So this is where I'll give you an example. So I think fundamentally, everybody or most of the people understand that AI clouds operate continuously. And they also operate differently than the regular cloud. So your AWS, which is not an AI workload provider, will work different than an AI cloud hyperscaler. So if you were to audit.

And like I said, I'll give an example. At Coreweave, we were to audit our product, which is an AI cloud product. Now, for us to be able to scope that particular audit, we had AI training workloads running on the GPU-backed infrastructure. So that was the infrastructure. So we had to scope this out. So typical audit process, we identified the identities, the compute.

the capacity, the network controls, et cetera, et cetera, right? From that whole laundry list of controls, what we needed to backtrack to be able to pull evidence. So we put that as an audit scope, right? Now, based on that scope, we reached out to the storage folks, the network people, the identity ID providers, our infrastructure providers to provide us the various evidences that we needed, yeah? So what happened?

By the time we finish this whole audit dance of collecting the evidences, right? And we finalize the scope, et cetera, et cetera, the training job that was supposed to be running on that particular product services, right, had already finished. So by the time our audit readiness dance completed, the GPUs were already returned to the pool. The identity was already revoked.

and the new network paths, the storage, et cetera, will be reconfigured and to be repurposed for some other customer or some other training model or whatever the business need for capacity was. So this is how fast-paced my world is. This is how fast-paced I think anybody who's working in AI native products and services, this is how quickly our world is evolving.

Raj Krishnamurthy (17:36.016)
interesting.

Jasmine Kaur (18:02.358)
Now, within this story, the reason I'm giving you this background is we received the artifacts, but the artifacts were kind of stale. Right now, I was not able to provide the effectiveness of a point in time evidence. Was my system not working as expected? It was right. The business model we are in was working.

as it was expecting. Nothing was broken. The platform worked as designed. It had all the required security controls. It had all the processes in place. But was I able to prove effectiveness of all these controls? No. Right. And that's where the certification gets risky. Right. It's hard for me to prove the effectiveness of a control.

And then it requires a lot of audit discussions, GRC practice narrative building, et cetera, et for us to really achieve that. So this is where we learned that the long audit cycles, the traditional GRC models of having a cadence, a sample, or population will not work for our AI infrastructure world at least. So that fundamentally is not a people problem.

It was not an execution problem, right? We have skills, we know what we have to do, we are experts. Even on the audit side, the auditors knew what they really needed, but it was actually a model problem. The way we were approaching to achieve audits was not working for us from an AI infrastructure provider point of view.

Raj Krishnamurthy (19:51.114)
I think that's a brilliant way you put it, Jasmin. Let me... And by model, you... Just to be very clear, when you use the word model, are you talking about learning models like anthropoclod, opus models, or are you using GRC as a model? What did you mean by a model?

Jasmine Kaur (20:07.502)
In this example, when I say model, I mean the GRC model. Are ways to operate GRC, you can call it approach.

Raj Krishnamurthy (20:12.045)
Yes, sir.

God, I think this is brilliantly put and I'll tell you what you, I think you're touching on something very, very, very interesting. So if I can summarize what I heard from you, what you're saying is that I think in the traditional world, we assume some level of permanency of systems of process and sort of the inter-process between them. And what you're saying is that in the new world, and I think that is true for the cloud world, but what you're saying is,

In AI world, it is even worse that these are extremely ephemeral. What exists today does not exist the next moment. And the question is that how do you demonstrate proof and test of effectiveness, right? And how do you apply the same principles that you've applied for so long? And that's the argument that you're making. Is that correct?

Jasmine Kaur (20:52.056)
Exactly.

Jasmine Kaur (21:04.43)
That's right. Yes, and I totally agree, like I said, right? So to your point, audits assume the system will pause long enough for it to be able to sample or pull an evidence, right? But the AI systems don't. And it's not only because there is a misconfiguration, it's because they are short-lived by design. And the design reasons could be needing for capacity, spinning up, training, inferring.

Raj Krishnamurthy (21:26.127)
100 %

Jasmine Kaur (21:32.322)
turning down, cetera. So the way it is designed does not equally equate to the way we can audit it.

Raj Krishnamurthy (21:41.059)
High percent, beautifully. And I think there are, in your case, just one second, I wanna pause. Eric, I'm hearing an echo here. Are you hearing an echo? We'll take this away in the post, Jasmine, just one second. I wanna make sure. Eric, can you come back?

Raj Krishnamurthy (22:00.568)
It was okay until now, but I just heard an echo from Jasmine.

Raj Krishnamurthy (22:07.628)
I don't hear it anymore. Anyway, you can go off if I continue here, I'll call you back. I don't want to lose the train of thought, so thank you.

Jasmine Kaur (22:07.896)
through.

Raj Krishnamurthy (22:18.34)
Maybe I'll continue again, Jasmine, we'll edit this in the post. But I think what you're saying is actually in your case particularly, you are hit with a double whammy. On one hand, you have to operate at the speed of declarative systems. I think CoreView is one of maybe the largest Kubernetes shop. And you're also maybe one of the largest AI infrastructure provider as well, which is very interesting. So you are hit with the ephemerality of, if I can use that word,

Jasmine Kaur (22:41.357)
Yes.

Raj Krishnamurthy (22:47.16)
of how sort of a new platform, declarative platform like Kubernetes performs. And you're also thinking about how AI is fundamentally changing the decisions that are being made at runtime on a declarative model like Kubernetes as well. So you have to deal with both those sort of unknown unknowns from an audit perspective at least, right, to deal with the traditional way of auditing. I think that's a very interesting viewpoint. Is that correct? Did I capture that correctly?

Jasmine Kaur (23:15.49)
That's right. And then I think you kind of hit the nail on the head, right? We are working for CoreWeave, right? As GRC practitioners, we are in catch-22. So the challenges that I'm telling you are the traditional models, right? We are experiencing, we're trying to evolve out of those challenges and make them work for AI hyperscaler. And the second part is that we need to be the brand ambassadors for AI.

So anything that is being developed using the AI model, agents, your infrastructure, your products, anything that is AI native, we have to be the brand ambassadors of those. So we have to be early adopters of anything. For example, agent at GRC. I need to be able to adopt it. But how do I adopt it is a catch-22 because I also wear a security hat.

Raj Krishnamurthy (23:48.976)
Mmm.

Raj Krishnamurthy (24:00.612)
I so.

Raj Krishnamurthy (24:11.791)
I want to get into the agentic GRC and I think that's a looks like that's going to be a fascinating discussion but I want to go back to what you just said. So you said this is not the traditional GRC. I was going to say this is not your father's GRC but for some reason I felt that was not politically correct statement. I would say that nonetheless. We are in the new world of GRC where we have to consider ephemerality which is the point you are making. Now the question is

How are you having these discussions with your auditor? You're already doing this, right? In some ways, you are being compliant, you are doing a lot of stuff. So what is that you're, can you describe to our audience the conversation that you're having with your auditors on how you explain to them this difference and what are you asking them to do?

Jasmine Kaur (25:04.109)
So

Like I said, there are maybe two or three aspects to it. Right. So the first aspect is that we are trying to bring our auditors along the journey. What what I mean by that is that we are trying to educate them or train them on AI. Right. So in my past few audit experiences, what I have

learned is that this AI cloud hyperscale world is also new to our auditors. So the auditors come in with a mindset, you are a typical cloud provider. So the lens that they have is similar to what they would be auditing a regular cloud provider with. So that was the first thing that we tried to decouple. We started to bring them

education and training around why AI Cloud and how AI Cloud is different than a regular cloud. What are those nuances that stand out in AI Cloud that are making it challenging for us to put a control plane together, leave aside being able to prove whether it's working or not, right? So,

That is the first aspect and that has been our road show as of last year to bring everybody along the knowledge gap that exists about AI cloud hyperscaler. Whether it's a product or a service that is running on that product, that is, I think, important for our auditors to understand the difference between the two type of clouds now. The second is

Jasmine Kaur (27:02.75)
what we are doing within Core V for the GRC model changes. So what we've started educating within our teams as well is we don't want GRC or governing AI Cloud or product services really does not have to be a product review process, right? So we want to make sure GRC becomes part of

our core product offering. It becomes part of our infrastructure itself. So when I say GRC as infrastructure, I'm not just meaning just as a metaphor, right? Like it's not a cool word that I just want to throw out here. I mean something very specific. So if you understand infrastructure is a system that, know, something that you can depend on continuously. It's not just an application layer.

Raj Krishnamurthy (27:36.697)
What do mean by that?

Jasmine Kaur (27:59.36)
or it's not just a presentation layer that you visit quarterly or when you're audited. It's not a documentation that you produce. When I say GRC is part of the infrastructure, I mean your control set, your compliance guardrails are embedded in the infrastructure itself. It runs all the time. It scales automatically.

It works whether someone's watching or not and your assurance is emitted and it's not really requested. You're not requesting evidence every time. Your system is emitting it.

Raj Krishnamurthy (28:34.831)
Very interesting. Very interesting. Can you... Let me make sure I understand what you're saying. I think what you're basically saying is traditionally when we think about, and I'm using the word GRC broadly here, even though there are three components, it is typically considered a back-office activity. What I mean by that is on a periodic basis, go fetch me a list of users. Let me get the list of users. Are these users on the right roles? Do they have the right privileges?

And I'm evaluating that against some corpus of data, applying some rules saying whether they are compliant or not compliant. And what you're basically saying is, and that is fine, what you're saying is that you want this to be a living and a breathing thing. So as transactions happen within a system, you want to be able to evaluate if they are compliant or not. That's what you're talking about.

Jasmine Kaur (29:26.51)
That's right, yes, through signals thresholds. So imagine, you know, your GRC, even if it's just compliance and risk, right? It's part of a platform capability, which means that your encryption is automatically enforced. That's one part of the story, but it is automatically auditable by design. You have a signal and a threshold based of which you can track deviation. Or your identity access management controls.

Raj Krishnamurthy (29:47.693)
Yep, 100%.

Raj Krishnamurthy (29:54.191)
And what do you say to those people? say, we've already solved that problem, have we not? Because we are pushing all these logs into SIM and we can look at them. And how is this different than traditionally log shipping into a central SIM like Splunk or LogRhythm or anything like that?

Jasmine Kaur (30:11.64)
Yeah, so it's a very good question and it's a very interesting discussion that we've been having internally as well, right? So understand SIM to be more like a detection and response vehicle, right? You have a lot of logs in that which are now from a telemetry perspective designed to track anomalies and deviations for certain set against the risk and the threat model that you care about.

Now add a layer of your compliance guardrails to that distilled log logic. And then based on that, in addition to emitting your incidents, anything and everything else that you need from a deviation detection, you are also able to admit whether that particular signal is within your compliance boundaries or not. Whether you're deviating from a threshold of a compliance or not.

Raj Krishnamurthy (31:06.433)
I love what you're saying.

Jasmine Kaur (31:10.464)
and not just detecting a gap, right? You need some signals to be able to reason the deviation.

Raj Krishnamurthy (31:16.302)
I love what you're saying. So what you're basically saying is that it is not just a passive mechanism of logging transactions or results or exceptions. It is an active mechanism to understand the configuration status drifts or anything that you would want to to emit clear signals that can be acted upon as soon as possible. That's sort of the fundamental difference. That's beautifully said.

Jasmine Kaur (31:39.054)
That's right, yes. And then also with Agent Tech GRC, my hope is if you add that layer on top of it, it should be able to give you reasons. It should be able to give you prioritization, stack rank remediations, you know. So imagine you have hundreds and thousands of terabytes of logs in a SIM.

But they will be useless if you're not able to make sense of them for compliance purposes and you're not able to act for remediations. You're not able to have reasons why you should care about those.

Raj Krishnamurthy (32:14.04)
Got it. So the way we think, or at least the way that I sort of thought about the GRCS transformation is what I would call the GRC 1.0, is primarily around how we take screenshots faster. So don't hate me for saying this, right? Maybe the RPS of the world, robotic process automation world. I think that has evolved into something what I would call sort of either the CCM 2.0, GRC 2.0, whatever term you want to call it.

Jasmine Kaur (32:29.954)
Yeah.

Raj Krishnamurthy (32:43.17)
which is around how do we connect and stitch across multiple systems with APIs, collect data, normalize them, standardize them, potentially even remediate. I think the third curve which you are talking about, which is very interesting, and to be honest, there are very, very few people that are talking about this, which is how do you turn this, not just API interactions, which is important, but how do you turn them into agents? I want to double click on that a little bit because I think you're bringing up an interesting one. What is agentic GRC?

What is your definition of agentic GRC?

Jasmine Kaur (33:15.69)
Okay, so my claim is agentic GRC is not CCM, right? Like you stated, there are three stages of the GRC maturity. The automation that you talked about is a machine going on a certain cadence, capturing the snapshots that you need and is able to keep them fresh instead of a human doing it. That was stage zero of GRC.

Then we move to this middle stage, which is stage one, which is CCM. So CCM, in my opinion, is now you have another logic that you have built, which is continuously going and hitting the same source for your evidence enrichment, monitoring it for certain parameters, and then spitting out your deviations or drifts.

you know, very specific to a certain criteria of the framework. That's the CCM piece. I see Agentic GRC to be the further advancement of both these worlds. So the automation advanced into CCM. Now it's time for CCM to advance into Agentic GRC, right? And when I say Agentic GRC, I mean not rule-based, it's not hard-coded.

Right? It's not just deterministic, but it is something that is capable to take decisions. It is a decision capable agentic GRC. That will be my definition of agentic GRC.

Raj Krishnamurthy (34:53.9)
And let me ask you this question. think this is the fundamental problem that we've all been struggling with. In fact, we have had people like Varun Prasad, who is the, I think he's the managing director at BDO, if I remember right. He's an Uber auditor. And we've had multiple conversations with both GRC practitioners and also auditors. And the challenge is this, Agents and large language models fundamentally are probabilistic in nature. Agents,

are even worse because agents compound those probabilities. If you have an agent producing 95 % probabilistic response, you compound that with another agent. It is 95 % of 95%. It gets worse and worse over a period of time. That's not necessarily true all the time, but I'm just making a very simplistic math here. My question is that as auditor, what is extremely difficult is that

In security and compliance, we are talking about deterministic. Either it is compliant or not compliant, right? How do you apply take this probabilistic agents into a deterministic world like compliance? How do we solve the problem?

Jasmine Kaur (36:06.254)
So the ultimate agent or agentic GRC, right? I agree with the opinion from, you know, Varun and all these people, but we need to have a moonshot. I am, I believe in visions. I believe in having a moonshot.

the work if I were to use an agent take GRC today, I will probably not use it because it's not ready for prime time, but we have a responsibility to make sure we build a GRC AI model that we all can rely on building a agent take GRC. We can call it a community project to build a GRC AI model and then

Raj Krishnamurthy (36:48.736)
Mm-hmm, mm-hmm.

Jasmine Kaur (36:57.056)
we become responsible to leverage that model to create the agents the way we want it, which are secure. They provide the telemetry. provide the visibility. And it goes beyond automation, but it's not autonomous. So you still need a human. We still need to be the practitioners who

Raj Krishnamurthy (37:13.198)
the guarantees.

Raj Krishnamurthy (37:25.293)
beautifully said.

Jasmine Kaur (37:25.826)
with the final lens on it. So let's not confuse agentic GRC to be 100 % autonomous. Like I said, it's beyond CCM, but it's not entirely autonomous. If you make agentic GRC autonomous, then we are again going to that catch-22 I talked about. How do I govern an agent? How do I make sure the agent is doing the right thing? So we will have to see how we evolve this space.

Raj Krishnamurthy (37:53.784)
Got it. Interesting. I hear you loud and clear. And I think this particular conversation that you brought up, I don't think it is an optional thing anyway. I think it goes back to fundamentally the case that you were building, is, number one, we are getting into a very higher degree of ephemerality with our systems and processes. Two is that they are all becoming sort of dynamic decision. They are not rule-based, which is a brilliant point that you made.

and they are dynamically determined, right, based on actions and heuristic response, previous heuristic data, so on and so forth, right? So you have to go, it's not even an option, because given those two parameters, you can't choose to do audits on a periodic basis anymore, and those statistical or static ways of doing things cannot exist, because they are antithetical to what he just talked about, right? So I think that's a brilliant way to put it.

Well, the one question I want to ask you, Jasmine, is that are we to this conversation that we are having, are we going to come out as very academic and just sort of daydreaming when in the reality most people are still struggling with continuous controls monitoring?

Jasmine Kaur (39:12.814)
I think yes, in the sense and the reason I'm smiling is

Jasmine Kaur (39:22.902)
If you go back a few years, when AI was still getting built, I used to work for Google, there were a lot of traditional AI models, which were hard-coded rules based on which there was some machine learning logic built. Then over the period of time, AI has evolved and chat GPD just changed the entire world. Now, if you talk about that era,

When we were able to do whatever we were able to do as a GRC practitioners, we did not have a sight of what was happening behind in our backyard. were, as a GRC practitioners, we were not able to keep pace with the way AI was getting built. Now we are in the middle of this world where I think it's inevitable to

avoid anything with AI. So I shift from an e-commerce product to an agentic shopping cart. And as a GRC practitioner, if I was doing e-commerce audit, right, five years ago, my methods would have worked. But now I have to audit an agentic shopping cart providing company.

You know, they have this as a product. I can not think small, right? I don't know if that answers your question. Yes, sometimes you feel we are living in this bubble where since we are in AI, we feel we have to do this. But if you think ahead and if you do not keep pace with the way AI is getting embedded into every product, everyone's life, and you're not able to modify your GRC models,

we will be left behind. We really need to be lock-stabbed with the way AI native products, services, schools are getting built.

Raj Krishnamurthy (41:29.293)
I think that's a fantastic. What do you think is the current state of GRC products? And particularly, do you think GRC products should continue to focus on building dashboards and reports?

Jasmine Kaur (41:43.16)
Okay, so I think this is where the controversy, I will get a little controversial, right? So I feel, and going back to my point about if we do not evolve the way GRC products are being built, right? If we still continue to build the product to building, like you said, dashboards or adding more connectors or, you know,

continue to operate in that application layer just to add more evidences and just to automate the life of a human so that they don't have to capture evidences. I think that GRC product market is going to shrink. That model does not operate at the same pace or expectation of the AI native products. So

If a company is able to reorient their product offerings to embed whatever they're doing part of the foundational infrastructure, I think five years from now that is the company or that is a product that is going to stay.

Raj Krishnamurthy (42:59.245)
I think you're touching a very, very, very interesting point, Jasmine. And the reason I'm saying this is that what you're describing has traditionally been seen as a systems engineering problem. So I'll give you an example. Kubernetes has this very famous concept of declarative mechanisms or reconciliation mechanisms where there is an as-is state and you're constantly measuring and there is a to-be state.

and its entire job is to reconcile between the asset state and the to-be states. And it does that automatically and autonomously. I think the agentic world is something very similar. In fact, it makes it worse. The point I'm trying to make is that for what you are saying, GRC products have to become as systems engineering products as security is.

Jasmine Kaur (43:28.642)
Yes.

Mm-hmm.

Jasmine Kaur (43:47.5)
That's right. Yes. Yes. And you have to make GRC more like a reliability function and not a back office audit function.

Raj Krishnamurthy (43:48.47)
Adios.

Raj Krishnamurthy (43:54.701)
Mmm.

So you're almost saying that GRC and what you're doing as this auditor, a compliance theater, you are basically predicting it's going to be pretty much useless.

Jasmine Kaur (44:06.498)
I think so.

Raj Krishnamurthy (44:08.192)
Okay.

And I think that is a fantastic way to sort of think about this. And I think it's a very tall order for a question. Let me ask you a slightly different question. As an industry leader, I know that you actually, you're a speaker in these circuits, in security and GRC circuits. You do a lot of that as well, and you will meet a lot of people in this. What do you do? People generally, are they with you? Is there a movement towards making this happen?

Or are you a lone voice in this daydreamer?

Jasmine Kaur (44:43.47)
So I think I'm not a lone wolf in a sense because a few years ago, a term called GRC engineering was coined, right? I think the intention of coining that term was to eventually evolve GRC from being just a back office team to be more engineering focused team. And the logic for building this or coining this term was not just,

you know, a career making term. The logic was to make it more like a reliability function. Make sure whoever you're hiring as a GRC engineer is not solely focused on adding more connectors for you to be able to automate more evidence polls. The fundamental was to make sure that person with SWISic skill sets, right,

understands compliance world, understands the problems of the compliance, understands security controls, and then can get plugged into security engineering and make controls as a code. Policy as a code started, controls as a code, start to do everything from command lines, and then have a path put together for GRC to be embedded.

in the platform, right? Are we there yet? No. Are we going there? Yes. So if you hear a lot of podcasts or you read about the GRC on LinkedIn or whatever your source of information is, you will see that the GRC engineering's fundamental, the reason it was started, it started to go back to why it was started.

I think people started to misinterpret GRC engineering to be, I can do scripting. I'm a GRC engineer, hire me, and I will be part of the GRC engineering function. So it kind of lost its value with that misinterpretation of the reason it was started. But I think it's coming back to where you want your engineering to be GRC platform. So answering a question, not a lone warrior, a lot of people

Raj Krishnamurthy (46:54.24)
I love it, love it. Harbors it.

Jasmine Kaur (47:02.168)
kind of agree that the work with GRC engineering that is being done right now is very small and it needs to scale to be more embedded, more as a code, more part of platform, signal oriented, how so you want to shape it.

Raj Krishnamurthy (47:20.246)
Now, I'm sure I agree with you. Now, slightly different question, right? Which is, what is even more difficult in your role is to convince your leadership to go put money behind this, right? To hire and build this assurance function, if you will. How do you have these conversations? because GRC is seen as a sort of a sinkhole, right?

Jasmine Kaur (47:35.064)
Yes.

Jasmine Kaur (47:49.346)
Yes.

Raj Krishnamurthy (47:49.429)
You just do enough not to get fired or not to get a material defect right from your auditor. So how do you convince your leadership team to say it's much bigger than a compliance theater or an audit theater and it has to be very proactive and it has to be an assurance function like we talked about?

Jasmine Kaur (48:08.11)
So different ways of approaching it depending on who in leadership you're talking about, right? So within like we sit within security organizations. So our CSOs, my manager, they understand the implications of running GRC only at a surface layer, right? So it's an easier conversation to convince them to make.

you know, or maybe open some head counts for assurance engineering or make a separate function called assurance engineering because they understand GRC is not only about evidences, it's not only about audits, right? It's not only about adding more integration work to automate those evidences. It's primarily about embedding, making sure we are more secure.

So it's an easy conversation because then you are able to tell them that the primary responsibility of an audit is also to come and tell you that whether a particular control is working the way it is working or not. So if you flip this question back to the leadership, do you want an auditor to come and tell you about your risk posture, about your control effectiveness once a year?

versus we make it part of your programs, we make it part of your platforms so that you can know it real time. You know whether that control threshold is being deviated, drifting, or is it within the compliant guardrails. So once you start having those kinds of discussions, I think it's easier for you to sell your vision of assurance engineering.

Raj Krishnamurthy (49:57.739)
Love it. And what if they say so what? So what if we know ahead of time? So what if we are proactive?

Jasmine Kaur (50:06.104)
So what if we are proactive, then we are able to remediate them early. It's not a major, minor, or if I find in question anymore. It's about making sure your infrastructure is secure. You don't want a bad press at a stage when you're actually growing really, really fast. So you have to come from that value at risk angle if the security angle

becomes a so what.

Raj Krishnamurthy (50:36.906)
Okay, got it. I think that's a brilliant advice, Jasmine. And we are approaching almost the end of the segment, and I want to ask you, there are very few women cybersecurity leaders. And I don't mean to stand out women like that, but I think it is in our best interest to see more women in leadership positions, more women, especially in cybersecurity. What is your advice to the girls or the ladies listening to the show, right?

How do they become the next Jasmine core? What would your advice be? How can, what can they do to come up the ranks?

Jasmine Kaur (51:14.766)
Sure. Yeah. So I think my first advice will be be fearless. Right. So you don't have to have a perfect plan. You really don't need to know everything. You really don't need to have everything on their job description on your resume for you to be able to even try that.

You just need to have curiosity. You need to have willingness to follow what interests you. Passion projects, learning, joining conferences are incredibly underrated. The value that you get out of doing such passion projects or the high learning, they open a lot of doors for you. So don't be scared to try something new. Believe in moonshots.

Believe in your capacity and your capability to achieve those moonshots. Because when you're part of a technology, and especially within the technology, when you're responsible for security, you need to be a forward thinker. You cannot be looking back. You need to think how the technology is evolving. Where can it fail? How can you protect it? And then what you need to put in

place in your skill set to be able to do all of the three.

Raj Krishnamurthy (52:46.508)
I think that's great advice. And if people have more questions and they want to reach you, what is the best way to get hold of your adjustment?

Jasmine Kaur (52:54.784)
message me on LinkedIn. I'm pretty active on LinkedIn. So I am happy to meet you for coffee or whatever you need my help for. I'm a community builder and I believe that it's high time that we need to start giving back to the community.

Raj Krishnamurthy (53:13.537)
And with that, Jasmine, it has been an absolute pleasure to speak with you. Some great insights, great conversation. Thank you very much.

Jasmine Kaur (53:21.87)
Thanks, Raj.

Raj Krishnamurthy (53:24.342)
Eric.