Stop Saying No: Why Security Leaders Should Enable AI With Data Governance, Not Block It

Why Security Leaders Keep Defaulting to No on AI

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 is exactly the position most CISOs find themselves in. Boards ask for an AI strategy. Sales teams pilot copilots without telling anyone. Engineering teams pipe production data into an LLM for a quick demo. The security function, asked late, often responds with the only safe default available: stop.

George Gerchow, CSO at Bedrock Data, named the pattern directly on The Security Podcast of Silicon Valley with host Jon McLachlan (co-founder of YSecurity and Cyberbase.ai).

"It's going to be just trying to set an example for a lot of my peers as to how to be more open minded, how to enable a lot of the technology that we're seeing today, how 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 not laziness. It is the rational response when a security leader has no visibility into the data the business is about to feed into a model. Without visibility, every yes is a guess. The fix is not more courage. The fix is the visibility itself, delivered through AI data governance.

The Wrong Question: 'How Are We Using AI?'

Gerchow's claim that the board is asking the wrong question is worth slowing down on. "How are we using AI" sounds like leadership. It is actually the question that creates the default-to-no problem.

The question assumes AI is a project to be deployed. It pushes the conversation toward demos, vendors, and tooling. It skips the prerequisite. Before any organization can answer "how are we using AI," it has to answer a more basic question. 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 cannot answer it. Pranava Adduri, Co-Founder and CTO of Bedrock Data, described what he saw at AWS: "AWS sees some of the largest customer environments in terms of data volumes. If I have 100 petabytes of data, what data do I back up. I can't back up everything. There has to be a risk-based approach."

The same logic now applies to AI. You cannot feed 100 petabytes of data into an AI program. You have to pick. The picking is the governance problem, not the technology problem. Security leaders who try to answer "how are we using AI" without first answering "what data do we have, classified how, owned by whom" are setting themselves up to say no by default for the next five years.

The right reframe is to push the AI conversation upstream into the data layer. The same scoping discipline that distinguishes winning AI adoption strategies from the 95 percent that fail also distinguishes confident security leaders from defensive ones.

Data-First Threat Modeling Beats Endpoint and Perimeter Thinking

A security program built on endpoint and perimeter controls cannot keep up with AI. The threat surface is the data itself, and the data crosses every endpoint and perimeter by design.

Gerchow framed the shift: "We've always tried endpoint, identity, perimeter, and all these things, when you said it at the beginning, John, it's about the data. So why not look at it from a data-first perspective. The volumes of data are going to continue to come all the time."

Data-first threat modeling starts with the asset and works outward, not the other way around. The questions look like this:

• What is the most sensitive data we hold.

• Where is it. Who is it shared with. What systems touch it.

• Which AI workloads consume it, directly or through pipelines.

• What is the blast radius if a model trained on it leaks part of it.

• What is the blast radius if an agent grounded on it answers the wrong user.

That last point matters because AI changes the agentic security model. An agent with broad data access is now a security boundary on its own, regardless of which endpoint it runs on. Endpoint controls do not prevent a misconfigured agent from exfiltrating data it was authorized to read. Only governance over the data itself does.

This is the same realization that drove the shift away from network perimeter dependencies for shift-left application security. The control point moved upstream because the perimeter could not hold. With AI, the control point moves further upstream still, into the data.

What AI Data Governance Looks Like in Practice

AI data governance is not a meeting. It is a working system that answers a small number of questions on demand:

• For any dataset, where did it come from, who owns it, what is it classified as, and what are we allowed to do with it.

• For any AI workload, which datasets feed it, at which stage (training, fine-tuning, grounding, evaluation, inference), and under which terms.

• For any user or agent interacting with that workload, which subset of the workload's data they are entitled to see.

• For any output the workload produces, whether the output is consistent with the entitlements of the requesting user.

When those questions are answered by a system rather than by a human chasing spreadsheets, the security function stops being the bottleneck. The business can propose a new AI workload, the governance layer can return a yes-no-with-conditions answer in minutes, and the conversation moves on.

The category Gartner now tracks for this is Data Security Posture Management, or DSPM, with an AI overlay layer. Bedrock Data and a handful of competitors sit in this space. The vendor choice matters less than the principle. The security function builds a working answer to the data questions above, and the answer is the precondition for every AI yes.

Governance That Enables: Visibility, Lineage, Entitlements

Three primitives turn governance from a brake into an enabler.

Visibility. A real inventory of every dataset, not a manually maintained spreadsheet. Discovery has to run continuously and catch shadow data stores, including the ones spun up by AI teams without security review.

Lineage. Where each dataset originated, what transformations it has undergone, and which downstream models and agents have consumed it. Without lineage, the security team cannot reason about blast radius after the fact.

Entitlements. Who is allowed to use each dataset, for what purpose, at what stage. Entitlements must reach down to model inference, not stop at the database table. The same logic that drives least-privilege design for AI agents applies to the data those agents touch.

Gerchow used a phrase that captures the posture shift: "Good brakes help you go faster." Visibility, lineage, and entitlements are the brakes. They let the business take the corners of AI adoption at speed instead of stopping at every junction to verify by hand.

The point is not that governance removes risk. It does not. The point is that governance puts the risk in front of the security team in a form they can decide on quickly, instead of in a form they can only respond to with no.

How to Reposition Security as an Enabler Without Losing Control

The reposition is real work. It is not a slide. A practitioner sequence that works:

1. Pick three AI workloads that are already live. Make them the test cases for the governance system. Avoid hypothetical use cases, which never apply pressure on the model.

2. Build the data inventory for those three. Source, sensitivity, lineage, entitlements, owner. Do this for the data they touch first, not for the entire data estate.

3. Replace the meeting with a query. Every yes-no decision the security team makes about those three workloads has to come from the governance system, not from group chat.

4. Publish the answer turnaround time. A 48-hour turnaround on AI data questions changes how the business plans. A two-week turnaround pushes the business to bypass security entirely.

5. Expand only after the three are in steady state. A governance system that covers three workloads fully is more useful than one that covers fifty workloads partially. The same scoping discipline that catches AI adoption failures applies here.

Adduri described the long-term posture Bedrock is building toward: "I see Bedrock as being this invisible layer that understands your data, that injects that context into every aspect of a business. If they have an existing security workflow, Bedrock's context should be injected there."

The invisible-layer framing is the right target for any in-house governance program too. The goal is not a security team that approves AI requests. The goal is a security layer that delivers the governance answer to the systems already making AI decisions, so the human approval is reserved for the unusual cases that actually need judgment.

That is what enabling looks like. The brakes are there. They just work fast enough to let the car go fast.

Listen to the Full Episode

In episode 95 of The Security Podcast of Silicon Valley, George Gerchow, CSO at Bedrock Data, and Pranava Adduri, Co-Founder and CTO at Bedrock Data, walk through the shift from blocker to enabler. Gerchow brings a decade-plus of CSO and CISO experience from Sumo Logic, MongoDB, and VMware. Adduri brings the AWS perspective on what the largest data environments on the planet actually look like.

The conversation covers the say-yes mindset, the data-first threat model, the AI data governance primitives, and the specific patterns Bedrock Data uses with customers to make the brakes fast enough to enable speed.

For any security leader thinking about how to lead through the AI wave instead of getting steamrolled by it, this episode is worth a full listen.