Rich Isenberg is one of my favorite colleagues and I deeply enjoyed our discussion on what makes a great CISO, what the cybersecurity organization should look like, how CIOs should engage on cybersecurity, how to secure AI and how to use AI for security.
Click the video above or listen to the audio-only podcast.
Here’s what I heard:
You have to scale AI governance. Rich points out many companies moving too quickly (taking on risk they don’t understand) and too slowly (missing market opportunities). “Autonomy without governance is not innovation; it’s negligence,” he says -- but also that workflows scale, while committees do not.
Securing AI will require experimentation. Rich and I talked about emerging techniques for security: using GenAI to accelerate security reviews, having agents create deterministic code at run-time that you can scan. Neither of these is a panacea. GenAI-enabled adherence review requires well-formulated standards. Scanning code at run-time can introduce latency in some workflows. There are no schoolbook solutions yet.
The idea CISO advises, so business leaders can decide. CISOs aren’t there to eliminate risk, or even necessarily to reduce it. Just as there are no financial returns without market risk, there is no technology value without technology risk. Great CISOs provide business leaders with the facts (and advice) that allows them to take intelligent risks. Rich argues that when companies adopt this mindset, they won’t need large security teams. The CISO will focus on building and applying coherent risk management processes. The rest of the organization will build and consume the required platforms.
Early thoughts
I love seeing different organizations and technology environments every week -- how they work (or not), where they might go, how they evolve. I’ve included a few reflections below on what I’m seeing that I haven’t fleshed out yet into an article. Think of this as the assignment deck for myself.
Governance will be a killer application for GenAI
We all devote more time and effort to governance than we did a couple of decades ago. Some of this results from increased corporate scale and complexity. Some from a better appreciation of the risks and a more risk-averse culture. Some from more regulatory mandates. Sarbanes-Oxley, know-your-customer, anti-money laundering, tech architecture, cybersecurity, procurement and privacy governance are all essential, but all require massive efforts from the governors and governed.
GenAI is bad at many things, but wonderful at making comparisons. Automating the comparison of artifacts with standards (possibly encoded in a knowledge graph) reduces the governance tax, rips wait time out of important processes -- all while improving policy adherence.
Don’t always communicate top down
In communicating everyone (I hope) tells you “BLUF: bottom line up front” and “Show, don’t tell.” This is good advice.
The Pyramid Principle by Barbara Minto reconciles these imperatives. You tell the reader or listener the bottom line and then you show the evidence for it -- this is a broadly applicable and stunningly effective communications patterns.
Yet, in some circumstances up front isn’t help. Bottom-line conclusions -- “it works,” “we’re on track,” “we’re done” -- are subjective syntheses of underlying facts. So, in some cases, you and the listener may disagree of synthesis more than the underlying facts.
In which case, you may consider a different communication pattern. Instead of saying “we’re on track,” start with “here’s where we are” -- and invite the listener to problem solve you on whether that means “on track” or not.
Rich Isenberg and I talk about what makes a great CISO below. CISOs must enlist facts to create alignment on synthesis. Even if everyone agrees on which data is encrypted, what does that mean in terms of aggregate level of risk? Is some variance to standard an unavoidable reality or an emergency that the leadership team must address.
Great CISOs, for example, evaluate the clarity of the facts, the political correlation of forces and their personal credibility to determine when to say “we must fix this now” and when to lead with “here are the facts -- let’s problem solve on what to do about it.”
The Interview: Cybersecurity leader Rich Isenberg
On the go? You can also listen to this in the car or on the elliptical via Spotify
James Kaplan: Welcome to another Prosaic Times podcast. I’m thrilled to have my colleague, Rich Isenberg, joining us this evening. I’ve wanted to do a podcast with Rich since I first got the idea that we should do podcasts for prosaic times. Rich, could you introduce yourself and tell us a little bit about your background and your journey from Connecticut to Atlanta to Capital One and SunTrust.
From computer camp to cloud security
Rich Isenberg: Wow, you’re making me feel old having to recount all
James Kaplan: Rich, just to be clear, we are old.
Rich Isenberg: That’s a fair point.
James Kaplan: Do you remember five-and-a-quarter-inch floppy disks?
Rich Isenberg: I do
James Kaplan: You are old my friend. Old.
Rich Isenberg: I had an Apple IIe and then an Apple IIc, and then a Mac. Always Apple, though.
James Kaplan: My very first computer was a VIC-20 with a tape drive, with 5K of RAM. And I think I got a C on a paper in seventh grade because I got an A on content, F for handwriting.
So, which averaged out to a C, so I wrote a word processor in Commodore BASIC so I wouldn’t have to write my English papers more clearly.
Rich Isenberg: Going to computer camp as a kid and learning how to, I think I grew up in Connecticut in the Hartford area,
James Kaplan: yeah, New Jersey. We didn’t have computer camp that was purely a Connecticut thing.
Rich Isenberg: Commodore 64s and oddly enough as you’re saying it, I still remember the programming. I learned BASIC programming to make my name scroll across the screen diagonally.
James Kaplan: I had a VIC-20, which I had inherited from my uncle, and then he replaced the Commodore 64 with an Apple, so I inherited the Commodore 64 and I was very excited because it came with a 1541 disk drive, which was the size of a shoebox.
It made terrible noises. But the neat thing about Commodore BASIC is the memory map was on page three of the manual. So at the age of 12, I was oh gee, if I want to do anything cool, I’m gonna have to write, learn how to read and write directly to video memory, using PEEK and POKE commands, the things that kids don’t learn today.
We should actually talk about cybersecurity or something that.
Rich Isenberg: Do you remember the first video game you played on the first computers you owned? What was the first game that somebody gave you?
James Kaplan: I remember writing two, the first of which was, a little thing where you, wandered around the dungeon and, tried to avoid monsters.
And I remember watching my brother and a friend of mine play it, and that was very satisfying. In seventh grade I wrote a program to keep track of baseball statistics for the science fair. And I realized that was sort of boring.
So I wrote a, program that you had to navigate some entity around the screen, without bumping into other things. Everyone came and played.
Tell us a little bit about your story then. We should actually talk about something relevant to what we’re supposed to be talking about.
Rich Isenberg: Alright, so, Rich Isenberg. If I were introducing myself to clients, I’d say I’m a partner with McKinsey in the Atlanta office. Been here for six years, work on interesting things and tinker with stuff. I grew up in Connecticut in the Hartford area. Went to college in...
James Kaplan: Was a big Hartford Whalers fan.
Rich Isenberg: I was a big Hartford Whalers fan. As you can see with Sherman the Otter wearing his
James Kaplan: Yep.
Rich Isenberg: jersey. Always on my desk.
Ended up working for Panasonic, leading the network division of their research and development in the United States, when the first SQL Slammer worm came out.
There really were no information security professionals outside of government. The internet was fairly new — mostly advertising and stuff like that. We weren’t really transacting. But as the network manager, I had to figure out how to play cat and mouse with the bad guys and shut this stuff down.
When I left Panasonic, I met the guy who invented online bill pay. He had a company called CheckFree in Atlanta, Georgia. I spent the next decade there figuring out things like remote deposit capture — things people take for granted today. How do you securely transact financial transactions over the open internet instead of private lines?
I continued to learn. Eventually, I joined Capital One, running cybersecurity operations and figuring out how to take a regulated bank to public cloud.
I came back home from DC to Atlanta and took over the chief information security officer role at SunTrust, my hometown bank, which was really fun. They merged with BB&T to become Truist. And I joined the firm as a direct-hire partner the day before we closed it down for COVID.
What makes a great CISO?
James Kaplan: Alright, I remember that. So you get the opportunity to interact with a bunch of different technology organizations, a bunch of different cybersecurity organizations. You get to interact with a whole bunch of different CISOs. What in your thinking makes for a good CISO versus a not so good CISO, and what makes for a great CISO.
Rich Isenberg: That’s an interesting question. I think if you go back 20 years, CISOs came from a non-technical, audit-heavy background and always got a reputation as the draconian Dr. No — those are not good CISOs.
After that it became clear that CISOs who understood the business started to make great CISOs. If you don’t understand what the business is trying to accomplish, you can’t possibly understand how to enable it securely and how to advise business leaders on risk trade-offs. I still think this is true today.
Oftentimes, I’ll quiz CISOs: tell me about your products. Tell me about your customers. How do they interact with your systems? Surprisingly, a lot of them don’t know the answers, nor do their teams.
I tell CISOs when I counsel them as they take new roles that at least 30% of your time should be spent up and out with the business, understanding the business, talking to business leaders, understanding the revenue streams. That’s the way you’re gonna be able to help prioritize and really help the business build value.
James Kaplan: I push that even a little bit further. Certainly in, in B2B markets, CISOs spend time with customers. And some of the best CISOs I know, have to fight off demands from the channel and from the sales force to go meet with this customer and that customer and the other customers.
What, what’s your thoughts on that, or what’s your reflection?
Rich Isenberg: I think that’s valuable. I also find that sometimes it can be distracting because customers want you to provide comfort, security, and safety as a feeling. And sometimes that distracts from the work of actually creating safety and comfort within the products.
It’s like any other CISO role — you have to balance the stresses on your time. I’ve even seen some B2B product companies create a separate role for customer-facing CISO versus CISOs accountable for responding to incidents. I think that’s a healthy move.
James Kaplan: Another term you could use for feeling of security is trust. And you could argue a lot of, a lot of what. Some CSOs do is spend, is spending time building trust with markets, which we could describe as a function of being secure and people perceiving, the security as existing.
And so it has to be both things.
Rich Isenberg: I agree. And when markets are concerned, oftentimes perception is reality
James Kaplan: The distinction between B2B and B2C markets for cybersecurity is fascinating to me. Many consumers are a little bit cheap and cheerful in terms of security, excluding high net worth and mass affluent in banking.
But oh my god, B2B customers care about it. If you’re doing group health insurance or prime services, there’s real pressure from the customer base around security.
Rich Isenberg: Absolutely. And the pressure’s building. A lot of businesses are getting smarter in their contracting demands around security in the B2B market. That’s put a ton of pressure on being able to even submit a bid. You have to prove the security features and that you can meet their standards.
And I think that’s fairly new — and increasingly specific.
James Kaplan: And it goes to your point about understanding the business. Because if you are being asked as a ciso, can we underwrite this risk or can we warranty this degree of protection — that is a fascinating business technology problem. You need to understand the business, and quite frankly, to your point, earlier point, you need to understand the technology,
Rich Isenberg: A hundred percent, and I would even push it a little further and say that the ideal CISO doesn’t make these decisions. They advise, and the business makes the risk decision, but the CISO has to present them in business language, to your point, to be able to actually determine what are the chances we could underwrite this risk if X thing happens.
James Kaplan: Jim Routh, who is the CSO of a, a number of companies, I probably won’t even list them, was, fond of saying that, He wasn’t in the business of eliminating risk. He wasn’t even in the business of reducing risk. He was in the business of allowing the business to make intelligent, take intelligent risks, that enabled them to do certain things from a business perspective or market perspective.
Rich Isenberg: 100% agree with that. The only way to eliminate all the risk is to unplug the computers and send everybody home.
Nobody gets paid, and that’s ridiculous, right? So you do have to think in that manner. I would also push it to say that if this were perfect and you finally had the perfect organization, right, the CISO wouldn’t even have a team.
It would be an individual contributor because I think these large CISO teams have become a crutch. If you asked the business who’s responsible and accountable for security, they have a 500-person team with a billion dollar budget to point at.
I think the more mature model for a CISO to push is that security is everybody’s job and everybody’s business and everybody is accountable. They are more in charge of ensuring the right things get prioritized and the right things get done. But if you really build that culture, you don’t need a team of 500 people because it’s baked into the business processes already.
What should the cybersecurity organization look like?
James Kaplan: Well, this is a really interesting question and which opens the door to a bunch of other. Interesting questions. You could say at some level, the CSO role, at least in many places, is a bundle of two functions. There’s a risk management function, right, which is Jim Routh’s point, helping the business, business leaders to understand which risks, right?
And there’s a service delivery function. There’s a number of things. soc, incident response, DLP, often identity often, but not always. Identity and access management, which are typically put underneath the ciso, right? Should the CISO organization be purely a risk management organization, or should it have all these technology delivery responsibilities?
I tend to favor putting them together because it makes the CISO’s role more real, but others have a different point of view. Where do you, where do you land?
Rich Isenberg: I think it goes back to reality versus a hypothesized ideal future. Having done the role and been in the C-suite at very large organizations, the ability to execute delivery and get things done is important because it helps you carry the mandate.
But if you could truly have an ideal security culture driven from the top down, there is this hope that you could turn it into more of a risk management function. Maybe a lot of the agentic AI capabilities are part of what may unlock this. But I don’t think anyone’s there right now.
I am a fan of combining it right now. What I always advocate is that every CISO needs solid engineering — not infrastructure engineering, but full-stack developers integrating with APIs and actually building security as a service.
The most effective CISO teams have a large part of that function today.
James Kaplan: Even if the CISO has a lot of delivery, a lot of what you need to be secure happens outside the CISO’s office. The security team doesn’t patch the servers. It doesn’t write secure code. Is that something you agree with?
Rich Isenberg: I do. When people ask me about vulnerability management, which generally sits under the CISO team, I point out that the CISO generally doesn’t own asset management. They don’t patch the servers, they don’t write the code.
But these vulnerability management programs and testing programs are simply grading the effectiveness of the IT management processes. A vulnerability management scan is showing you how effective your policies and processes on patch management and software lifecycle management are.
The CISO doesn’t own what creates this, but they’re using these programs to get the information to determine how effective they are.
James Kaplan: Where do you stand on CSO versus Chief Technology Risk Officer? If it was up to you, how would you structure the role?
Rich Isenberg: I mean, titles are titles.
James Kaplan: Not, not, not the title. I mean, whether there’s one person who’s in charge of cybersecurity and then other people who are responsible for other forms of technology risk. I’ll be transparent. I favor combining all the technology risk together because you would reduce the chance that you have two different teams going to talk to application development folk about patch management, right?
But curious what you think.
Rich Isenberg: I agree because there’s a lot of overlap in controls around different areas of technology risk management. Having different teams with different methods and different opinions, often assessing the same controls, is not a model that works very well.
James Kaplan: A couple years ago, there was a bit of a move to take CISO out of it. I was wondering what your take is. I think you see less of that now because I, my perception hasn’t been terribly effective. What’s your take?
Rich Isenberg: I agree. There was a push many years ago because of this theory that if CISOs line-reported to the Chief Information Officer, they wouldn’t have an unbiased view and voice to stand up for safety over speed.
Oftentimes speed would trump safety because of the way technology orgs were historically incentivized — on speed and code. They didn’t consider a security defect a real defect, and nobody’s bonus depended on it.
I do think the only way to really bake security and safety into products and technology organizations is to be embedded within it. Otherwise, you end up bolting it on afterwards.
James Kaplan: If you think your CIO is gonna prevent your CISO from providing transparency to the management team and the board, you need a different CIO and a different CISO
Rich Isenberg: Right. But I do think one of the norms that’s enabled healthy behaviors here has been that while a lot of CISOs line-report to a CIO who then reports to the CEO, they also have an independent relationship with the CEO and the board. And I think that’s important.
When I was the CISO at SunTrust, even though I reported to the CIO, the CEO, Bill Rogers, would directly say: “Nobody gets to edit Rich’s board slides.” You could see them, you could talk about them, but you don’t get to change them because we need transparent talk of risk. Debates are healthy. There’s a healthy tension by design in that system.
James Kaplan: The one place where I’ve seen the the CISO not report to the CIO is, in technology organizations where you have technology spread across the entirety of the business. And sometimes then I see the CISO reporting to the CEO.
Rich Isenberg: I’ve seen that too. The giant technology organizations are very engineering-driven. The security teams there don’t have the same mandates that a large bank security team does. They don’t have the big regulatory stick.
Nobody’s gonna yank their ability to do banking if they’re disappointed in their security model. So I do find they become very innovative and often do things better.
These large tech companies benefit from ruthless standardization of their technology stack and not having to deal with 50 years of tech debt and mainframes. They have a database, which is sometimes a lot easier to deal with.
What makes a good CIO on security?
James Kaplan: I think there’s an interesting dynamic for the cloud service providers because they face so much pressure from the banks. So we’ve talked a bit about CISOs. What makes a good CIO in terms of information security or cybersecurity and technology risk? You and I have both heard many CSOs expressed frustrations with the CIO.
What are the great CIOs or what makes for a great CIO or what great CIOs have you observed or what are the characteristics of great CIO on security?
Rich Isenberg: Number one, they’re really good listeners. Some of the best that I’ve observed or worked with, even though they may actually be the smartest person in the room, they’re always the last to talk. They’re always asking for everybody’s perspective.
When you start to have leaders like that, it actually develops healthier conversation and makes it easier to gain influence and do the right thing. What makes a good CIO is a lot of what makes a good leader. You have to build an emotionally connected team — the emotional connections and the trust within the team.
Now, I will say they also have to care about technology and understand it. There are a lot of long-tenured CIOs that operate from a seat of fear because they don’t really understand the technology. Those don’t really get inquisitive and don’t always get to the right answer.
James Kaplan: And it’s a challenging thing, right? Because if you’re a CIO, it’s a long time since you’ve been fingers on keyboard. the proliferation of technologies in a large institution is almost terrifying, right? And very hard to keep up with. it’s funny, the head of infrastructure at, one of the big banks was a good friend of mine and they were having problems with — I forget whether it was,
Tandem or Unisys or something — some decades-old system in some part of the world, and he’s this is great. This is the thing I was first programming on in the 1970s. I’m getting on a plane, I’m going there myself, I’m gonna show him, show him how it’s done. But I do have a degree of sympathy.
For people who’ve been around a long time and you’re managing a huge organization and my God is a variegated stack, and how the heck do you stay on top of all this?
Rich Isenberg: Yeah. Great CIOs are great talent multipliers — that’s how they stay on top. They invest in people, modern skills, and partnerships. They know when to build, buy, or partner rather than doing everything themselves.
Secondly, they operate with discipline and clarity. Who has decision rights for what? Get rid of the friction in teams. The best CIOs make it easier for CISOs to do the right thing rather than attack with brute force.
They’re also great architects of trust. They care about balancing speed with safety, innovation with control. They wanna make sure their org can move fast without creating invisible risk.
I think they’re really good at translating technology into business outcomes. I don’t hear the best CIOs talk about systems and platforms. They talk about growth, efficiency, resilience, and customer trust.
James Kaplan: I would, I would say I would take maybe a slightly different view, which is the best. CIOs will talk about platforms and technologies depending on the audience. Right. They can talk about growth and margins to bus, fellow members of the executive team. But when they’re talking to their town hall, in many cases, they can show, they can understand the platforms and the technologies.
And the other thing I’ll add is many of the best CIOs I’ve observed are obsessive readers, right?
Rich Isenberg: Yes. And that’s another translation too — the best leaders I know are voracious readers. But the mandate for a CIO has changed. It used to be that CIOs needed to deliver technology.
Now, when you look at the amount of technology conversation in stock rating calls and analyst questions, it’s clear that the great CIOs are delivering confidence that the organization can actually innovate, scale, and adapt without losing control.
James Kaplan: Well, I’d also say if you go back about 15 years, we had much more in the way of technology oligopoly. A couple of storage vendors, three compute vendors, a major enterprise application vendor in each domain, three or four DBMS providers.
You had a simpler stack and you could rely on the vendors more. Fifteen years ago, a CIO was, in many respects, a vendor manager rather than an organizational and environmental architect.
Rich Isenberg: Yep. Back in the day, nobody got fired for buying the 800-pound gorillas in the market, whether networking, storage, or compute. There was safety in that. And I agree that vendor management was what was really going on.
Securing AI
James Kaplan: All right, so let’s talk about AI and security or AI and technology risk.
There’s two mistakes you can make in security. You can go too slow or you can go too fast, right? Or you can take on too much risk or too little. Which direction do you think most companies are?
Erring in, or is it a mix or both? So, the modal company, do you think is, is moving too fast on security and incurring too much risk or moving too slow and incurring market risk rather than technology risk?
Rich Isenberg: I think it’s definitely both, and oftentimes within the same company. Many companies are being pressured to move very fast on AI experimentation and early deployment without fully recognizing how autonomy has changed the risk profile. They assume existing cloud or application security controls will be sufficient, even though agentic systems introduce new failure modes, chained actions, and hard-to-trace decisions.
At the same time, there’s this reaction driven by fear and uncertainty. Some orgs respond by applying a one-size-fits-all control, treating every AI use case as the highest risk. That slows everything down and pushes the business toward shadow AI.
The orgs that get it right aren’t the fastest or the most cautious — they’re the most deliberate. They tier things by risk. They’ve invested in monitoring and containment early. And they allow people to move very quickly within those boundaries.
Speed, when done right, can be achieved not from ignoring risk, but from having confidence that it’s managed.
James Kaplan: I thought, and I think you thought that cloud was a tremendous disruption. From a security standpoint that, we had to give up the perimeter, everything was much more automated, things were moving faster.
We needed a, a whole new security model. And I would say, generally speaking, most technology organizations, rose to the challenge. Over time, after, some deceleration or some slowness. But yeah, it feels a much bigger disruption to security models than, than cloud ever was..
Rich Isenberg: I agree. And part of it is happening faster. When I talk to clients, I use this analogy: it’s very similar to cloud, but on steroids.
When public cloud started being experimented with in large organizations, security teams would dedicate 5% of their multi-talented architects’ time to try to figure it out while the business and the rest of the tech team hired a thousand people. Then they realized security was the blocker because it needed full-time focus. Suddenly we saw the creation of cloud security teams, and then you started to get business enablement.
I think AI is different enough that the same thing is happening. Those that are gonna get it right realize that you need some dedicated horsepower directly involved with the tech and business teams to figure out strong agent and machine identity and to build that deep observability.
But I do think there’s a challenge: there’s nobody in the job market who’s been doing this for 15 or 20 years. When I think back to my Capital One days, part of the reason Capital One was able to accomplish so much so early is there was no competition for talent.
So I do think there’s this great need that security teams have to figure out how to upskill their teams to step up to the challenge.
James Kaplan: It’s organizationally similar, but conceptually different. And the way it’s organizationally similar is death by use case, which is a million little, not little. A million vice presidents, directors want to commission their project using cloud now using ai, and they’re gonna go solve their use case around.
I don’t know. customer retention in middle market. Something, something, something, and the rest of the organization can go hang and they’re not gonna use a platform and they’re not gonna use standards. And maybe they’ll get some vendor that will do whatever they want, want to do. And, it’s, it’s sort of in terms of transformation, it’s as I to say, it’s trying to get to the moon by climbing the tallest tree.
The first 60 feet feel great. But you’re very quickly creating a lot of technical debt, and I think you see some of the same things with ai. Now, conceptually it’s different because cloud as complicated. It was, at least it was deterministic.
Rich Isenberg: Yeah, I agree with that a hundred percent. There are lessons learned from people dealing with enormous inventories of tech debt because of what you just described, and it can easily be recreated in the agentic world.
If you allow every business to choose their own agent platform, build their own agents, and create their own MCP servers and AI gateways, you’re eventually gonna end up with 87,000 outdated versions of Linux residing in most data centers today that somebody will have to go deal with.
James Kaplan: Or not even using AI Gateway, just go directly to the, go directly to the provider.
Rich Isenberg: Yep.
James Kaplan: We’ve talked about some of the governance and organizational changes. What do you think are the three or four biggest architectural changes or technology changes required from a security standpoint in the age of AI or the agentic age?
Rich Isenberg: If I think of three, the biggest shift is moving from a thought process of securing individual systems to securing end-to-end workflows. Agents and AI really break the old paradigm that there’s a single user, a single action, or a single boundary. You really have to make that mind shift.
Second, companies need to think about strong agent and machine identity. All these agents need verifiable identities, scoped permissions, and least privileged access, just like humans. I find that’s one of the hardest things to get right, and not getting it right from day one will make it very difficult to scale.
James Kaplan: Is agent identity more complicated than machine identity? Because we’ve been dealing machine identity for a while now, is agent identity thornier?
Rich Isenberg: Yeah, I would argue most companies have not really solved how to manage machine identity.
James Kaplan: Okay. But a few have, right?
Rich Isenberg: They have, and it is thornier. Some of it is because there are new protocols like OAuth and rich access requests to deal with.
If you believe part of the goal is to build an inventory of reusable agents that you can stitch together in different workflows, then these agents have different roles every time they execute a task. You have to ensure they have an identity fit for purpose for that role on that task — which may only last 15 minutes. And they need a different identity with different permissions 15 minutes later to execute their task on another workflow.
This leads into another architectural challenge: policy enforcement now has to happen at execution time, not just at design time. You need controls that can evaluate, in runtime, what an agent is trying to do in context before the action actually occurs.
Third, you need really deep observability from an architectural design perspective across planning, tool use, and code generation. That has to include containment and rollback. You need the ability to isolate agents, revoke credentials, and reverse actions.
If I had to sum it up, the big change is security has become dynamic, identity-driven, and behavior-aware — not perimeter-focused.
James Kaplan: Yeah, I mean, I’ve had Jaya Gupta from Foundation Capital on a week or so ago, and she was talking about decision traces. But it occurs to me that decision, the sort of, the deliberative exhaust data about deliberations that agents can throw off, right? That you see on the screen when you use cursor or what have you.
It may be the case that decision traces will be, or agentic decision traces will be an important part of the security telemetry going forward. We need to capture that to understand what the risks are and how to manage them.
Rich Isenberg: Yeah, a hundred percent agree.
James Kaplan: You made the point that we need to. we can’t do things at design time. We need to deal with them at runtime. One of the most interesting papers I saw recently, asked the question how in God’s name do you manage what agent is allowed to do what or access what tool in running a non-deterministic process, right?
And it, the paper offered an interesting suggestion. That instead of the agent accessing a tool directly, the agent should generate code to access the tool and then we can, we can analyze the code to see if it’s accessing something it shouldn’t. And then the agent should, and then, you can have tooling that says, yep, this code looks okay, and then the agent can run the code.
I was wondering how practical you think that is.
Rich Isenberg: Very interesting idea. I actually think that creates a pretty strong pattern, especially if you’re talking about higher-risk actions.
It reframes the agent from an autonomous actor into something more like a developer. A just-in-time developer, right?
James Kaplan: A just-in-time developer, but we know how to scan code.
Rich Isenberg: While you’re right, the code can be scanned and validated using security tooling. You could do policy checks, static analysis, compliance rules, pre-execution. But I don’t think it’s something you’d use everywhere — it would add latency and complexity.
But for actions involving data or infrastructure change? I think it could be extremely effective at turning opaque agent behavior into something that’s inspectable, which is kind of what security teams want.
James Kaplan: The paper proposed this in terms of calling tools that would send data outside the environment, which is not everything, but is higher risk than other things.
Rich Isenberg: Yeah, so I think case by case, it’s a pretty strong pattern to have in the quiver, but I don’t think it’s a de facto single silver bullet.
AI for cybersecurity
James Kaplan: So let me turn this around and talk about some of the opportunities associated with cybersecurity in the agent era. We talked a lot or we talked a bunch before about how the role of cybersecurity is to help businesses make decisions about which risks to take.
Risk management is inherently non-deterministic. It requires judgment. But a lot of our thinking about security is often very reductionist. This data must be encrypted at rest. Those systems need two-factor authentication.
That works great if we’re talking about preventing social security numbers from being sent outside the organization. It works less great if we’re talking about whether we can share this strategy document with a vendor — is it baked enough?
And I was wondering, is there a way to build reasoning into cybersecurity processes to help them scale?
Rich Isenberg: What an interesting idea. The strongest point is that you’re correct in saying a lot of controls today rely on a very static yes-or-no rule.
A non-deterministic control would evaluate the intent and the context. Rather than saying social security numbers can never leave the environment, it would ask: What data is it? Who’s requesting it? What’s the purpose? What’s the downstream exposure? And it would make a risk decision: should I allow it? Should I allow it with constraints? Does it require human approval? Or does it get blocked?
If you took that principle and combined it with policy engines and feedback loops that can reason and learn over time — tightening or loosening based on observed behavior and human grading — it could reduce friction while still maintaining security. It could be key to how orgs can scale without drowning in approvals.
One of the benefits of agentic AI is removing that human delay. But what orgs are struggling with right now is there’s an enormous amount of human delay in building and approving all the things that go into agent AI.
James Kaplan: Yeah, I mean, it’s a, it’s a, it’s an interesting interconnected challenge because we need, at least I’m observing as rapid a pace of technology consideration. As I’ve seen in decades, right? There’s all sorts of things, individual technologies you need if you’re gonna do AI in a scalable, responsible way, all of which need to be evaluated and risk assessed.
And many organizations I know of are, sort of bottleneck in that, in that way.
Rich Isenberg: Yeah, I’d say I agree completely.
James Kaplan: Yeah. And the and what’s interesting to me, particularly about this issue of agent to control is if you think about what you and I have done many times over the years or constantly over the years as we think about security strategy, is we help people think through the intermediation between a necessarily,
Non-deterministic set of risk analysis, right? How much risk is, how much property risk is too much, too much intellectual property risk. There’s no equation for that, but that has to drive a set of deterministic controls based on human judgment, about how much IP risk is too much IP risk.
We either do or don’t have multi-factor authentication on this system.
Rich Isenberg: Yeah. I mean, I think you’re right. I think the biggest risk in AI isn’t what the technology can do. It’s deploying it without knowing how to stop it.
James Kaplan: Exactly.
Rich Isenberg: If you can’t slow it down or shut it off, if you can’t explain it, you don’t actually control it.
And now we’re — I think it’s about autonomy, and autonomy without governance is not innovation. It’s negligence.
James Kaplan: Right. And then the one other thing I’ll note is there, there are more prosaic things that I think companies need to look at from a security standpoint, which is, you know, can you get some of the. Can you automate some of the toil of just comparing this architecture to that set of architectural standards or security standards?
I was wondering if you could talk about that. How, how, how real is that now and how big a deal is that the ability to compare different things to even deterministic technology standards.
Rich Isenberg: I think it’s here and it’s a big deal. Companies with all their technology are very concerned about resilience. One thing we’ve learned with pattern recognition is that a way to measure resilience is how compliant everything you build is with the actual standards in place around building it. Most folks can’t answer that question.
To be able to really do reasoning, you feed it your knowledge base and start to do the comparisons. You figure out where you have non-compliance to architectural or security standards that are creating invisible risk, so you can actually make decisions.
We have clients doing this. A common bottleneck — not just for AI but for development organizations writ large — is the architecture review and security review. It becomes very opinionated and committee-focused. One thing we’ve learned is that committees don’t scale; workflow scales.
James Kaplan: The second thing I wanted to ask you about, which may be a little bit closer in than non-deterministic controls, a number of folks have observed that there’s a security opportunity and the ability to integrate and interrogate the massive amount of exhaust data that any technology environment of any size throws off.
How real is that and how close in is that?
Rich Isenberg: That said, I think all these things are possible. Where people are getting hung up is that a lot of chief executive officers and boards are demanding: where is our agentic transformation in the business? They’re not really focused on the opportunities to fundamentally change the IT operating model and cost structure through some of these opportunities you’re talking about.
To truly succeed in this transformation, they have to do both. The opportunity to take in the exhaust and get decisions and insights, as well as accelerate the pace of technology done safely, is gonna be market-changing.
For the folks that get it right, they’re going to outpace their competitors and do it more efficiently.
James Kaplan: Yeah, I mean, I’d say that first off, For most companies or many companies, the biggest single rate limiting factor for their strategy is technology. They just can’t deploy capability quickly enough or efficiently enough. And the second thing is, or the clear implication of that, is you need to apply AI in a disciplined and systematic way to the technology function.
No less than any other. Business function, quite frankly, you won’t succeed in applying it to any other business function unless you apply it to the technology function.
Rich Isenberg: I agree. And this goes back to what CISOs and CIOs should be thinking about right now. AI is not gonna replace technology leaders, but technology leaders who can’t govern AI are gonna replace themselves.
James Kaplan: Or be replaced.
It’s that cartoon I love showing a horse in the 1890s: you’re not gonna be replaced by a car, you’re gonna be replaced by a horse driving a car.
Rich Isenberg: I tell my kids, right, AI is not taking your job, but someone who knows how to use it better than you will.
James Kaplan: Anything we, anything we neglected to talk about? Anything else you would want to say?
Will the NHL ever return to Hartford?
Rich Isenberg: I don’t think we spent enough time talking about the tragedy of Peter Karmanos moving the Hartford Whalers out of Hartford.
James Kaplan: Well, I was gonna get to that — that was the next thing. Alright. I mean, and that’s an even bigger tragedy than the Dodgers moving from Brooklyn to Los Angeles. So here’s the question I was gonna ask. What is the likelihood that there will be an NHL expansion team in Hartford in the next decade if you had to bet on it?
Rich Isenberg: Zero.
James Kaplan: There is no non-zero price you would buy that security at?
Rich Isenberg: No, and I’m tainted by history, so there is bias in here.
But if you remember — most people don’t care about this or are too young to remember — the reasoning is that Hartford is in between the television markets of Boston and New York. A lot of sports profitability is driven by broadcasting deals, and in the NHL it’s team by team — there’s no NHL-wide broadcasting deal. So the Hartford market is just not competitive.
People forget that the reason the Patriots got Massachusetts to help fund Foxborough was they threatened to move the team to Hartford.
Even though there are die-hard fans, one of the most popular and best logos, and the Brass Bonanza goal-scoring song, I don’t think the NHL will do it. The community would embrace an NHL team, but I don’t see it happening.
James Kaplan: Okay, follow up question, as I’ve noted too many times. Whalers really refers to either a type of ship or a person on the ship. Hartford is a long way from the seashore when, if it were up to you, when they moved the team from Boston. Boston Whalers, that makes sense to Hartford, should they have renamed the team as the Hartford actuaries.
Rich Isenberg: Probably, but then it would’ve left the city even earlier the rest of the insurance companies.
James Kaplan: I mean, Hartford Whalers makes about as much sense as the Utah Jazz.
Rich Isenberg: Yeah, that’s a true story. Yeah.
James Kaplan: All right. Well, Rich, thank you very much.
Rich Isenberg: Oh, this was exciting. I’m excited to listen when it comes out.
James Kaplan: All right, terrific.
Rich Isenberg: Thanks.
