Shift to AI – Episode 2 – Shift Left Is Dead. Shift to AI.

Presented by Cycode, the Agentic Development Security Platform

Roland Cloutier

Hi, welcome to Shift to AI. I’m Roland Cloutier, Global Chief Security Officer and Digital Business Enabler. On this podcast, we explore how AI is reshaping security leadership, engineering, and digital trust.

Today’s topic is “Shift Left Is Dead, Shift to AI.” For years, we believed application security was about helping developers write more secure code. Today, the developer is often an AI agent, and the software factory itself has become the new perimeter. We’ll explore what that means with one of the industry’s most respected security leaders.

I’m so excited to have a dear friend and longtime colleague, Bret Arsenault, CISO Emeritus at Microsoft. Bret spent decades helping secure one of the world’s largest engineering organizations while enabling innovation at global scale. Few people have a better view of how software engineering and security have evolved – and what a lot of people don’t know is that Bret actually came from the engineering and software side of the house before moving into security.

So today we’ll discuss what comes after shifting left, and how CISOs and engineering executives should prepare for autonomous software development. With that, I’d like to welcome Bret. Hey, Bret, welcome to the show, man.

Bret Arsenault

Thank you so much, Roland. Always good to see you.

Roland Cloutier

It’s always great to be with you. And you know what – I open these with a simple question, so I’m going to ask you this first: walk me through the first thirty minutes of your morning, and the last thirty minutes of your day.

Bret Arsenault

No, no – now I’m nervous.

Well, it’s a little different now that I’m in retirement mode. But, you know, I wake up in the morning, have tea, chat with my wife, go check on the fish pond, and then look at what’s going on in the world of AI – how it’s going to make my life better and how the technology is working. And obviously, who’s buying the Seahawks is a big topic lately, too.

Honestly, though, it is interesting. I still spend time doing venture work, and I stay involved in technology. I also support the Hispanic community and women in technology through some board work. And then I just enjoy connecting with people I love being with, and working on projects like this one with you.

Roland Cloutier

Yeah, it’s funny – as we transition into a different part of our careers, how busy it still keeps us, and how much we still have to learn. You and I were talking a couple weeks ago about learning AI, using these different technologies – it’s been an amazing year for that.

And I get it – we’ve thought about this for so long, about where we needed to take security, and it felt like we’d never see it in our lifetime. But it’s kind of like you not watching the Patriots – I never thought I’d see that in my lifetime, and here you are talking about the Seahawks. I really don’t understand it.

Bret Arsenault

I’ve watched them – and I’ve watched them lose – but not enough. They’re a winning team for sure.

Roland Cloutier

All right, I want to set the stage a little bit. I titled this one “Shift Left Is Dead, Shift to AI,” because as security, risk, and privacy executives, a lot of our focus is on a three-part drive: enabling our business to use AI in a secure and trusted manner, defending against new AI threats in all their forms, and becoming better security business people by migrating our own organizations to the use of AI – both to be competitive and to defend against AI. So there’s a lot going on there.

But do you believe that statement – that shift left is dead and we’re shifting to AI? Do you agree? What died, and what replaced it?

Bret Arsenault

Well, I think it was the Beatles who said the reports of my death have been greatly exaggerated. I don’t know if it’s dead, but I don’t think shift left in the traditional sense is going to be enough in this world. We were all trying to shift left, but there are times when you get step-function improvements in capability, and this is one of those times where you can’t incrementally sneak up on it.

I think we need systems that are far better designed, because, like you said, people aren’t even writing the code anymore. So I don’t want to say shift left is dead, but I definitely don’t think it’s going to be sufficient.

Roland Cloutier

No, we often talk about what we’re trying to do with our engineering partners, and you come from an engineering background. Can you spend a minute on that? I don’t think anybody knows what Bret did before he was CISO at Microsoft for a decade or more – it’s such an interesting background.

Bret Arsenault

Yeah, I was fortunate to have a pretty broad background, largely within one large company. I was Chief Technology Officer for the product division back when we had a security brand before we moved to what’s now the Forefront brand – think of us competing with Symantec and everyone else. I was CTO for that product division, building those capabilities, and before that I was CTO for the e-commerce business. So I’ve spent a fair amount of time in that space.

I think one good way to frame some of this is that – and as you know, I’m not the smartest guy in the room – I use frameworks to help me remember things. Every transition, every shift, even every job change, has things that are different about it and things that stay the same. For many people, I’d recommend reading Morgan Housel’s book Same As Ever, because every transition has a whole bunch of things that are exactly the same as the last one.

The differential isn’t a hundred percent. So the question becomes: what do you leverage from the past to improve on the new thing you’re building toward, and what’s genuinely net new? I think we’ll probably get into that around identity, and even around shift left itself. At the end of the day, developers are still trying to do what I was doing – I didn’t do a lot of Fortran, but I did a lot of Pascal. Being an efficient programmer is still being an efficient programmer, producing outcomes and output from the products you’re building.

That part hasn’t changed. But how you do it, and how you secure it, changes quite a bit.

Roland Cloutier

Well, let’s jump into that, because I think you’re right – the output we’re looking for is so critical to this discussion. Let me ask you this: did we spend a decade solving the wrong problem by trying to turn developers into security engineers?

Bret Arsenault

I never thought that was a great path. We always wanted developers to be more aware of security issues so they’d design better software – that idea of shifting left, designing security in rather than bolting it on, was a good concept, and we did a lot of good work in that space. But the more we tried to turn developers into security specialists, the more it took away from the core of what they actually did.

Way back, when the earth cooled, I was a computer scientist working on animation – building the systems that real artists used, tools like what’s now Softimage and others. I thought I was an artist, but I wasn’t; I was just a coder helping build the software. And I think a developer is never going to be a security person at heart in that same way. They might treat security as an adjective or an adverb, but they’re not waking up every day thinking about it – they’re thinking about optimizing code.

Honestly, we saw the same pattern with testers. We used to have testers, then we got rid of them, and there was a whole period of debate: do you want developers to be testers, or do you want them building harnesses that do that automatically? The way we used to frame it was – if we did our job right in security, developers would just fall into the pit of success.

Bret Arsenault

Their code would be clean, free of vulnerabilities, it would auto-update, it would have a good threat model. So instead of trying to make them experts, you make the systems do the right thing so they can’t make the mistakes that cause vulnerabilities in software. I think that idea – automating things so people fall into the pit of success – is a better approach than just trying to turn them into security engineers.

Roland Cloutier

I don’t disagree with you, Bret. There’s this mountain of issues coming our way, and we could argue all day about the path to this idea of zero-threat code environments. But there’s this mountain of code everywhere: our infrastructure is code, our applications are code, our integrations into our digital ecosystems are code, our business process management platforms – it’s all code. So when did the software factory become the new perimeter? Is this just happening because of AI? Has it been happening for a while? And where do you see it going?

Bret Arsenault

I think it was happening before AI, honestly. But there’s an important distinction: developers can’t be ignorant of security issues, and frankly, training agents to be smart about security matters too. I’m not saying it has to be done a certain way, but there’s a better way of doing it than what we did with things like IDEs and design environments – GitHub’s a good example, though there’s a whole slew of them.

We’d look for patterns, flag a bad coding practice or a bad library, and think we’d done our job. Then we’d leave it to the developer to go find the right library and fix it, instead of just pulling in a clean library, fixing it, and automating the whole thing for them. I don’t think the technology and tooling would have let us do this even five years ago – I think AI is what actually makes this automation work.

I have these three H’s I always come back to: honor the past, be honest about the present, and have hope for the future. I don’t think we could have done it differently, because we didn’t have the technology. So I’ll honor the approaches we took, but if we’re honest, those approaches aren’t going to work now. We need something different. I believe the technology, the focus, and hopefully conversations like this one will help people see what they should be doing to prepare for the future – and that gives me hope.

You’re the hope in my day today, Roland, so thank you.

Roland Cloutier

I’m here to serve, brother – that’s what I do. I’m a shining star for people. That’s what this podcast is all about.

Bret Arsenault

No, it’s good, it’s good. But I think I may have lost your question in there – why don’t you hit me with it again?

Roland Cloutier

No, I mean – this whole idea that software is the perimeter now. Our organizations were so focused on infrastructure defense, network defense, system defense, app defense, and then product defense – and product defense was really just a component. In a lot of cases, quite reasonably, the CISO, the director of whatever – they didn’t even have accountability over software development defense, over product code defense.

And now it’s become the entire business – the product we deliver, the technology we operate on, the digital ecosystem of our customers and partners – it’s all software. So that becomes the perimeter. How does that change in your mind?

Bret Arsenault

Yeah, it’s interesting working for a software company, where our primary assets are software. But I’ll use a bit of history and context here. Originally, security was all perimeter-based – all network perimeter. That was the easiest thing to do. Take an environment I worked in: 6,000 routers and over 10 million endpoints, and those 10 million endpoints operating on about 28 different operating systems. Doing everything in software meant dealing with 28 operating systems, versus 6,000 network infrastructure devices that all spoke the same language, basically Cisco IOS. So it was far more efficient to do network-based work.

But then, with zero trust and a whole bunch of other things, the network stopped being enough. So we said, let’s make it the infrastructure. Then the infrastructure wasn’t enough, so it became the software. You just keep moving upstream, the same way we move things up the stack over time.

Add to that mobility, then cloud-based computing, with completely different sets of controls and capabilities. Then the whole digital transformation that got massively accelerated by COVID. And then you realize – if everything is digitally transformed, even your biggest manufacturing firms are software companies. Take Caterpillar and John Deere, just as US examples, since you and I both like tractors: the amount of telemetry coming off those devices, which originally were agriculture or heavy equipment, is enormous. That digital transformation made everybody part of a software company. Everyone became not just a consumer of software but a purveyor of it, including a purveyor of cloud services.

So it necessarily had to shift – software had to become the perimeter. And then add one more step: the amount of low-code, no-code, Claude, whatever you want to call it, where non-coders are getting code written for them. Betting on the developer as a person was definitely not going to be the scale model that works going forward.

Roland Cloutier

It’s incredible to think about the scale we’re in now – not just what’s coming, but what we’re already in, and how that changes services. You touched on this a couple of questions ago, but I’d like to go a bit deeper: when the developer is an AI agent, and we’re talking about the transformation of how we develop code, bring it to market, and operate our businesses – what does AppSec become? Is it nirvana? Does it become what you and I have been talking about for years: in-process, in-work, validated independently, an entirely different subsystem focused on quality and security? How do you look at it?

Bret Arsenault

Well, I think the key word you used there was quality. At the end of the day, whether it’s a security vulnerability or just a vulnerability in the software, people always confuse the two. What you’re trying to write is the most efficient code you possibly can that’s free of any untoward behavior – whether that’s influenced by somebody else, or by your own lack of good coding practice.

I think the systems we build will be far better at achieving that dream of falling into the pit of success. Take the classic example: good companies today – take your old company, for instance – what’s the one thing you do for quality? You have code reviewers before you can check in. You need two independent code reviewers for any critical software, frankly for any software. That doesn’t scale; it’s people-scale. And the quality of that review depends on how knowledgeable the reviewers are.

Now imagine an entire repository of all the code ever written – take open source as an example – and you run some of these amazing models against it, using that as your code review process. Here’s one of the best things I see coders doing today: when you tell a model its work is going to be checked by another AI system, it behaves completely differently, just like people do. It’s the same as telling a developer that the engineer down the hall, who’s been on the project ten years longer than them, is going to be their code reviewer – it changes how you behave.

Roland Cloutier

Interesting.

Bret Arsenault

Yeah. Even when you tell an AI system that another AI system is going to be checking its work, it changes its behavior – you can see it in its commenting practice, in real time. And now you can do that at scale; it’s not two people, it’s two entire systems, or three. So your checks and balances get better. One model alone would already be an improvement. Two models working against each other is even better.

I do think it’ll be a much better scenario. But I see people betting they can just go with one path – no, absolutely not. Pick one, have somebody else check it, then switch it around and see who’s in charge, just like we do with auditors. You can’t use the same audit firm forever; it’s amazing how an auditor’s behavior changes the year before a new auditor comes in versus after. It’s the same as ever.

Roland Cloutier

Yeah, it’s funny – when you think about how much code we test, and you were specific that it’s critical or important code, or code touching a specific part of your value chain, that’s where you do the double-verified checks. What I think is great is where this goes next: the scale of what we can now do. It doesn’t matter if it’s critical – we can check all of it, 100%. You were teasing me a couple weeks ago about, you know, four hundred million lines of code, and you said, “That’s cute, that’s all you’ve got?” So, when we’re talking about AI coding assistants, where do you think they create the most value, and the greatest unseen risk?

Bret Arsenault

That’s cute. That’s a cute project. Just kidding, just kidding.

Bret Arsenault

It’s super interesting – this is always that classic early-adopter risk-reward discussion. I think the biggest thing people should differentiate is: are you focusing your AI assistance on net-new product, or are you going back to – remember the dev thing – what’s the least favorite job now that testing is gone? Sustained engineering. Nobody wants to be on sustained engineering. It’s poorly coded, there are no comments, you’re not adding net-new features, you’re just maintaining the system.

But there’s huge value in using an assistant to go back and clean up and comment all your old code. It’s more about the bottom line than top-line revenue generation, but it’s a really good thing to do, and it’s lower risk. You can spend time in existing repositories and figure out how they’re working. That’s number one.

Number two: I think using these assistants is a great idea, and for a while you’ll still want human intervention – your pull requests, your check-ins. You probably won’t go to production without a person checking for a while. You have to optimize the process, and having a really good workflow with your AI system is going to be super important. Whether the check is a human or a different AI system, you want the flexibility to have checks on the checkers. But you’ll get much broader coverage than you’ve ever had before, across the entire system, including your supply chain, and much deeper visibility.

The risk is that it’s all based on existing code and existing models – everything is trained on something. Generating something genuinely net-new is where I really wonder how that’s going to happen. So using them in those scenarios is super helpful.

Switching them to fully autonomous is a more interesting scenario. Going back to your comment on coders, there’s a real question of accountability once we do that. Who’s accountable – the person managing the agents, or the agent that did the check? Honestly, it’ll all come back down to lawyers and deep pockets.

Roland Cloutier

That’s funny – legal isn’t part of this series, but it could be a whole series on its own. Who’s accountable? When you think about the issues from the board to the executive team to officers, where does accountability for autonomous AI in the business actually land? I’m curious – is that the greatest unseen risk to you, or is there something even greater?

Bret Arsenault

No, I don’t think that’s the greatest unseen risk. Whenever there’s change, there’s a lot of money for attorneys – I should be careful, this is a public podcast – but there’ll be a bunch of ideas, maybe some regulations, and eventually enough case law that someone can actually create penalties or fines and resolve things.

It’ll take a long time. But luckily, some very smart firms, entities, attorneys, and governments are working on what the accountability should look like, because that’s going to be a huge factor in how this works. Some of the bigger risks I see are developer bias toward AI – even when you tell people, if this is important you should go check it, it’s AI. We’ve already seen examples, like the legal scenario where AI created a set of fake cases to justify its own output, fabricated case law. It turns out a simple check, is this case real, would have caught it. It wasn’t; it was made up.

I think we’re going to need a much better way of doing fact-checking. You don’t want to have to double-check everything, because then you start asking why you’re using the tool at all. But if you check nothing, you have a huge liability problem. That’s one part.

Then there’s the more obvious risk – letting something run autonomously on a pipeline, which is super dangerous, versus writing a tool or a widget. I’m less worried about models than I am about pipelines.

But the thing I worry about that’s probably less obvious is training and education in the development talent pool. I see people asking, why would I take a coding class? Why would I become a coder? You still need people who write and understand code. So I worry a bit about training for the junior engineers coming up.

Roland Cloutier

I think this is another part of our jobs, honestly. Some of the best CISOs I know are sitting down with their leadership teams, their L1s and L2s, and saying: here’s our organization in two years, you have one year to transform, and your job is going to be X, Y, and Z, which means you need different skills, and so does everyone on your team. Put that plan together.

When you start to see that forward-leaning thinking, it changes the makeup of your organization, not just what you do, but who you’re hiring, why you’re hiring them, and who wants to be there versus not. It’s an interesting time. I think what practitioners used to look for isn’t what we need to be looking for anymore.

Bret Arsenault

No, well said. I was fortunate to be part of a couple of organizations doing job re-architecture, evaluating: do you need a security data scientist, or a data scientist who understands security? Classic scenario. When you take down an entire organization and its function and break it into the tasks and skills required, and take the job titles away, because that always confuses people, and ask: what are the tasks and skills that have to happen for this set of outcomes? It’s incredibly powerful. Once the job titles are gone, you get this long list of tasks, and it becomes a great model for using AI to figure out which tasks are better outsourced to an agent.

A classic example: management skill sets. Management requires compassion, empathy, EQ, IQ, the ability to hire, financial responsibility, all the things you’d expect. But now there’s a different set of things you’re managing, so you need a different skill set. I know you’re going to do a series on this later, so I won’t go too deep, but I think people are most underestimating this: what skills do you really need today, what skills need to evolve, and, more importantly, how do you transition people?

Some people can transition to new skills, others can’t. So you either find people from a new pool, or you change the pool you’re drawing from, and people can opt out, or they might not have the ability to make the change. I think some of the best leaders I know are spending a lot of time in that space, because it’s very different work. And by the way, it’s not the security org driving that change – security is part of it, but it should be part of the overall business plan of the company.

Roland Cloutier

It is – it’s the business value chain and how it’s going to operate, which actually takes me to my next question, because I’m a big value-chain guy. You can’t protect what you can’t see. If you don’t understand your business, how you develop a widget, manufacture it, market it, sell it, protect it, how are you even doing this job?

When you think about the diversified, digital, integrated supply chain we have now, it’s incredible. I’ll show a picture of a value chain from ten years ago next to one today, and it blows people’s minds. So, sticking with that track for a minute: which part of the AI software supply chain concerns you the most?

Bret Arsenault

Of the actual AI supply chain, or the supply chain and what AI is doing to the traditional supply chain?

Roland Cloutier

Let’s just stick with software, it doesn’t have to be AI specifically, though AI will obviously be a major, integrated component, along with your internal and external partnerships that deliver on it. So, the software supply chain in general – what scares the crap out of you the most?

Bret Arsenault

It’s a good question. Just to have some fun with the four-hundred-million-lines-of-code thing – it’s the same as with vendors. You’ll meet someone who says, “we have twenty thousand vendors,” and that doesn’t sound like a lot until you talk to an Amazon and they laugh at the number of vendors we have in our supply chain.

Because of the way AI is integrated into everything we do now, the fourth-tier supplier, the one feeding into all the software you’re getting, has so little visibility from anybody in that chain. It’s super hard. And half the time, they don’t even know themselves that AI is being used in the services they’re buying, which they then deliver to you as a vendor. That’s probably one of the scariest parts to me, the fourth-tier supplier you don’t even know is a fourth-tier supplier.

My hope for the future is that AI capabilities will give us better insight into that. I’ll also go back for a second to something else: what’s going to be genuinely different and impossible versus what’s just going to be the same thing, faster. I don’t need AI to fill out vendor questionnaires faster, that’s fine, but it’s solving a problem, not the right problem.

Roland Cloutier

Yeah, that needs to disappear. It’s a funny thing, I’ve done this exercise with some peers recently where I said, let’s not talk about third-party assessment or fourth-party assessment. Let’s talk about visibility, capability, and accountability when you’re thinking about your partnerships and your digital ecosystem. Don’t think of it as parties, think of it like the old rings, with data in the middle.

From a partnership perspective, on each ring, label whether you have visibility. Label whether there’s a control architecture or understanding that gives you visibility or the ability to impact it. And label whether you have accountability, or whether you’re simply being informed, and how you’d even validate that. It gives people a really unique view of what we have to work on: how do we use AI to pull information in across those dispersed parts of our supply chain, to make better, faster, AI-enabled decisions?

One of our hopes, and you and I have talked about this, is whether access to faster information could let us build a real multi-tier model for our vendors, so that when something happens, the business can shift its value chain to another one. It’s a great, interesting concept, but I agree with you, that’s one of the most concerning areas that has no answer today, and one we have to keep pushing on.

Bret Arsenault

Yeah, but you’ve keyed into something important. Everything up until “I can switch to another vendor” made sense to me, and in one sense I want that independence. But having been a customer of yours at a previous company – we operated in over a hundred and forty countries, and payroll was processed in almost all of them, but we couldn’t get the guarantees we needed in certain countries. The cost of adding one more vendor to solve for four countries was really expensive, but we had to, because of the security bar. We couldn’t just wholesale switch.

There’s this tension between no lock-in with your vendor and optimizing for your vendor. We were optimized for ninety-five percent of the problem, and the other five percent we had to solve a different way. I think people sometimes try to homogenize things so much that they could switch anywhere, anytime, and then they lose the accretive value of the relationship they actually have. It’s a balancing act between how aligned you get and how independent you stay.

It’s important for people to be intentional about how aligned they want to be with any single vendor. The classic example: I could run six different endpoint systems and be completely independent, but I’d spend so much on the overhead of managing them that it wouldn’t make sense. So is the answer one? Probably not. Is it six? Definitely not. Being intentional about that changes a lot, and with the international regulatory changes going on, that’s actually my lead into the other area I’m concerned about: the regulatory space in AI that’s about to happen. It’s going to change a lot of what people are doing. It can’t run with no regulation – I’m not a fan of massive over-regulation either, but the only way to have accountability is to have some level of regulation.

I spent two years working on global policy, so I know how complex it is, but we’re going to see things happen, we’re already seeing them, here in the US and elsewhere. Whatever plan people are working on, even people writing code need to be conscious of how they stay compliant with the areas they want to operate in, and how they’ll need to adapt as those rules change. I’d really want my assistant to tell me: am I compliant with these regulations, and if they change, how much work is it going to be to adjust?

Roland Cloutier

What’s interesting is you bring up the legal issue and these multi-jurisdictional questions around compliance and regulatory frameworks. I want to jump to a question I was going to ask later, but you’ve brought it up, the concept of code provenance. How important is provenance when you’re talking about code, jurisdictions, and the future, this concept of trust and validity? How do you look at that?

Bret Arsenault

It depends on whether you want to use provenance as a shield or a sword. As a shield, I think it’s a great thing. As a sword, it’ll be counterproductive. It’s a fine line – I love the idea of strong provenance, and I think it’s a cornerstone for building trust in the things you’re talking about. But I want to use it as a protection mechanism, not a punitive one, until it’s egregious, and then, of course, you have to do something. But that’s my view.

Roland Cloutier

Okay. Well, how about non-human identities, since we’re jumping into the hard stuff – are AI agents being treated as privileged identities? How do you look at non-human identities in general?

Bret Arsenault

This goes right back to my Morgan Housel point about things being the same as before. The hardest problem to solve at global and cloud scale that still hasn’t been solved is OBO, on behalf of. It’s really an authorization problem, not an authentication problem, and we’ve been living with it forever. That’s how we got into trouble in the first place, with the system account, a cheater way of handling “on behalf of” at a granular level.

Any agent running as a system account is a mistake, the same way letting users run as a system account is a mistake. You need a separate identity type, but going back to my point about tasks and functions, the identity question should really be the same: what is this entity, human or non-human or agent? Is it authenticated, is it actually who it says it is? Is it doing what it’s allowed to do? And is it being audited and tracked, so what it’s doing, and can do, is visible? That’s hard, because every read becomes two reads and a write when you audit something, including successful and unsuccessful attempts.

Roland Cloutier

And by the way, we’re not going to be the ones reading it, it’s going to be another AI agent asserting, investigating, identifying, and taking action.

Bret Arsenault

That’s right. But you still need the construct for how to do it. This is why the logging nightmares we all live with today exist, we’re not outputting in a standard format, so everything has to be parsed and redone. I think there’s an opportunity for identity to be done more cleanly with agents, giving us a more standard way of working with them, there are a few standards being worked on right now. But it’s more than just a non-human account; it needs its own type, its own set of behaviors, and a better way of tracking and auditing, because other agents are going to be acting on it in real time. Instead of a SOC analyst detecting an anomaly and shutting down a vendor account, the denial-of-service potential here is massive.

Roland Cloutier

It is. And that gets me to the question about, I know you hate this term, human in the loop. I’ll say it differently: will human approval gates remain necessary, do you think?

Bret Arsenault

I think until you get enough trust in the system, and accountability for when the system makes a mistake, you’ll still want a human in the loop in high-risk systems. Think about it like intrusion detection versus prevention – everyone wanted IPS systems, but as soon as they started getting outages from them,

Roland Cloutier

Intrusion detection – yeah, they went back to detection, or got rid of it altogether.

Bret Arsenault

Exactly, they went back to the other one. There’s a price to pay for all the oversight you’ll need. I think people forget you need a ton of oversight in these systems, and you want to make it as inexpensive as possible, inexpensive from a compute standpoint, because you don’t want to be burning GPU on your audit capability. It’s expensive, and you already have a token-accounting problem.

You want it to be inexpensive, but you need it to be real-time or near-real-time. I think the two most underserved areas in this space are proper identity management for agentic systems, and data management. I’ve said this before: AI will do for data management what antivirus did for PC management. People will finally take it seriously.

Roland Cloutier

Huge. Yeah, I agree, and I’ve got about fifty more questions on that, we’re not going to have time to get into all of it. But listen, I’ve got a wicked smart guy here. By the way, I don’t think anybody knows this, but Bret and I are both New Hampshire natives, so I can use my deep New Hampshire accent with him and he actually understands what I’m saying.

Bret Arsenault

That’s it, there you go, that’s New Hampshire right there, bud.

Roland Cloutier

He went to school in the same town my mother did, which is really funny. I get to see you all the time, but people don’t always get to see Bret. So, despite you joking about not being the smartest guy in the room, you really are, most of the time, and it’s fun getting these nuggets from you. In our last few minutes, I want to pull some great points out of your brain that listeners can take with them.

So let’s talk about the future. If you went back into the seat tomorrow and were building a new AppSec product, digital ecosystem security, software defense, whatever you want to call it, starting from scratch, what wouldn’t you build?

Bret Arsenault

It’s always easy to think about what you would build, the whole greenfield thing never actually happens. But I certainly wouldn’t build the same quorum process we had for code check-ins, I’d get rid of that and make it all software-driven. I wouldn’t build the same training and awareness programs; I’d build a very different one. I wouldn’t spend as much time on the developer-as-security-person thing, and instead spend that time making the pit of success an actual reality.

And interestingly, on the developer side, I don’t know if I’d spend as much time on the tooling trainings we did. People loved the technical training, but I’d spend a lot more time on systems thinking and critical-capability thinking, on how to design critical systems, than on pure tactical, technical-skill training. Those would be the big things.

Roland Cloutier

Well, let’s flip to the leadership question then: what assumptions won’t matter in three years that you, I, and our peers have made for the last decade or more?

Bret Arsenault

This is where I go back to “same as before.” I don’t think leadership changes much at all here. Leadership is still about getting the right resources for the team, setting the right strategy, enabling teams to do things, making sure training is in place. I still think leadership stays exactly the same, the tactics change.

I still believe the soft skills in senior leadership, how you work with the business, were always the hardest ones for tech people. You still need those. I don’t want to say you don’t need empathy, but agents don’t have feelings, at least not today, so it’s interesting: you still need to be an empathetic leader because you’re still leading people, but how you lead changes.

I had someone on my team, twenty-something years ago, writing a thesis on the rights of machines, he said machines shouldn’t have to work twenty-four hours a day. I thought, what are you talking about? What a prescient guy, twenty years ahead of his time. What are the rights of machines in the systems we’re building? That’s well beyond the scope of this conversation, but I do think about it.

One thing I’d do in leadership: hire a lot more people with social skills and human-centered design skills. I still love STEM, but soft skills are going to matter so much more, in how we land this with everybody, how these systems work, and what it means for people’s job security. The whole junior-developer question is really different now.

Roland Cloutier

It really is. I think the assumptions in leadership that are going to change are around expectations, we set some generic expectations for ourselves, our teams, the business, based on what we think we can and can’t change, and a lot of those are going to shift. Right on point, man. All right, I’ve got to ask you my last question, because it’s that time: if you’re in the seat, what’s the first thing you change in your software factory next Monday?

Bret Arsenault

There’d be so many things, I wouldn’t just change one.

Roland Cloutier

First thing, you walk in, doors open, team sits down: first thing we change today is this.

Bret Arsenault

I’m so focused on this, I’d change the entire review loop of what we do. I’d change the tooling, and I’d get people writing and building tooling, because I think the culture change is a bigger issue for your dev team than the actual technical piece. Part of getting them there is having them work on tooling that isn’t critical to the business.

I’d have them write think papers on how they’d write themselves out of a job in five years, and what their new job would be, force them through that thought process. Not because we’re actually going to do it, but because you’ll realize what you’re really doing is helping them create a new job five years from now. So: how do we prepare you for the job you’ll want to have in five years? I’d spend real time on that in the software factory.

And one more thing: I’d go look at all the money we’ve spent on software tools, code checkers, everything, and reevaluate. I’d assign a team to figure out, of all the tools we have, where we have opportunities to optimize, get rid of, or replace tools with something better. I think there’s a huge opportunity there.

Roland Cloutier

Huge opportunity, huge. This all gives us opportunity. Bret, I can’t thank you enough. When I decided to do this, I called you and said, “Hey, I’m doing a podcast, can we chat like we normally do on the phone?” And you said, why not, we do this anyway. So this is awesome, man. I really appreciate you taking the time.

Bret Arsenault

I’m super excited to do it. I’ll leave you with this: there are a lot of people out there on the doomsday train for developers, and I just don’t buy it, I’ve never seen anything that doesn’t need more people who understand how to write code. Maybe they write it differently, produce it differently. But if you realize, as a developer, that your job is really to enable a business to do something, to enable teams to do more, whether that’s no-code or otherwise, that’s great too.

I’ll honor the past, but it’s not going to work going forward. If I’m honest about where we are today, it’s not going to look anything like this in eighteen months. But I believe that with good leadership, people working on it honestly, and using the tools available, and working a bit with your government, we’ll be in a much better place. I look forward to getting better code, less vulnerable code, across the plethora of systems I use, in the next eighteen to twenty-four months.

Roland Cloutier

There you have it, straight from the horse’s mouth. And don’t forget the three H’s, he’s been beating those into my brain since about 2010.

Bret Arsenault

I guess I can only remember frameworks, I’m not smart enough for anything beyond that.

Roland Cloutier

It seems to work for you, brother, it really does. Well, everyone, thanks for listening. For years, we believed application security was about helping developers write more secure code. As you heard today, that’s changed with the AI era, and it’s changed some of our assumptions. Software is increasingly produced by autonomous systems operating at machine speed, and that’s giving us the opportunity to change our industry, our programs, our organizations, our companies, at machine speed.

Our challenge is no longer securing developers, it’s securing the software factory itself, and that takes an entirely new approach and a new kind of thought leadership. That means understanding identities, pipelines, prompts, provenance, and governance. You heard it all here today, and trust is one of the integrated systems that ties it together. Shift left wasn’t wrong, it simply wasn’t designed for where we are today.

Bret, thank you for joining me, and thank you to everyone listening to Shift to AI. We’ll see you on the next episode.

Bret Arsenault

Thank you, Roland.