CISO AI Governance: Lessons from Millennium ’s CISO Assembly
The AI Governance Problem Is Mostly a Basics Problem
At our Transformational CISO Assembly in Atlanta on October 7, a keynote speaker asked the room a simple question. Who here is fully confident they know every AI and SaaS tool running in their environment?
One hand went up.
That moment set up the next two days. Under every session was the same pressure. AI is moving faster than anyone’s plan for it, and security leaders are being asked to steer through change they can’t fully size up yet. CISOs don’t like being in that spot.
On Day 2, the keynote panel “Velocity vs. Vulnerability,” moderated by Dr. Dave Chatterjee, Adjunct Associate Professor at Duke University, brought together security leaders from financial services, state government, federal research and national security policy. A Day 1 fireside chat with ADT’s Deputy CISO added the operator’s view. The panel’s answer wasn’t to start over. It was to update the playbook, beginning with the basics AI is putting under stress.
The short list
- Set your risk appetite first. The business moves faster when it knows where the guardrails are.
- Fix the basics. AI speeds up whatever’s already weak in asset inventory, data governance and identity.
- Go find the shadow AI. Unapproved MCP servers can be running before a governance committee ever hears about them.
- Write down who owns what. That means who owns the risk, who’s accountable and who can take systems offline.
- Widen your tabletops. Bring in legal, communications, executives and third-party scenarios.
What delegates told us before they arrived
Before each Assembly, we collect a short needs assessment from registered delegates, including the objectives their department is working on. We reviewed the responses for Atlanta. About 90 delegates took part, more than eight in ten held security titles, and just over half were C-suite.
AI topped the list, and most of those mentions were about governance, risk or security. Only about three in ten framed it purely as adoption or automation. Here’s how the rest stacked up.
| What delegates named as an objective | How often |
| AI | About seven in ten |
| Compliance and program maturity | About three in ten |
| Identity and access | About three in ten |
| Consolidation and modernization, led by cloud and infrastructure migration | About one in five |
| Detection and response, data security, network and OT, exposure management, application security | Each about one in ten to one in seven |
This is what delegates said going in, not what was discussed in the room. Still, the pairing is worth noticing. They arrived focused on AI governance, with identity and compliance close behind. On stage, the answers kept coming back to inventory, ownership and identity.
1. Security done well makes the business faster
Eric Boateng, Chief Information Security Officer and Head of Enterprise Cyber Security at MassMutual, opened the panel by flipping the usual question.
“The question is how much security risk are we prepared to take while we try to innovate with AI.”
Set that appetite, he said, build the guardrails, and teams can move inside them. “We speed in our cars because we have brakes. That is risk management.” Quinton Jones, Information System Security Officer at the National Institutes of Health, took the analogy further. Without brakes, “our maximum speed we would ever safely be able to go is maybe five, possibly 10 miles an hour.”
Exceptions work the same way. When the business needs to go outside the guardrails, Eric said, it “has to be well documented. It has to be time bound with compensating controls.” Senior management decides who owns it, somebody monitors it and a mitigation plan follows. The answer to a product team is never a flat no. It’s yes, within these limits, and here’s the paper trail.
He also tightens his own scoreboard. “If I am green on metrics, I go back and tighten the thresholds because green metrics is bad, by the way.” The thresholds come from a year of his team’s vulnerability and patching data.
Later in the day, Eric accepted The Millennium Alliance CISO Distinguished Collaborative Leadership Award at lunch. His parting words to the room were the same idea: “if security is done right it’s going to enable speed.”
2. AI is an accelerant, and the fuel is your existing mess
Daniel Langley, CISO at the State of Oklahoma, didn’t hedge.
“We don’t truly have to rewrite the book with controls and how policies and governance and how we do things. It’s just adding another layer to it. It’s not a change completely. It’s an add-on.”
What that layer needs underneath it, he said, is to “truly get down to the basics on some aspects, like truly understanding your asset management, understanding what your environment is like, what is out there.”
Rick DeLoach, Deputy CISO and Senior Director at ADT, landed in the same place: “AI is an accelerant.” Dr. Georgianna Shea, Chief Technologist of the Transformative Cyber Innovation Lab at the Foundation for Defense of Democracies (FDD), said organizations are still getting hurt by “the low hanging fruit that we’re getting tripped up on.” Add AI as a force multiplier and those hygiene problems get worse.
Eric tied it to data: “If you have poor data governance, you’re going to have bad AI governance because it feeds with each other.” He expects agentic AI to be the big one. “In the next couple of years, agentic risk will be the number one risk that we have, because you have tons of these agents talking to each other.” His starting point is inventory. How many agents do you have, who owns them and what are they doing? An agent can have a valid identity and still misbehave. “They could be the right identity, but might be behaving the way it was not intended to do.”
Georgianna added two cautions.
- Risk registers. Likelihood scores often lean on whether something has happened before, and speed changes that. “All of these fundamental assumptions that we’ve been taking for granted and working off of really need to be reexamined.”
- Compliance. “You can be compliant but not be secure.” In her reading, the NIST controls used in assessments don’t test AI. They look at the confidentiality, integrity and availability of data, not whether you can trust it. On cryptography, the control “just says, do you have a crypto program?” Check the box and move on.
For a CISO, the AI program and the basics program are the same program. An agent inventory is an asset inventory. Agent permissions are an identity problem.
3. You can’t govern what you haven’t found
Rick shared a story from ADT’s weekly AI governance committee. His team raised MCP servers. The committee’s answer: “we don’t have any MCP servers because we haven’t approved any.” So his team pulled data from their own tools and showed them. A fair number were already in the environment.
His point was about the operating model, not the people. Threat actors don’t wait for change control boards, and “governance councils, those are, you know, old operating models and we need to move at speed.” If your review process depends on requests arriving through the front door, it misses everything that came in another way.
Oklahoma goes after the same problem from the network side. Daniel described it this way: “Anytime AI is used in the state of Oklahoma, we actually get an alert. We get the prompt and response, and if they try to upload a document, we actually capture that document at the same time.” It isn’t a gotcha, he made clear. The goal is to see what’s happening so the state can respond at the speed things now move.
Back to the one hand in the Day 1 room. The first job of an AI governance program is finding things. Policy comes after.
4. Decide who owns it before the incident starts
The panel was built around three ideas from Dr. Chatterjee’s framework: commitment, preparedness and discipline. Under commitment, the first question was who owns the risk. The answers were sharper than “the CISO.”
Daniel split apart two things leaders tend to blur: “there’s a difference between owning and who’s actually accountable.” Everyone who touches a system owns some of its risk, he said, but accountability sits with someone specific. At the State of Oklahoma, that’s typically him or the CIO. Eric described the financial services version. System owners decide within the risk appetite, and anything past tolerance escalates through risk committees, up to the board.
An attendee asked what happens when a data risk owner leaves and nobody wants the job. Eric reframed it: “We don’t have a data risk issue. We have a resiliency issue.” His fix is a named co-owner for every critical inventory item. “There’s always going to be a co-owner, someone who is equally knowledgeable and have the seniority to make some decisions.”
Authority gets the same treatment. Rick said ADT’s incident response plan spells out, with executive sign-off, “that we have the authority to take systems offline if there’s deemed to be a threat in the environment.” The reason is simple.
“So we don’t get into an incident bridge, and we’re trying to figure out who has the authority to do what. Like if you’re trying to do that, it’s already too late.”
Georgianna was blunt about resilience: “if you’re planning on just protecting the system, you’re going to fail.” She starts from the mission, maps the critical functions behind it and the technology that supports them, and works out the minimum service the organization has to keep running through an attack.
5. Rehearse with everyone in the room
Daniel’s test for a backup plan: “if you say you have a full live backup system, but you’ve never tested it, you have theoretically a backup system.”
Eric described how far MassMutual takes rehearsal. His teams run third-party compromise tabletops and zero-day tabletops, plus a combined scenario where a third-party compromise arrives through a zero-day. There are executive-level sessions with the CEO in the room. The biggest problem in a tabletop, he said, is communication: “who to talk to, at what point, who do we inform.”
An attendee whose company serves the banking sector told the room what happens when you widen the exercise. Their insurer facilitated a tabletop that brought in the CEO and the legal team, and added a scenario the team hadn’t planned for, in which “all of our credentials got exposed to the internet.” One panelist’s reply: “If you have not involved every aspect of it in those planning sessions, you haven’t done it.”
Four checks to run this month
- Risk appetite. Is it written down, with a documented, time-bound path for exceptions? If product teams can’t see the guardrails, they’ll build around them.
- AI inventory. Does it come from your own tool data or from intake forms? The MCP story suggests the two can differ.
- Ownership. Does every critical risk have a named owner and a named co-owner? Does your incident plan say, with sign-off, who can take systems offline?
- Next tabletop. Is it built around a third-party compromise, with legal, communications and executives at the table?
The questions above didn’t stay on the stage. Who owns the risk and who’s accountable came up again in the workshops and roundtables, and the room didn’t always agree. Delegates drew the line in different places, and the answers shifted with the size of the organization and the industry. Nobody needed to settle it. Hearing how a peer in another sector or at a different scale handled the same question kept the conversation going, and gave people something to compare against their own setup.
That’s a big part of why delegates came. They wanted to hear how peers were handling it, and to know they weren’t facing it alone. They also wanted to see the new solutions showing up almost daily, so they could tackle a problem or just stay on top of what’s new.
That conversation picks up again at our Transformational CISO Assembly, December 1 and 2 at The InterContinental in New Orleans. The agenda includes sessions on streamlining enterprise AI intake and review, how peers define data-access tiers and real-time circuit breakers for autonomous agents, and modernizing incident response for cloud and AI breaches. Details are at mill-all.com.
