Welcome to Conversations with CISOs, Security Leaders, and Technology Executives, where we sit down with the leaders shaping cybersecurity and enterprise technology. Today I'm joined by Vincent Romney to discuss integrating AI into enterprise stacks. Vincent, thank you for taking the time to join us today. To get us started, could you introduce yourself and tell us a little bit about your background and your current role?

Sure. Again, my name is Vincent Romney. I have a ~ 28 year history in information security. ~ Started out ~ in the Air Force ~ as an information systems guy, and then ultimately ended up in cyber warfare, retired at the end of 2013, entered enterprise and did some defense contracting, got to work on nuclear surety programs there. And then now I'm currently in an enterprise role as Deputy CISO for an international company that's publicly traded.

Excellent. So when an enterprise says they want to integrate AI, what does that actually mean from an architecture and a security perspective?

So I think one of the the fallacies that exists out there is that by integrating AI, we're changing the fundamentals of security. And in fact, everything that goes into architecting security holds true when it comes to architecting security around AI. AI just has some nuance about how it individually acts. And the type of actions it can take because we can build agents that operate semi-autonomously or fully autonomously. And as a result, the considerations around IAM, identity and access management, ~ segregation, least privilege, least ~ capability, all that stuff have to be baked in a little more ~ I'd say rigorously to ensure that the AI workloads don't go awry. It's really a discipline factor. And so, from an architecture perspective, I try to apply a much more aggressive evaluation of the ecosystem to understand what the AI is intended to do, and then try to bake the security, privacy, GRC around that in a way that I'm confident that I can stand up to an audit, that I can defend the system adequately in depth. Because ~ one thing I've learned about AI, particularly prompt injection capabilities, when you either have a chatbot or an agent that operates off of input, ~ it's not that difficult, and in fact, in many cases trivial, to ~ get that system to act outside of its original intent.

So specifically what are those principles that hold across traditional cybersecurity in AI and what are some of those exceptions that you have to know ~ address with AI more specifically?

I don't think we make exceptions to the the foundational principles, but we have to look at the system more aggressively and determine that it's a ~ much more potentially dangerous situation. So identity and access management has always been one of those cases that we try to work with least privilege identity, right? So that identity can do the least amount necessary to do its job, whether that's a human or a machine or whatever. Well, with AI, especially in an agentic system, an agent it's it's a little more aggressive about trying to get its job done. ~ the recent hack at ~ and I use the term hack, it w it was a compromise. of Hugging Face as a result of OpenAI's research project was an agent doing everything it could to accomplish a task. And if we think that way, then we say, well, we've got to make our identity and access capability truly a zero trust involvement. So we build a zero trust relationship throughout the ecosystem that that agent has access to. You know, and this was a research project, so it's not like that's something that should happen in enterprise, but if somebody were to give their agent 100%, you know, root access to everything, it could go awry very quickly. So it's that concept where we're going to apply those things in a way that we treat that AI as kind of a loaded cannon and make sure that we're not allowing it to go off in ways that we aren't intending.

So what should happen before an organization connects those AI models or agents to applications or enterprise systems and data?

The most important thing is to truly evaluate the worst case scenario. A lot of people you know, everybody loves the happy path. We want it, we just want it to do what it's supposed to do. And arguably, you know, vibe coding and pre-built agents and things like that are very good at doing the happy path. And so people kind of I guess lower their guard, even at enterprise level, ~ about these systems. And I think that's where the biggest issue comes with an organization saying we want to adopt an AI system to do X, Y, or Z, the evaluation of what that intent is and then how could it go wrong? Really thinking the negative use case and breaking it down and figuring out how you're going to compensate for the potential negative use cases. And most of that comes around true hard segregation, just buckling things down so that there's not a way to break out of an environment.

So when it comes to integrating AI into enterprise environments, most enterprises do not exactly have clean environments. There's years of cloud services, SaaS applications, identity systems, legacy infrastructure, et cetera. So what makes integrating AI into that stack particularly difficult?

Well, again, ~ a lot depends on that integration. But again, if we build an agentic system, I love going back to that because that seems to be the trend. Everyone's making agents do things because it's a ~ it's offloading work to a machine. And when we offload work to that machine, the challenge is that the machine is going to do things that are outside of intent to get a job done. And so when an enterprise says, I want to build this into our existing environment, understanding how that existing environment is authenticated is a primary thing. That agent needs to authenticate to something to do work. What else can it authenticate to with those same privileges? And so getting very, very granular in What is available through that legacy enterprise system? Because some some enterprises, that network is essentially flat. And as a result, permission into that network means permission to everything in that network. So de-scoping things, going to micro-segmentation, breaking things down to a much smaller blast radius ~ is an imperative when somebody's bringing something into an existing, as you said, dirty stack.

So you kind of already touched on the identity and access piece, but how should organizations treat AI agents when it comes to identity and access management? Should they be treated more like users, applications, or something else entirely?

Well depends on the role, right? I mean if it's a service and because we currently have services, right? We have machines that provide services, they have a service identity, ~ and as a result, we we treat them like that service. ~ but some agents function much more like a user. And so ~ some of them have a role from the Active Directory perspective. They actually fill a role in the Active Directory perspective. They have an HR slot. If they're doing that, we treat them purely like a user and really put those controls in the same context as a user. We have role-based access, we have least privilege, we try to contain them. We make sure that user is observed as a user. And as opposed to a service where it's a deterministic system, a service is like a lambda function that fires or a server that does a certain thing. ~ Those are very deterministic and it's not going to do anything but that. In the case of AI, the potential to do things outside of that scoped deterministic expectation are there. And so we have to build ~ identity around that. And really that comes down to treating it, if we treat it like a user, we're going to treat it like a user. We're going to look at it from an insider threat perspective. We want to observe behavior, so we use user behavior entity analytics to really look at that and monitor it.

So when it comes to AI having access to data, obviously as you just stated, you don't want it having access to everything. You can't have it running amok. But how do you give it enough context to actually be useful within the enterprise?

So a lot of that is where RAG comes in. We want to build this RAG ~ interface where it can have the contextual data it needs, build that into its context window, and operate within that without really having to utilize ~ a lot of outside resource. The danger there comes with any agentic system is that if the system prompt for that agent is scoped in a way that it's going to try to get that job done within the scope of that system prompt, and we give it access to, say, the internet, it will take vectors outside of the ecosystem. It won't even use the rag. It'll go outside to the ecosystem and see what else is out there to play with. ~ Because that's the nature of the beast. It it will do things we don't expect. So building a good rag, containing that, making sure it's isolated to the back end LLM and the rag, and then ensuring that that system prompt can't be manipulated. That's certainly one thing is when we test and we attack ~ an agentic system, one of the first things I try to do is overwrite the system prompt. Because if I can overwrite the system prompt for that agent, then I can make the agent do whatever I really want it to do ~ in that scope and a lot of agentic systems do have human interface. So I can send it a document, and in that document, embed a prompt, a prompt override, a prompt injection. So those kind of activities mean that if we are going to do this in the enterprise, we do need to look at what that environment is scoped to. And so not giving it all the data, but taking some of the data, putting it in a rag, and saying, This is your data, just this environment, operate out of this. You don't have access to a database, you have access to a data set that's plugged into the rag and that's where you get it.

So you had already mentioned in your opening that a lot of securing AI isn't new, that it's those basic principles, those identity and access management pieces. But where does AI genuinely require new security controls or perhaps tools or solutions?

Well I don't know that there's a new approach. Again, I've really evaluated this, and I just I don't see AI requiring new security. It's the security principles that we have established over decades properly applied to a new ecosystem. And that new ecosystem, some of those caveats are that first off, I have the capability to have the entire sum of human language as a back end to draw out of. So now I do not have any assurance that there's going to be a deterministic response, say in a chat bot, or that an agent that is utilizing an LLM to make decisions to create output is going to do the same thing twice. So it's security has traditionally been locked around the idea that this service does X, therefore I scope that service to this, and it will always do that. And that's probably the nuance that makes AI different is that we still have the same security principles, but we now have to look at a system that is no longer deterministic. It's now kind of whatever it wants to be at that moment. And obviously the LLMs are getting better, the back-end stuff. We build machine learning systems to be much more towards the deterministic side of things, you know. But even those are not purely deterministic they are still AI. They are still going to provide some variability in the output of that. So building security around something that's no longer deterministic, we still use the same principles, but now we have to apply it to a non-deterministic model.

Okay. So when as enterprises are continuing to adopt AI, how do you prevent that from becoming another form of technology sprawl? Is there any danger that every department will start buying their own models and agents and SaaS products before security has visibility into them?

100%. And and that happened before AI, right? I mean shadow IT was a thing, and it still is a thing, and then shadow AI is gonna be a thing and it will always be a thing. Because people, you know, let's be honest, people wanna do stuff. Right. I mean I was people get down on developers like, they're always doing no no. Developers love to build. They love to make things happen. They want to do their job. Yeah, they love to do their job. They love to make things happen. Somebody in finance wants to make their job easier and they go, hey, this AI might be an option. Maybe I can build something to do X, Y, and Z in my job to make my job easier, to get better context of what's happening in my world. And and so that is going to be a constant, you know, shadow whatever is a constant. As an enterprise, the ability to enable people to do stuff on their own with air quotes around on their own, but bake it into a process that the enterprise has capability to control it, has visibility that it exists, you know, and and can work that through. So ~ I did a keynote yesterday, and one of the points I brought out is that we have leadership in our company that they're coding. They are using vibe coding capabilities to build out and do stuff. And ~ the thing that I've kind of tried to wrap around this is great, do that, but before it goes to production, before you engage that, let's pull that idea that you built in a Vibcode environment and let's reformat it through our normal SDLC so we can apply SAST to it, you know, static application security testing, so that we can apply DAST to it in the staging unit. We can beat it up, we can fuzz test it, we can break it before it goes to prod, so that we now have an application that's supportable. Because one of the things that you know, if finance intern Bob builds out this whole thing that does a job and he becomes dependent on that, and the department becomes dependent on it, he's the only guy. He

Mm-hmm.

leaves or it gets complicated and it needs patching and it needs fixing. We don't have a support system for that product because it's independent of our normal pipeline and our normal support system. So we want we want people to innovate, we want people to do stuff, we want to wrap that in. And own it enough to be able to support it. Because you know, finance intern Bob leaves, and now that system is something in you know finance is using, but nobody owns it. And sorry, you know, Cluade Code can't own it.

So that's an interesting way to balance that kind of business enablement and innovation with security. Are there any other ways you found effective with shadow IT or previously shadow IT and now shadow AI to balance those two things?

Try desperately as a security professional not to be the department of no. ~ You know, be the department of how. I think again, this is something I adopted prior to AI. You know, AI gave us ~ I'd say a little more of a pucker factor as it started to explode and we're like, whoa, this is moving really fast. You know, I don't think we ever had a technology move that quickly and and become ubiquitous in our lives. And so this that's probably the thing that's unique to how AI has ~ has created challenges for security professionals. Is it's just that rapid rate of adoption. ~ Once you get your head around it and you understand the liabilities there, now you can effectively communicate risk up to the leadership and have them help make decisions on how to deal with that risk. You know, we say this is how much risk we're incurring, we're embracing this risk to do X. Are you good with that? Do you feel the ROI is worthwhile? Because we are increasing the level of risk to the company by doing X, or Y Z.

So what does good visibility and monitoring into AI look like once it's integrated? What should security teams actually be logging and monitoring when it comes to AI access?

That's a good question. And the way I look at it is think audit. So you're you're in an audit situation. Can you explain what's going on? Because once something goes awry and auditors are in there from a regulatory body, from you know, FTC, from whoever, they're in there. They're scrutinizing every element of your ecosystem. And if you can't explain what's going on beginning to end, then there's a problem. And so your observability needs to be built around all of that. So if I have an ecosystem that ~ has an agent that does a job ~ that maybe interacts with my customer data, ~ and in that job it has an output. I need to have all of that documented and logged so that I see the inject, I see the outcome, so the agent's decision making outcome. ~ I see the data it accessed and what happened to that. It went, you know, got pulled, it got consumed, it got restructured and put into another file, whatever that process is, I need to be able to identify every element of that workflow so that in an audit, I am not going to be, you know, caught just dumbfounded and say I have no idea what's going on.

All right, excellent. So as we wrap up, I have one last question. If you were designing an enterprise AI architecture from scratch today, what are the security principles that you would build into the foundation?

I think I would again go right back to the foundational level security. I would say I need to know who is doing what, why it's doing it, and what the expected outcome is and every possible iteration of failure. Once I've defined that in the architecture, and I say, great, it's connecting to this data. Now every single connection I need to understand what the intent is, what the failure modes are, what the capability of that ~ system was supposed to be, and then document that so that I'm not allowing a agent to have access to all the things. And that's you know, fundamental architecture is always I've got a compute, I've got data. You've got application that uses both. So what is that interaction supposed to look like? So in architecting AI, I want to use that same principle and build in all of the defense mechanisms that I need to throughout whatever that ecosystem looks like. So we talk about things like a WAF. Well, is this AI ecosystem going to interact with people on the other side of our network? So is it going to go out to the internet? If it is, then you know I probably add a WAF in there. You know, there's these fundamentals that just are always there. And that's why I kind of find it interesting that people ~ do have, in some cases, they're, you know, they're waving their arms in the air and their hairs on fire about AI. And I'm like, well, yes, it is a very innovative and unique technology capability. It is not new technology. I mean, heck, Ada Lovelace and ~ Charles Babbage ~ conceived AI effectively back in 1830. 1835. So, you know, this isn't a new principle intellectually, but the capability is relatively new. And ~ and that's been based on just incredible increases in compute and data structuring and in ~ enterprise ~ level hypervisor you know capabilities. We are now at a point in technology where we can support AI. ~ And so I think you know, from my perspective, the architectural principles don't change. But we have to apply them in a way that adapts to this unique kind of independent capability of things like agentic systems.

All right. Well, thank you everybody for watching. If you enjoyed this conversation, be sure to like, subscribe, and leave a comment with your thoughts or suggestions for future guests and topics. And thank you again to Vincent Romney for joining us today.

Thank you.