Stop Saying No: Enable AI With Data Governance, Not a Blanket Block

The fastest way to lose influence as a security leader is to be the person who says no every time the business proposes a new AI use case. Yet that’s where most CISOs find themselves. Boards ask for an AI strategy. Sales pilots copilots without telling anyone. Engineering pipes production data into an LLM for a quick demo. Security, asked late, responds with the only safe default available: stop.

George Gerchow, chief security officer at Bedrock Data, named the pattern on episode 95: the job now is “to enable a lot of the technology that we’re seeing today, to have the gumption to stand up to the board when the board is saying, how are we using AI, which is the wrong question.”

The default-to-no posture is neither laziness nor cowardice. It is the rational response of a leader who has no visibility into the data the business is about to feed into a model. Without visibility, every yes is a guess, and a security leader who guesses wrong owns the breach. The fix is the visibility itself, delivered through AI data governance. This post is about how a security leader gets there, and why the CTO who is the de facto security leader at most Series A companies should care just as much.

Why do security teams default to no on AI?

Three reasons, and none of them is a character flaw.

First, timing. Security is usually the last to hear about an AI pilot and the first to be asked to sign off on it. When the request arrives after the data is already flowing, the honest answers are “no” or “give me two weeks,” and both feel like obstruction to the team that asked.

Second, blindness. Pranava Adduri, Bedrock Data’s co-founder and CTO, stated the prerequisite plainly: “you can’t have AI without data. That’s kind of the foundational mantra.” To compete with AI, he said, “you need to first have an understanding of what data can you use to enable that.” Most companies cannot describe their data at that level, so the person asked to approve an AI workload is approving something whose inputs nobody has inventoried. “No” is the only answer that can’t be wrong. His conclusion: “when we think about it from a security lens, now more than ever, being the office of no does not work.”

Third, personal risk. George’s hardest days at Bedrock came early, pitching traditional CISOs on what the company had found in their environments:

“You show them a problem and they’re like, I don’t want to see that problem. No one’s asking me about that problem. So we put all this time and effort into illuminating, hey, this is a real issue with the way the data is moving, and especially in AWS environments, when we find sensitive data in lower environments. My expectation was that they would be like, I’m solving this problem. I’m so glad I know, now I’m going to go get it. And in the very beginning, my eyes were opened a little bit. Some people just want to [say], I saw that, but no one’s asking me for it, so therefore I’m not going to take any action.”

George Gerchow, chief security officer of Bedrock Data, on episode 95

He went on to wonder whether the legal pressure on the role, and he named the Joe Sullivan case, has changed its ethics: “is it getting to a point now where the CISO is trying to reduce their own risk as much as the company’s risk, if not more?” The pressure is concrete. Uber’s former chief security officer was convicted in federal court in October 2022 of obstruction and misprision of felony for concealing a 2016 breach, and every CISO in the country read that verdict as a note to self.

A leader who can be held personally accountable for what the company does with its data, and who cannot see that data, will say no. That is the structural reason behind the office of no, and it is good news, because structures can be redesigned. Here is the same request handled two ways.

”How are we using AI?” is the wrong question

“How are we using AI” sounds like leadership. It’s actually the question that creates the default-to-no problem, because it assumes AI is a project to deploy and skips the prerequisite: what data do we have, who owns it, what is it classified as, and what are we contractually allowed to do with it?

That question is uncomfortable because most enterprises can’t answer it. Pranava described the version he saw at AWS, where customers wanted a zero-ransomware strategy and were told to back up their most sensitive data: “If I have 100 petabytes of data, what data do I back up? I can’t back up everything. So there has to be a risk-based approach to doing this.” The same logic now applies to AI. You can’t feed 100 petabytes into an AI program; you have to pick, and the picking is a governance problem before it is a technology problem.

George’s answer to who does the picking belongs on the wall of every security team: “Who really owns the data? It is not the CISO that owns the data. It is the business that owns the data. And the business needs that data to be able to make predictive decisions and drive innovation for customers to be able to leverage products better.” Security’s job is stewardship: knowing what’s there, what it’s worth, and what’s allowed, so the owner can move.

For a startup the reframe is even more useful, because you have less data and fewer people, so the inventory is a week of work rather than a quarter. It is the same scoping discipline that separates AI projects that ship from the ones that quietly stall, and it is the first item on the AI readiness check we recommend before anyone signs an agent vendor’s contract.

Should the CISO report to the CTO?

George has watched the reporting line move twice in his career, first at VMware, then through security leadership at Sumo Logic and MongoDB before joining Bedrock Data as CSO in 2025:

“All my years at VMware and technical companies like that, there was this thing that was going on where CISOs sort of reported into a corporate infrastructure, and they had always had a lot of friction with engineering. And then when cloud started coming out, engineers really started doing most of the security. They were like, [get] out of my stuff. And then CISOs were like, no, no, no, slow down cloud, slow all these things down. And then IT’s footprint was reduced. But AI has brought a different mechanism to this whole ball game now, because of the amount of data and because engineers are trying to move fast. I’m seeing a shift to where progressive CISOs are now starting to report to the CTO.”

George Gerchow, chief security officer of Bedrock Data, on episode 95

What that does, in his words, is give the CTO “the responsibility of, I got to move fast, but I also have to be secure,” and it demands “a progressive CISO too, who’s AI ready,” one who asks “how can we get this done and provide the proper guardrails instead of saying no and blocking all this.” His conclusion: “we have to, as security people, get out of this traditional bucket that we’ve been in and start thinking like engineers.” Jon went one step further on the episode: think like product people, and ask how security can supercharge the business into the future of AI. Either way, the security leader’s customer is the person shipping.

Yash Kosaraju, the CISO of a16z, runs his team on the same rule and gave Jon the reason on episode 104. A no leads to two things: “they’ll never come back to you,” and “they’ll find a way to use it anyway.” So his team works out what the person is trying to do and defines access to the right set of data for that use case, and a proof of concept gets a subset of test data. Jon wrote up the rest of that conversation, including why the approve button on AI agents is going away, in The Human in the Loop Is Going Away.

The data backs the direction of travel, if not the exact destination. Heidrick & Struggles’ 2025 Global CISO Compensation Survey, an executive-search firm’s survey of 371 CISOs in the United States and Europe, found 42% reporting directly to the CEO, three times the share a year earlier, while the share reporting into a CIO or CTO fell from roughly half to 30%. Security is leaving the IT basement either way. At an engineering-led company the natural landing spot is the CTO, which is George’s point; at a Series A startup the CTO usually is the security leader, which makes the org chart moot and the posture the whole game.

George lives the arrangement himself: “I’m kind of his customer in a lot of ways,” he said of Pranava. A security leader treated as the internal customer of the engineering org, rather than its inspector, shapes what gets built instead of vetoing it afterward. Deciding who should hold that seat at your company, and whether to hire or rent them, is the question we wrote up in In-House, On-Demand, or YOLO?

What is data-first threat modeling?

A program built on endpoint and perimeter controls can’t keep up with AI, because the threat surface is the data itself and it crosses every endpoint by design. George, who ran security at two very data-driven companies (Sumo Logic and MongoDB) before Bedrock, put it in one line: “We’ve always tried endpoint, identity, perimeter and all these things… it’s about the data. So why not look at it from a data-first perspective?”

Data-first threat modeling starts with the asset and works outward. Four questions, in order:

1. Asset. What is the most sensitive data we hold? Customer records, source code, contracts, PII, credentials. Rank it. You cannot protect 100 petabytes equally, and you don’t need to.
2. Location. Where does it live, including the copies? George’s cradle-to-grave point: “how does it move and what are the copies and does it still have the same entitlements to it?” Lower environments are where Bedrock keeps finding production data.
3. Consumers. Which AI workloads read it, on whose credentials? Pranava sees “all variants of this”: copilots connected “to all their SaaS repositories,” in-house agents built on historical data, and teams training their own models.
4. Blast radius. If the model or agent leaks part of it, how far does it go and who is harmed? An agent with broad data access is a security boundary on its own. Endpoint controls don’t prevent a misconfigured agent from exfiltrating data it was authorized to read; only governance over the data, and least privilege on the agent, do.

That fourth question is where lineage and entitlements earn their keep, and where the AI data bill of materials we wrote up from the same episode comes in: a DBOM answers “what went into this model” the way an SBOM answers “what went into this binary.” This post stays on the leadership side of that line; the DBOM post has the mechanics. It’s the same realization that moved the control point upstream in shift-left application security. With AI it moves further still, into the data.

What does “good brakes help you go faster” mean for AI guardrails?

The phrase is Pranava’s, and it is the best one-line summary of the enabler posture we have heard:

“Having that visibility, it’s the foundation for being able to then build the right guardrails. I like to think about this adage: good brakes help you go faster. A lot of the conversations that we have now take on a similar tune to, we are rolling out AI, we want to use it to be competitive, but we don’t know what data is going in. And as a result, we can’t control necessarily what’s coming out. And so usually the conversation then evolves to, can you please help me understand what AI I have at play? What have I deployed? Give me visibility into that. And then can you help me understand what data I’m sending to it?”

Pranava Adduri, co-founder and CTO of Bedrock Data, on episode 95

Brakes are what let a driver take the corner at speed. Applied to AI, the guardrail ladder has four rungs, and each one converts a class of “no” into a class of “yes.” The objective, in Pranava’s words, is “how do you give people the right guardrails to run faster.”

1. Visibility. An inventory of the AI workloads in play and the data feeding each one, including the shadow stores AI teams spin up without review. This rung turns guesses into answers.
2. Classification. For each dataset: an owner, a sensitivity tier (public, internal, restricted is plenty), and the contract terms attached to it. This is what makes “yes, with conditions” possible, because the conditions are now written down.
3. Policy at the point of use. Guardrails where the work happens: the browser warns before a customer table lands in a personal chatbot, the IDE strips a key before it leaves the laptop, the gateway redacts before the prompt reaches the model. Pranava’s framing is to give builders “the scaffolding and guardrails to allow them to catch themselves in the one or two off chances that something risky is about to happen.” This rung makes the yes fast. The browser half is in Enterprise Browser Security, the people half in Shadow AI.
4. Monitoring. Lineage, drift, new tools appearing weekly, entitlements re-checked as models and agents change. Pranava’s vision for this rung is a layer that keeps up “at the speed of machine, not at the speed of human,” because what he calls the data echo chamber (data goes into AI, prompts produce new data, that data feeds back in) outruns any review meeting.

George’s example of what rung three catches is worth keeping in your pocket for the next board meeting: a manager of fifty people who “all of a sudden starts putting all of their reviews or comments inside of ChatGPT and then says, okay, spit something out that helps me give a yearly review on this person. You laugh, but is it happening out there and do we know that it’s happening?” Without rung one you cannot answer the second question. Without rung three, the answer to the first is always yes.

None of this is exotic paperwork. The four rungs map onto the Govern, Map, Measure and Manage functions of the NIST AI Risk Management Framework, the voluntary framework NIST released in January 2023 and extended with a Generative AI Profile in July 2024, and onto the management-system requirements of ISO/IEC 42001, published in December 2023 for any organization that develops, provides or uses AI. When a customer’s security team asks how you govern AI, a ladder you actually climbed is the answer, and an ISO 42001 program certifies it once instead of re-explaining it per questionnaire. If you train on customer data, rung two is also where training-data scrubbing starts.

How do you reposition security as an enabler? A 90-day plan

The reposition is real work, not a slide. Here is the sequence we run with clients, expanded with what Pranava and George described:

1. Pick three live AI workloads as the test cases. Hypotheticals never apply pressure. Pranava learned the value of forced focus the weekend Silicon Valley Bank failed, when he and his co-founder planned for four levels of “what if we only get this much back.” The half-the-money plan, he said, “was the plan we should be executing all along anyway, because it was a much more focused plan. It forced us to really cut out a lot of projects that weren’t on the critical path.” Three workloads is your half-the-money plan.
2. Build the data inventory for those three. Source, sensitivity, lineage, entitlements, owner. For a startup this is days rather than months: a shadow AI detection pass puts the AI tools and the accounts behind them on one page, and an AI access-control audit tells you which of those tools can reach which data.
3. Replace the meeting with a query. Every yes/no decision comes from the governance system (at first, a spreadsheet plus a named owner is fine), never from group chat. The test is that the same request gets the same answer twice.
4. Publish the turnaround time. A 48-hour answer changes how the business plans; a two-week answer teaches them to route around you. Put the clock in the request form and report against it.
5. Expand only after the three are in steady state. Then add the next three. A couple of quarters in, you have what George described feeling for the first time in his career: “When you have this ability for data, know the lineage, the entitlements of that data, how it works, what’s sensitive, what’s not. It’s just a very powerful, comforting feeling.”

Done well, security becomes the layer that makes bigger, security-conscious deals closeable rather than the reason they stall, the same way turning security into a sales asset wins the stickier customers. The brakes are there. They just work fast enough to let the car go fast.

The decision: who gets to say yes at your company

If you run security at a startup, or you’re the CTO who does by default, the question in front of you is smaller than “should we allow AI?” Your team already uses it. The question is whether the next request gets a guess or an answer, and that comes down to whether rungs one and two exist before the request arrives. Pranava’s summary of the objective is the one to write on the whiteboard: “How do I enable the business? Not how do I say no.”

The fastest first step is the inventory. A shadow AI detection engagement puts every AI tool in use, the accounts behind them, and the data flowing to each on one page in a few weeks. That is rungs one and two of the ladder, and the whole difference between the two columns in the first figure. If you’d rather hear the argument from the two people who built a company on it, Pranava and George make it in 38 minutes on episode 95.