Accountable Engineering in the Age of AI  🔗 **Source:** [Accountable Engineering in the Age of AI](https://www.youtube.com/watch?v=6YC0lz46sQw) Hello everyone and a huge thank you for joining us today for our discussion on who's responsible for AI risk. A really deep and provocative discussion on accountable engineering in the age of AI. This panel discussion is going to explore how risk ownership changes in a landscape dominated by AI. We're going to go into all the things team structure, culture, individual responsibility, as well as some of the technical approaches being taken and the capabilities organizations are leveraging today to remain resilient. So, this is a lead dev online panel discussion and it's put on in partnership with chainuard. ChainGuard is the trusted source for open source. They provide hardened, secure, and productionready container images, language libraries, and OS packages that are continuously rebuilt from source. Chain Guard secures the open-source software and dependencies your engineering teams and AI agents rely on so you can build and run applications faster. Stay compliant and eliminate the supply chain risk that often comes with using open source software. So, a little bit of housekeeping before we begin. Our discussion will last roughly 45 minutes and after that myself and our esteemed panelists will head over to the Lead Dev Slack channel. We're going to be in the panel hyphen Q-N and hyphen A channel. And if you missed that, I'll repeat it again towards the end of the webinar. We will also probably take a few questions, so feel free to submit your questions through the Q&A feature on Zoom, but if we don't get to them, we will respond to them in Slack. And now I'm very excited for our panelists to introduce themselves. They come from a a diverse background in startups, scaleups as well as established organizations. So why don't we start with you Aisha then and see and then Alex and I'll tell you a bit more about myself after that. >> Thanks Sar. Hi everyone. My name is Aisha. I'm heading application platform security at an insurance company called Aviva. Uh prior to Viva I have worked in um various different roles within security all the way from governance, security operations, engineering, architecture and the list goes on and many tech companies as well. Uh currently I look after app platform security that also includes cloud and cloud infrastructure as well as data platforms and SAS security. Happy to be here. Hi folks. Uh my name is Mikan. I head of platform engineering at Field. Field is a renewable energy company and we have an in-house automated energy trading platform. Um so my background is from financial services uh aerospace engineering. Uh I'm really excited to be on the panel today as field we're quite early in our geni journey and sort of keen to share some ideas and and and hear some of the questions from the audience as well. Pleasure to be here. >> Yeah. And uh my name is Alex Borage. Um I lead the product security team at Chenguard. Um you've just had a wonderful introduction to what Changard do. Um so yeah, my background is is kind of on that intersection between security and engineering, product security, application security. Um yeah, making sure that the products that we build as an organization are secure and and managing the risk uh for our customers. Um, and yeah, really excited to be here as well. >> That's awesome. Thank you all. And I'm Maxi and I'll be your panel moderator today. A bit about me, I'm an experienced engineering leader who's led multi-year crossf functional transformations and quality, product infrastructure, and front-end platforms where I modernized systems, improved developer velocity, and enabled our platforms to scale to billions of users globally. Now I'm a Stanford certified AI governance executive partner now advising small and midsize executive teams on pragmatic AI governance processes, frameworks and implementation roadmaps to make deploying responsible AI repeatable and scalable. So this discussion strongly aligned with my daily work and the need to manage AI risk across organizations. If you didn't know, and this is coming from lead dev's own reporting, twothirds of organizations report exploits involving vulnerable LLM generated code with similar proportions facing prompt injection incidents and jailbreaks. AI generated code is also linked to around one in five security breaches discovered. and AI coding assistants. Although they can ship code four times faster, their code is often 10 times riskier. So why don't we just get into the discussion? Um I feel like we should start with a a question for everyone. So maybe we'll start with you in Sean, but everyone's invited to chime in. The threat landscape has shifted from static vulnerabilities to highly dynamic risks as we've heard. Agentic AI systems that autonomously generate and execute code, vibe coding that lets non-technical team members create production-like systems and attack surfaces that are dynamically changing in real time. So in this new era of AI risk, how has risk ownership and this idea of accountability changed in the last year or year and a half in your organization? >> Yeah, that's a it's a really good question. Um and I'll answer briefly from our perspective at field. Um so as I mentioned before we're a renewable energy company and so we have a sort of broad um business user set. So we've got folks in product but we've also got folks commercial adjacent and then your sort of classical data scientists and engineers. And I think with a lot of these uh sort of advents we have a lot more folks from the sort of analysis functions from the commercial functions that are able to make contributions. Um and so what risk ownership looks like for us is by and large the accountability still sits um within the engineering function u because we we operate in sort of build it uh own it model. So folks within our organization are getting paged at 3 in the morning if there's a problem. Um, but what that means particularly is that the the sort of QA of the artifacts that that do go out or anything that will run in our production environment sits with us and that means we do a lot of that QA validating that um folks where they're making contributions are fitting in with existing patterns. Um, and by and large people understand what's going into production because they will get pitched for it. Um, so in summary, it hasn't changed the model too much. uh sort of expanded the risk surface if you will or the source of risks uh but in terms of the accountability uh at field it still sits within engineering. >> Thank you Alex. How about you? >> Yeah. Yeah. So I think my experience is is a little bit different in that the one of the key things that I'm seeing changing is um there are now kind of parts of the business outside of engineering like outside of the traditional places where we would build products, features, tools that are now able to to to do that thing to to build new things for customers. Um you know whether this is uh sales folks like vibe coding something putting it in front of a customer or I don't know things like finance building tools for their own internal use, right? So there's just kind of new uh functions that are able to create tools um that maybe don't have the the muscle memory, the culture, the habits of how to build things securely, what things to be aware of, what checks you have to go through. And so um while we want to enable those parts of the business and we don't want to hold anybody back, we the the threat landscape has changed because threats are now popping up in places where as a product security organization we would never previously have looked or as a security organization, right? We would we have traditionally been focused on what is engineering doing? What is coming out of engineering? Whereas now we need to like open up our visibility and our site to the whole organization because new products can come from anywhere which means new threats and new risks can come from anywhere as well. >> I think that's such an interesting uh dynamic. So we're we're going to dig deeper into this but I want to hear from Aisha coming from a more established corporate back background. >> Yeah, sure. So the the the way I've seen is historically and traditionally security uh to be very struggled with ownership as a whole anyway where you know you would have code owners you would have your SDLC you would have your um pipeline packages and supply chain third party all put together so it's um in my point of view um AI speeding up um code development u software development new features is um have added to that existing struggle of ownership and the gate points of where you want to take action to security findings. So um in integrating this security into this new newly um created way of code generating really really fast speed um is is going to be one thing. Another thing is that existing vulnerabilities that u we're seeing across applications and products that we have um have vulnerabilities um uh that could be reachable and exploitable with AI coming in from outside as well that time between a vulnerability is zero day being out and that getting exploited that is just narrowing and narrowing down that means although there is this ownership and speed problems we still need to be even faster in addressing the issues that we're receing. So the struggle is um again placing ownership having accountability and at which points do we um have um security guard rails in the gates that will um look after code vulnerabilities. >> Got it. And so I think what the the theme that I'm or the trend that I'm hearing here is that from a smaller startup like field they kind of just like put that responsibility on edge and then as we get to a scaleup like chain guard the dynamic um gets a little bit more complicated with a little bit more partners uh tackling security and risk accountability and then within the broader corporate function there's a need to move quickly to address these issues. And we're going to tease a little bit more on that in an upcoming question. Uh but for now, I think what's really standing out and maybe what's on everyone's mind is agentic code generation and vibe coding, right? Um we talked about how they increase the software supply chain attack surface in ways that like our traditional software processes really struggle to handle. So the risks are not only dynamic but they're transient and they're everchanging. So when we get down to brass tax, what are some of the con concrete controls or practices that you have seen effectively reduce this expanded risk especially you know that context of having non-technical team members contributing generated code. So Alex why don't we start with you and then follow up with Aisha. Yeah. So I think you know as you've said the the speed at which things change is is now operating at a different scale than it was before. Um you know where previously you might have been able to run some security scanning tools or or be able to get a snapshot of the state of your organization the state of your enterprise. uh like we have seen from the recent attacks you know just in the last few weeks we've had the kind of high-profile attacks on on Triby and Axios and other organizations that like dependencies get introduced and then they're exploited in a matter of minutes before you're even aware that those are dependencies of your organization. And so it becomes much less around kind of managing your sbombs kind of peace meal and much more about what systems do you have in place, right? Your your security posture is no longer like how much red and how much green do you have on your dashboard. It's what systems do you have that are operating at machine speed to protect those things. Um and you know to your point about what do we do about new parts of the organization that are maybe engaging with with activities that they didn't before. I think the the key thing that the way that chain guard is approaching this is you know we make the the easiest path we make the default path the safe one and if somebody is able to do something then then they are allowed to do it right so we put in place tooling so that you know whoever whoever you are in our organization if you're able to build something if you're able to publish it then we have put the safeguards in place to make sure that that is then secure um so we don't have to rely on education we don't have to rely so much on culture building, you know, it's the the tooling is there to support people um and and enable the business to operate as fast as it can do. >> So, permissions based or rule-based tooling capabilities. >> Yes. But also, you know, permissions about uh what goes out the door, right? like we have automated controls in place to make sure that before you know something that is built in our CI pipeline is is published and pushed to a customer that it has gone through the required checks that we've validated the sbombs that it is pulling its dependencies from the right place all of that sort of thing as well. >> Got it. Brilliant. Okay, Aisha. >> Yeah, I mean I would I would look at it you we've got to get the basics right. Okay. All the essentials. So leaving um AI aside, are we doing what we're supposed to be doing? which um we should have been doing yesterday anyway. So do we have the right uh checks in place? Are we starting from clean slate? So for example, the likes of chain guard or really lean images and third party libraries that you don't need but you're inheriting the vulnerabilities from there. So get those really really clear and right from the beginning. Then inventoring of course because what it's one thing where you have known vulnerabilities that you're checking against. It's another thing when a zero day comes in and the time it takes for you to respond to that right. So know exactly what is where and how it it is going to get impacted with with enhanced context. So of course you know your inventorying which show where you you want to go for sbombs or even enhanced platform views that will really help. And the other one is utilize AI in those checks as well. So you know if if the code is moving at AI pace which is machine pace then you got to move it machine pace to catch up with that. So wherever we're putting in guard rails or deny by design deny explicit deny anywhere on that on the pipeline where we're introducing new code. Um we've got to make sure that we have that really quick. um response to it. We don't necessarily want to slow down teams at all, but we also want to have relevant enough gates everywhere where we can plug in um and uh and um whether it is being proactive or we need to respond, we have those gates available to us. Um, one other thing I've seen from traditional application development platforms or dev platforms of Saudi pipelining is CLC all that you know niceness we have and it's sort it's at least to me sort of a little bit clear as to how this would work out in a more speedy fashion with AI generated code um and AI generated um newly introduced attacks. It's another thing when we're looking at a lot of um puzz platforms SAS >> with low code being introduced with AI enabled on top of it as well. they don't necessarily fall within the our traditional SDLC um and um and the security controls and they also cannot be compatible with those security controls and we just need to make sure that we we are kept up with that as well and we will be seeing more and more organizations relying on uh platform specific AI generation or low code environments um that's definitely top of my mind >> absolutely so it sounds like you take a principles based approach, right? where you start with like what do we have a risk assessment an inventory getting good and strong on the basics of security and then you build on top of that um responding to every dynamic part of AI like low code and no code platforms for example and I think we're going to hear more about that approach as we get further into the webinar but I think that that's such an interesting contrast um especially when we think about a larger more established organization versus uh an organization uh that's a scale up. So awesome response and what since we talk about a a scale up and an established corpor corporate background I think I want to take it back to kind of the startup point of view and so I I'd like to start with you on this question in see and in a resource constrained startup and maybe if we're all managers I think we can all identify with the feeling of being resource constrained but how how have you restructured teams and rituals so that risk ownership doesn't become diffuse when non-engineers use agentic tools or vibe coding to build and deploy or just generally anyone using different AI tools. What practical patterns help maintain accountability without killing speed, especially as these new risks appear that didn't exist in traditional development? No, thanks. That's a really great question. I guess um for a bit of extra context, uh so within field the platform I mentioned before, the in-house energy trading platforms, it's fully automated and so this is very much an internal business application. It doesn't have um sort of average customers in the conventional sense. Um and the energy industry at least where we operate is regulated. So, so we have some requirements to be able to there's a lot of explanability required in our systems. Um, and so I give all of that as context um because it then helps frame the kinds of contributions um that we have and the model that works. Um so in our context where we have non-engineers using agentic tools um generally this tends to pop up in areas where it's sort of some analysis some analytics um sort of SQL procedures that sort of thing to try to slice and dice data in multiple different ways um or contributions on say we have an internal web application that's used for controlling uh the trading platform um and so generally there's a there's a bit of sort of onboarding for for non-engineers so that they have a an understanding of patterns etc. And so I think in terms of the structure of the teams I think we've just taken a lot of learnings that we've had in the whole sort of agile space of folks still using that term in general about putting cross functional groups together um so that they understand one another's context uh and what they need to work on. So what that means for non-engineers is um you know rather than have a a PR came out was thrown over the wall landed in CI and no one really knows why it's there just sort of having that open dialogue about sort of what's the problem you're trying to solve and talking through through approaches because yeah the thing to bear in mind is that um but some of these folks they won't be familiar with the patterns they won't be familiar with the code base uh code bases and best ways to solve that so I think some of the good patterns we've just discovered over, you know, the past decade or two about how individuals work well together still still work here. Um, and so to talk about, um, the sort of risk ownership, um, when we're talking about really critical parts of the energy trading platform, particularly places that need to be audited, um, what we found is that actually those tend to be left to the engineers and the technical folks just because of the level of criticality required in the application. Um, so that's generally that's generally how it seems to work for us. So where things are lower risk, the contributions are very very much welcome and and it's easier to ramp folks onto that. Um, where the level of criticality is super high, generally the sort of the context you need to be able to understand what to do or to make improvements is quite high. It's basically doing the job. Um, and so we we find that there's less risk introduced um in those areas of um of our platform. >> Got it. So it's a riskbased approach. I think that's really interesting. Alex, how is it over at Chingard? >> Yeah. So I think maybe to come at this problem from a slightly different direction. I think we as the security industry have have been kind of fighting a losing battle over like building uh habits and and and building skills and educating nonsecurity specialists. you know, we we've kind of been losing that battle for the last, I don't know, two decades, maybe longer in in, you know, security training is something that people don't really engage in. They don't really learn from. It doesn't really change their habits and their behaviors and and so now if we're trying to roll that out to, you know, people outside engineering or or maybe, you know, some of the non-traditional parts of the org, like I think that that barriers and those hurdles just get higher and higher. So I think what this does is give us an interesting opportunity to to come about this from a different angle and say rather than trying to build the culture in the humans in our business, we can try and build the behaviors that we want to see into the AI agents themselves. um particularly as we're seeing the growth of skills um and the you know org level instructions that we can give to our AI agents we could that's where we can now plug in the behaviors that we want to see the behaviors that we don't want to see and that enables us to uh kind of level up as an organization in a way that is invisible to the people using it and in a way that feels frictionless and and to your original question you know we're all resource constrained you know I can create some prompts and then roll those out to everyone's AI agents much much faster than I can you know get 100 people on a call and and do some training with them and and level them up. >> Got it. So the team scale it's no longer getting approval for another engineer. It's like okay we need another 10 agents to execute XYZ thing. And I I completely hear you. I uh there's a lot of discussions happening around security overall. Some people want to take it towards security appreciation versus a typical uh security training. So, it's really interesting to to hear more about this as well as what you said about building the oversight behaviors you kind of want to see into the AI agents themselves. I think that's pretty innovative. Um, so I don't want to leave it there because I definitely want to hear about how does all of this translate when you're working in a in a more established corporation like such as insurance. So, Aisha, what is this um h how does how is this changing for you? So I'm curious specifically about the corporate context and agentic risk like have they increased cross team collaboration for you and if so which teams now work more closely >> and what the impact of product development cycles. Yeah, I think that with many organizations um on a on a startup scale up scale I presume there there are a lot of teams that may wear multiple hats where it requires collaboration um um uh across team methods where where you scale out in very large corporations and organizations um the the boundaries are a little bit more defined. So when you bring um agent AI or AI agents into your existing you know applications platforms uh you know products that you have etc it definitely pushes the boundaries on that. So what I what I what I have seen is um we're seeing more and more teams that wouldn't um otherwise talk to each other starting talking for example dev and business units um where um the there is a shortcut from like I said from where it would be a product feature now it is an agentic workflow uh um in the um in the back end and I've seen a lot more moving around data platforms data teams as well. So we I'm seeing more and more push for well um collaboration uh that is can't be helped. Uh it's the conversations that needs to be had um in order to define you know it's architecture how it's going to be implemented who's doing what and the question of ownership definitely comes up uh in those which leads to more conversations I guess. >> Absolutely. But does it have you seen it impact product development cycles or is it a situation where it cannot impact product development cycles like a deadline's a deadline or is there room? Uh it's I've seen a push um bring forward deadlines uh where um we have seen change in in collaboration where we've seen we've identified we could be more efficient etc. But it's not necessarily um something that sort of redefined um how we dealt with SDLC in at least in this large scale. >> Got it. >> Thank you for that context. And so I think um now is a great time to remind the audience if you're here and have a question definitely use the Zoom Q&A feature and we'll see if we can work them into our discussion today. Um, so Aisha, I'm bringing this back to you because I'd love to hear more about implementing guard rails for dynamic risks. And what what I'm talking about here is like at platform scale. Uh, we talked about the dynamic risks of agentic systems. We talked about agentto agent interactions, real-time code execution, even shadow agents, right? We we have this kind of problem in the industry of people using maybe not approved AI tools, for example. And so when you think about that dynamic set of risks, what capabilities or guard rails have you and your team implemented? This could be observability, identity for agents, escalation paths. What have you implemented that organizations of any size could retrofit into their plan? >> Yes, certainly. So like I said in the previous question as well, we've got to make sure we get the basics right. Okay. So if you we don't have the foundation fundamentals in place with a agentic AI or AI agents coming into which whichever various form or AI generated code coming in it's it will only heighten existing existing risks um and it will um uh have an impact on the blast radius. So what we've done is um review of what what gaps have we got um in terms of all things security and that is from are we um logging in correctly? Have we got uh necessary controls in place? Are we covering um uh vis do we have visibility everywhere? And um of course with anything like the question of shadow agents where they popping up from um depends on uh again your existing security controls. If you're a little bit more relaxed organization where you have um um um where you allow a lot more autonomy to teams to bring in apps and um and solutions or even um on on their desktop uh device. you'll find a lot of that um in large in my organization it was quite restrictive to begin with. So we've got a good handle of you know what we think uh is coming in however it doesn't necessarily mean that we have the full visibility. So visibility is absolutely the most important. And the other ones is security controls we need to consider um as new security controls with um uh use of genai and agentic workflows and um AI agents being used whether it is something that we're building on our own platforms or it is that we're third party solution are we doing whatever is necessary in terms of its the guardrails we need to embed into those LMS and the output Are we testing it right? And I think it's not necessarily just a security question. It's a a platform DevOps and um product management wide. How do we now test um the output in a in a way that we can rely on. So of course there will be a lot of security testing that we've been doing um AI specific security testing um problem injection attempts perhaps adding in another LLM on top of another LLM that will look at um security of the output in very risky situations. So we've considered all options with a risk um uh profile uh consideration where the risk is really high going with more restrictive controls. Um I've also recently started looking at enhancing existing security posture management we have with AI visibility. So um so if you're using any existing security uh tools you can ensure that they will be covering um the likes of cloudbased um AI platforms um its configuration um its um um uh attack surface etc etc. >> Gotcha. Okay. So it's it's a multi-pronged approach that even with AI now you're seeing the need to partner across the organization particularly to hit reliability and resilience targets but it's still like the foundation of it all is that principles-based approach you talked about about getting the basics right I think that's interesting now I'd love to kind of contrast that a little bit and hear from like a smaller startup so in seeen are there specific implement uh specific speific guardrails that you've implemented or seen implemented within your organization? >> Yeah, it's a good question. Um, so as I mentioned before, we're we're quite early on in our journey and one of the main areas that we're starting to focus on um is having uh agents perform some ad hoc maintenance tasks on our trading platform. Um so an example scenario this is you know we sometimes have maintenance windows on the exchange and and there certain there's certain requirements in terms of how our clients need to behave around these events. Um the notifications are quite dynamic. Um and so we're thinking about actually can can agents just take care of this rather than you know the on call uh team member needing to manage this and and handhold it. Um and what we're thinking about specifically around that is observability. um that's really really crucial for that kind of context. Um and particularly um thinking about identity and access management. So sandboxing as much as we can. Um it's no no different to how we manage any other application and thinking about actually what what privileges uh the identity that this agent will be be running on this host environment. But what privileges will it have? others privileges. We're comfortable with it having elevated controls by default just denied. Um and and the same applies as well for for members of our development teams where folks might be running things like cloud code or or codeex locally on the desktop. What what authentication credentials have they got set up locally? because I mean this is working on on the file system and we've all read the news articles about agents that didn't ask for permission before they did the thing or the AWS case about certain environments getting getting deleted and and that that's very very likely when you have these inheriting credentials that that humans have. So for us, we're thinking about how do we audit the credentials that our local teams have so that actually if they are running things like codeex, it is safe or at least the roles that have been assumed at that time are appropriate for the level of work required. >> Got it. So it sounds like uh there's a use of agents right now for per performing ad hoc maintenance task, but there is a broader plan to incorporate agents into things like AM identity access management and observability. Awesome. Uh, okay. I don't see any questions. So, we'll continue with the Q&A that we have here. And I might combine because we're at the 35 minute mark. So, I might combine the last two questions um just to get like final input from everyone before we open it up to broader Q&A. So when we think about individual and cultural accountability in a new risk category right how do we redefine personal and team level responsibility in this dynamic environment so that velocity doesn't come at the expense of accountability and let me see I I just made you talk for a bit in see so maybe I'll start with Alex on this and Alex if you could close with what's one one new practice someone could take away today and implement over the next 90 days. >> Yeah. So I think you know we've talked a little bit about uh vulnerabilities now operating at machine speed and our need for like our defensive and and our controls to operate at machine speed as well. So I think thinking about this in terms of like what are the responsibilities of of individuals in our organization is is maybe not the right way to think about it. Right? It's it's a case of understanding that no humans are going to be able to keep up with the new threat landscape. And so it's maybe a case of uh educating or reorientating people that that that that will kind of necessarily be too slow to be able to keep up with what we're looking at. So, you know, shifting that responsibility onto AI agents, onto tools, onto systems that we have in place that operate at machine speed and that that don't operate at human speed. um I think is kind of how we need to think about accountability. It's not the people that are accountable for things, it's the tools that we put in place that are now accountable for them. Um and yeah, to wrap up uh I think you know one very concrete uh change that people could make is in terms of uh understanding their supply chain security and and you know moving on to uh something that removes vulnerabilities, removes risks before they're even introduced. Um, so I'll I'll do a little plug for chain guard here. I think, you know, rather than, you know, previous model where you might want to monitor vulnerabilities as they're introduced, triage them, respond to them, and then remove them. We've seen that that entire model just doesn't work anymore. You can't keep up. So, you know, shifting over to something like Changard where we will remove those vulnerabilities before they're even introduced into your environment. Um that's just one example of of the way that we need to think about uh reorientating the speed at which we're operating. >> Awesome. So addressing the risk upstream like before it even gets to you. >> Exactly. >> Okay. Cool. Uh Aisha, what's one thing and then I'll come to you and see, but what's one new practice or capability that's uh an audience member or someone viewing this webinar that they could take away and implement in the next 90 days? I sorry I was on mute. I was um thinking of picking one. I couldn't make a decision between two. Um so definitely one very very practical um advice I can give is um if you're a large organization where you have concerns around AI use and visibility start with an AI register and ownership register. Um as um easy as it seems it's a and is as um manual as it looks. a good place to start to understand how your organization is utilizing AI and that is in many different flavors, right? AI for enterprise, AI for um productivity within the organization. It could also be AI used for code generation as well as agentic AI and AI agent use as part of your products. So have a registered and treat it like treat it like you would to any security uh uh risk and inventorying of your assets. Um if you cannot get this via API at least do it manually it's better than nothing. Another thing is definitely and definitely look at your back end look at your data architecture and ensure your authentication authorization workflows that you're assigning are getting it right. Um that's that's one thing that I can uh two things that I can provide as advice. >> Two for the price of one. I love it. And so in so we'll close with you here now before before you share like your one suggestion for 90 90day takeaway. I'm curious um when you think about your first-line managers, when you think about your staff engineers, your IC's, I'm curious about what does good look like for you in that dynamic environment. Right? We heard Alex talk about um security and accountability is like something humans won't be able to keep up with. We've heard Aisha talk about um starting with the basics and getting those right like with an AI register. What does good look like for you? and then definitely let us know what's your uh 90-day takeaway that people can implement. >> Sure, absolutely. I think on the topic of what good looks like for me, I think uh having staff, engineers, having you know leads, building systems that make this easy for people. I think on on subjects like security, I think that's generally always been true. um as much as we can build systems and whether that's processes that are automated or or guidelines that we would generally have folks follow um I think that that for me still remains the the benchmark of what is good um and I think you know Alex gave a really good answer there about um humans not being able to to cope with the pace of change and so I think it makes sense to build more systems you know the more automation that helps make this easy for people the better um and then I think on the subject of sort of 90-day takeaways. I think what I'm thinking about a lot these days is about the sort of the the respond and and recover aspects of of the NIST framework, for example. Um, and I think, you know, how do we build LLM capabilities that make that side of things easy? Um, I think there's only so much that you would be able to sort of prevent in the in the first place, but actually how do you make that sort of response that response and recovery quite easy um when you when you have these security incidents. So, I think that would be the sort of the main thing I'd be thinking about. >> Okay, got it. Thank you. But no, response and recovery being a a near-term goal, but no specific tool. Just kind of like addressing it internally. >> Uh, I'd be thinking about tools. So for example um you know normally organizations would have a sort of incident playbook for example what happens if we have a vulnerability or a breach of some sort I'd be thinking about how do we how do we make that playbook executable faster right is this can we build a capabilities to actually make >> managing the recovery of internets a lot faster than it would ordinarily be because if the threats if the threats are faster than human speed then I think similarly our or response and recovery for any incidents needs to match that as well. >> Got it. So basically incident playbook at agentic scale. >> Yeah. Oh, that's that's a sound bite if I ever heard on. Yeah, that's right. >> Awesome. Thank you. Uh as we close out, let me check to see if we have questions. Uh now is a great time to ask your questions. Uh or come hang out with us in the Slack channel panel hyphen Q-N and A and the Lead Dev uh Slack channel. But what you essentially heard today and learned today, we covered the surface area of risk uh that AI introduces, the controls our experts have implemented to manage these risks, how they've thought about restructuring their teams, and redesigning partnerships across the organization to address these challenges, implementing guardrail to account for dynamic risk and cultural and individual responsibility. So, thank you so much for all of the good insights in today's panel. Panelists, please give yourselves a round of applause and let's head over to the leadv Slack and thanks again chain guard for sponsoring this webinar. Thank you and see you next time. Thanks everyone., Accountable Engineering in the Age of AI, YouTube, 01kqzegfjhc3jmqcbtkdz4ekfx.