Controlled Chaos: Enabling Innovation While Ensuring Safety & Security

Michael Waite: Happy Friday, everybody. It looks like we have a few people joining, so we will go ahead and get started.

I am Michael Waite, co-founder and CTO of Dune Security. I am joined by Sheron Chakalakal, head of GRC at UiPath, Christopher Donaldson, executive security advisor and vCISO at CXD Consulting, and Michael Carroll, director of GRC at Yugabyte.

We are really excited to talk today about an interesting paradox that security leaders face every day: balancing the pace of innovation with remaining secure. If you innovate too slowly — if you focus too heavily on being airtight with security — you might miss critical opportunities. But if you innovate too quickly and are hasty with security, that is a recipe for disaster. We have three outstanding security leaders here to dig into that paradox.

Before we dive in, let us give everyone a moment for proper introductions. We will start with Sheron, then Chris, then Mike.

Sheron Chakalakal: Thank you for the introduction and for this opportunity, Michael. Hello, everyone. I lead the GRC program at UiPath. I have been with the company for more than five years now. Previously I was leading compliance programs at Salesforce, and I started my career as an engineer.

Christopher Donaldson: Pleasure to meet you all, and thank you for the invitation to join the panel. My name is Chris Donaldson. I am a principal at CXD Consulting. I specialize in executive security strategy — working with CISOs and executive teams on defining what they should be doing, why, and how they are actually going to achieve those objectives. Really looking forward to this conversation.

Michael Carroll: My name is Mike Carroll. I am the GRC director at Yugabyte. I am primarily responsible for overseeing our security and data privacy compliance programs, along with informing our risk management strategy. Before this, I spent about six or seven years in a combination of IT audit and cybersecurity consulting roles.

Michael Waite: Fantastic. Thank you all. Sheron, let us start with you. Our industry has been talking about the tension between innovation and security for over a decade. When you hear the phrase "controlled chaos" in the context of your work, what does that actually mean to you — and has the definition changed as the pace of business has accelerated?

Sheron Chakalakal: This is a great topic, and honestly one we discuss every year as the company grows. For us, controlled chaos means enabling rapid innovation in a safe and secure manner. The speed of that innovation has kept changing, especially with the boom of AI — it almost feels like being in startup mode all the time while simultaneously operating as a public enterprise.

UiPath went public five years ago. I joined before the IPO and we were already in startup mode. Five years later, we are still in startup mode — continuously innovating, breaking things, and building more. The culture has not fundamentally changed even as we matured from startup to public company. It is just continuous chaos, executed safely and securely.

Michael Waite: Tell me more about that transition from privately held to publicly traded. There is a lot more scrutiny involved. How do you balance that?

Sheron Chakalakal: You have to work very closely with leadership — not just security leadership, but engineering, product, and every other team — to understand what works for them, what balance is achievable, and how quickly each team wants to move. Then you figure out how early you can integrate into their processes — ideally as early as planning and design — so that security does not become a stopgap at the very end. The only way we were able to mature as the company matured was by being there from the start, in the conversations about what is coming in six months. That has helped us stay ahead.

Michael Waite: How do you keep this balance front and center given how fast the pace of innovation has accelerated? If you are only revisiting it annually, there is a lot of missed opportunity.

Sheron Chakalakal: You are constantly evolving as the company and the industry adopt new technologies. When AI arrived with enormous speed, teams started using it to build more things, more quickly. We were forced to use AI ourselves — to use AI to safeguard AI. If you are not malleable enough, not flexible enough, you fall behind and people stop taking you seriously. But if you are flexible and find a balance between your objectives and the company's, you can reach a common solution together.

Michael Waite: Have there ever been moments where the pendulum swung too far toward innovation, or too far toward security? Any examples you can share?

Sheron Chakalakal: Absolutely. With the explosion of AI coding agents and AI-powered applications, we started seeing tools proliferate everywhere — vendors embedding AI into every product almost overnight. At a certain point it became: how do we control all of this? We had to go back to the beginning, look at our boundaries, add more guardrails as we learned more, and mature the approach incrementally. That is typically what we do whenever a significant new technology emerges.

Michael Waite: Chris, how do you help the different companies you work with manage this? I imagine the paradigm is different for each of them.

Christopher Donaldson: It really does depend. I tend to conceptualize organizations in three different buckets — they are not necessarily sequential phases, but most organizations sit in one of them at any given time.

The first is compliance-focused. At the executive level, the conceptualization of what matters is compliance. For B2B SaaS companies in particular, security is often synonymous with getting a clean SOC 2 report, ISO certification, PCI, or whatever certification unlocks enterprise revenue. If you are in a regulated industry, compliance is the price of entry. That phase can last a long time.

The second is risk mitigation. This often follows compliance, especially as organizations reach a Series D, IPO, or get acquired — there are real assets at stake now, and executives start asking what comes after the certifications. The question shifts to: what material risks could put us out of business?

The third is what I would call next-generation security — insider threat programs, AI security, ongoing innovation. The problem is that organizations that try to jump straight to the third bucket without getting through the first two tend to do neither particularly well. If you have a team of five people and you are being asked to run an insider threat program while also getting SOC 2 and ISO, something is going to suffer.

The key is understanding what phase you are in and calibrating your priorities, communications, and executive expectations accordingly. Security has historically been in a damned-if-you-do, damned-if-you-do-not situation — holding all the responsibility with none of the upside. Getting the CISO or GRC lead embedded in the company's strategy from the top down is the most consistently successful approach I have seen. Then you ride the lightning in terms of what you can actually accomplish.

Michael Waite: Mike, how do you manage the controlled chaos at Yugabyte?

Michael Carroll: I see it as a spectrum. On one end, you implement controls to protect against the risks everyone thinks about — data breaches, ransomware, the events that land you in the news. On the other end, if you implement no controls at all, you can move very fast, stay innovative, and keep up with customer demand immediately. Speed is one of your core competitive advantages as a startup — something a Fortune 500 company genuinely struggles to replicate given their layers of review and approval.

Going all the way to the controls-heavy end of that spectrum cuts the legs out from under you if you are a startup. The goal is finding the balance, and doing it in a way that is consistent with where the organization is actually trying to go. The first conversation you need to have as a GRC practitioner is: what are the goals of the company, what are they trying to achieve, and how much risk are they willing to take on to get there? Once you have that, you can have an intelligent conversation about how much to enable speed versus how much to add friction in the name of protection.

GRC is fundamentally managing that game — and understanding that the balance will shift as you grow, take on more complex customers, and raise additional rounds of funding.

Michael Waite: I want to double click on something Mike and Chris both touched on — the compliance frameworks we have historically used as a stamp of approval for security posture, like SOC 2 Type 2 and ISO 27001. How do you view those frameworks as a true barometer of security, and what do you supplement them with to actually sleep well at night given today's landscape?

Sheron Chakalakal: We had a foundational decision to make at the start: go compliance-first or go risk-first. We quickly understood that if we organized around chasing frameworks, we would always be in a catch-up scenario — forever creating new controls for each new framework. So we chose to be threat-based and risk-based from the start. We built out our risk register, defined the processes that close or mitigate those risks, and then identified the controls that govern those processes. Mapping to frameworks then became relatively straightforward — often we were already doing more than what any given framework required. At that point, adding a new framework is not a big deal; it is mostly just a mapping exercise.

Christopher Donaldson: The way I frame it for clients is a three-legged stool. The first leg is compliance — the things you have to do. The second is material risk mitigation — the scenarios that, if they occurred, could put the business out of business regardless of whether they are covered by your SOC 2 or any certification. You need to identify three to five of those and make sure you can survive them. The third is hygiene — the baseline practices that apply everywhere, across the whole organization, as a lowest common denominator.

Compliance tends to be very scope-specific: a particular ISMS, a particular product, a particular data type. It does not apply universally. Sectioning these three pillars off intentionally and burning through them from left to right — compliance, material risk, hygiene — is the framework I have seen work most consistently.

And to the framework question directly: treat frameworks as frameworks, not as prescriptive requirements. The right question is not "what does SOC 2 require?" The right question is "what risk is this control designed to reduce, and what is the most sensible way to address that risk given our specific business?" Most major frameworks — SOC 2, ISO, and many others — give you the flexibility to implement controls in a way that makes sense for your context rather than mandating a specific solution.

Michael Waite: I want to dive into the relationship between security and the rest of the organization. Security wants to protect the business — that is the prime objective. But sales and revenue teams want everything done yesterday. If security slows people down, that is security's problem. If security enables fast innovation and something goes wrong, that is also security's problem. Chris, how do you manage that relationship with the companies you work with at CXD?

Christopher Donaldson: It is genuinely tricky, and not just because it is objectively difficult — it is the expectation management piece that is so challenging. Getting everyone on the same page about trade-offs is hard because most organizations, in my experience, do not actually have a security strategy. And when I say security strategy, I mean something at the executive level that everyone has agreed on: what are we trying to accomplish with security, why do we do it, what does it mean to us, and what does implementation look like. That tends to be absent — and when it is absent, expectations get misaligned. You end up with the CIO marching in one direction because the CMO and CRO told them compliance certifications were the priority, and now someone is asking for something else entirely.

We have a responsibility as security leaders to force those difficult conversations early. Push for clarity of expectations from the top down, even when things are not clear. That is the foundation on which you can build a coherent path forward.

Michael Carroll: I agree with Chris that it is a difficult challenge. One thing that reduces friction significantly is aligning your goals with the organization's goals. Here is a concrete example: say egress control is a risk I want to address. If I go to the engineering team on my own and ask them to take it on, it is probably going to end up in the backlog. But if I know that breaking into the financial sector is a strategic revenue priority, and I know that financial customers require PCI, then egress control is not a security initiative — it is a prerequisite for winning those deals. Now I have alignment with the business. The security initiative becomes a revenue enabler, and that is a much more compelling case.

Sheron Chakalakal: Absolutely. Using GRC and compliance as a sales enablement tool is very effective at creating alignment. A great example: when UiPath was looking to expand into multiple international regions, the go-to-market and support teams quickly realized that security had to be part of that conversation from day one. Data residency requirements, public sector compliance frameworks — customers in those regions required it. So we became sales enablers from the start rather than a bottleneck at the end.

Michael Waite: Sheron, how far in advance do those conversations need to happen? If someone says we want to open up an APAC region — how early does security need to be in that conversation so it is not the bottleneck when it is time to go live?

Sheron Chakalakal: We start at the business case. When the conversation begins about entering a new region, it includes: what is the projected ARR, what will it cost operationally, and within that cost — security and GRC are part of it. Not just maintaining the region ongoing but implementing all the necessary controls from scratch. It has to be at the very start, because the teams quickly learn that missed opportunities happen when they did not bring security in early enough.

Michael Waite: I want to touch on shadow IT — when things are locked down or policy is unclear, employees go around security and install things they should not, or take actions that introduce risk they may not even realize violates policy. How do each of you approach this?

Michael Carroll: The first step is making sure people have access to the tools they actually need to be productive. If we fail that baseline, either we are slowing the business down or — more realistically — people are working around us on personal devices or personal licenses. Once we confirm the right tooling is available, the door also needs to be open for additional tools, because in the age of AI, tools are constantly leapfrogging each other, and locking teams into one or two options is overly limiting. The third piece is having an efficient procurement process where people can request tools and we can vet them from a legal, financial, and security standpoint quickly. And we try hard to consolidate — cutting duplicate tools that do the same thing. Flexibility within reasonable boundaries helps you get the best of both worlds.

Sheron Chakalakal: I agree with Mike — you have to meet people in the middle. When ChatGPT arrived, we could see immediately that people were starting to use it. At that point, there were not enough tools to understand what data was going into it. So we moved to the enterprise version, put guardrails around it, and made it available to everyone. That way, we were not leaving people unsatisfied or blocking their productivity — they could just use the enterprise version with appropriate controls rather than going to a personal account. We always try to work with teams: if a tool is going to help them move ten or twenty times faster, let us get the enterprise version together, add the right guardrails, and move forward with them.

Christopher Donaldson: I see both sides of this one. There is a part of me that wants to lock everything down, and another part that wants to just say go fast and figure it out. Right now, one of the big examples of this challenge is AI coding tools with all their new plug-ins from GitHub repos that are created daily. How do you go at the speed of innovation when that is happening?

The only thing I have found real success with is collaborating directly with principal engineers and senior architects on shared objectives. I use what I call the grumpy engineer test: how would a grumpy engineer respond to this request? If I can pass that test, I am making a rational, business-positive decision. And when I can actually work alongside a grumpy engineer — that is the best scenario. Because engineers fundamentally get it. They do not want to ship something that blows up. I believe everyone on the engineering side wants to do the right thing. The key is framing it as collaboration toward a shared goal, not telling them what to do.

Michael Waite: AI has been coming up in everyone's answers, so let us open Pandora's box. Over the last three years, the pace of innovation has hit an inflection point — a genuine hockey stick moment. When we first started working with ChatGPT building Dune in the early days, it felt miraculous. Today AI is core to everything we do — it gives our developers superpowers and lets our go-to-market teams move much faster. Incredible, but with enormous risk attached.

When I look at tools like Claude Code, which now runs with system permissions locally and integrates with a wide range of unvetted tools and plug-ins — that can introduce tremendous risk. But if companies are not using AI, they will get left behind. Mike, how do you look at this current paradigm, especially with agentic AI use cases, and how do you balance capturing the innovation while staying eyes wide open about the risk?

Michael Carroll: We have definitely hit the inflection point — my parents asking about ChatGPT is a reliable litmus test for that. A year or two ago, AI was a differentiator. Today it is table stakes. The question is no longer whether the business wants to pursue AI — it is how to enable the business to use AI safely and effectively.

AI has also fundamentally changed how a lot of people do their jobs. In many workflows, people have gone from being the doers to being the reviewers. Even in IT audit firms, junior members are increasingly reviewing the output of AI-driven testing rather than performing the testing themselves. That is a big shift.

From a risk management perspective, I view AI tool evaluation as a vendor review on steroids. All the normal risks of a SaaS platform, plus additional dimensions — both security and legal. For example: if I put our proprietary source code into ChatGPT, have I just handed that code to a third party unnecessarily? And on the output side: do we actually own what the AI generates, and can we use it commercially? Those questions need careful evaluation between security and legal together. And the answer is often not a hard no — it is about understanding the license tier. The free tier of a tool may carry different risks than the enterprise edition with better data protections and clearer IP ownership.

My goal is always to enable the business as much as possible, given a risk level we are comfortable with. That also means deciding not just which AI tools to approve, but what classifications of data can be used with each tool. Some tools might be appropriate for customer data under the right contractual terms; others might be restricted to public data only. It is not always a binary yes or no — it is scoping the use case appropriately.

The most underrated component of all of this is training. If we are just running a request-and-approval process without helping people understand the reasoning behind our decisions and the actual risks involved, we are fighting an uphill battle. In addition to standard security awareness and data privacy training, organizations now need specific AI training — both on how to use these tools effectively and on what risks we are evaluating when we assess them. The best outcome is an employee who, before they even submit a request, goes to the vendor site, checks the privacy notice, reviews the security posture, and comes to us already informed. That is a big win.

Sheron Chakalakal: We treat AI risk as a data security problem at its core, because at the end of the day, what you are protecting is your data — your customer data, your crown jewels. So we go back to basics: what are the unknowns, what are the data security processes we already have, and how can we extend and adapt those for AI? Attack vectors are escalating and evolving rapidly, but if you anchor yourself in data security fundamentals — understanding all your ingress and egress points, knowing where data flows in and out of the organization — you can mature your data security program iteratively with AI governance as an extension of it.

It also concerns me at a personal level. I am having conversations with friends who are connecting personal finance apps to AI tools, building personal agents, and not thinking about the security implications at all. The risks are real at both the personal and organizational level, and if we are not approaching AI from a data security lens, we will always be in catch-up mode.

Christopher Donaldson: There is a really interesting psychological dissonance starting to occur. People who are forward-thinking technically — who know what they can do personally with AI at home — are experiencing real frustration when they come to work and have to do tasks manually that they have completely automated in their personal lives. That dissonance is very difficult for organizations to manage, and it is going to destroy morale for some technical teams if we do not find a way through it. I genuinely have not seen any company crack this fully yet.

The pace of change makes it even harder. You can invest significant effort in reviewing and enabling a tool — say, approving Cursor for your developers — only to have something like Claude Code come out the following week with better functionality. Now nobody wants the previous tool anymore. You are constantly on a hamster wheel trying to catch up. What I keep coming back to is the need for security and engineering teams to work more tightly together toward shared objectives, rather than continuing this bifurcated model where security sets requirements from a distance and engineering teams feel disconnected from the reasoning behind them.

Michael Waite: You touched on the agent supply chain as an emerging attack surface — new GitHub repos, new plug-ins being pulled down constantly, bypassing traditional code review. That is really interesting. And on the threat side, we are seeing things like prompt injection, where a jailbreak attempt embedded in an email could compromise an inbox managed by an AI agent. The threat landscape is evolving faster than I have ever seen it. How do each of you stay on top of the risks we are actually facing today?

Michael Carroll: Candidly, I think we are mostly reactive right now, and I think that is honest. With other aspects of information security, we have well-established best practices — we know relatively well how to secure a network, how to run a secure SDLC. With AI, we do not have that yet. Even the frameworks and regulations coming out feel more like "have you considered this?" than prescriptive guidance. We are handling things on a case-by-case basis as they surface. Hopefully, like everything else, best practices will emerge as the space matures.

Sheron Chakalakal: We look at attacks that are actually happening externally and ask: could that have happened to us, and what would have prevented it? We replay that question constantly and use it to mature our processes. A lot of these attack vectors are so new and creative that you would not think of them proactively — you learn from what you see in the wild. And it is not all doom. On the same timeline that new attack vectors are emerging, new companies are emerging to address them. There are tools now that sit in browsers, inspect prompts, and flag potential threats. There are tools that work alongside models to detect adversarial inputs. Keeping an eye on those startups and understanding where they fit into your AI governance story is valuable.

Christopher Donaldson: My focus recently has been on skills and plug-ins as an underappreciated attack vector. Developers are constantly pulling down new GitHub repos and plug-ins to add new capabilities, driven by how fast code planning, brainstorming, and iteration are evolving. Every new cutting-edge model that someone wants to build on comes with new dependencies, and all of that essentially bypasses traditional code review — it gets pulled down and runs as a cloud workload or locally. The AI agent supply chain is becoming a significant attack surface that I am not seeing enough people talk about yet, and it is surfacing more and more on my radar.

Michael Waite: We are just about at time. This has been a genuinely fascinating conversation — I am sure we should do this again in six months when the landscape has evolved even further. Sharon, Chris, and Mike: thank you so much for your time and insights. This has been a pleasure.