Accountable Engineering in the Age of AI - CourtneyR.dev's 2nd Brain

Accountable Engineering in the Age of AI ![rw-book-cover](https://img.youtube.com/vi/6YC0lz46sQw/maxresdefault.jpg) 🔗 **Source:** [Accountable Engineering in the Age of AI](https://www.youtube.com/watch?v=6YC0lz46sQw) > [!note]+ Document Notes > tags: #ai-security #software-security #platform-engineering #risk-management #ai-governance #supply-chain-security #agentic-ai #incident-response > author: Lead Dev > source: YouTube > reference: https://www.youtube.com/watch?v=6YC0lz46sQw > date created: 2024-12-20 18:47 > > # 🏷️ Title: Accountable Engineering in the Age of AI >  ## 🧰 Action Inbox - [H1] Create AI register and ownership inventory — manual tracking better than no tracking #ai-governance - [H2] Implement upstream vulnerability prevention systems — address risks before they enter environment #supply-chain-security - [H3] Develop machine-speed incident playbooks for agent-driven response — human response too slow #incident-response ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Lead Dev Panel Discussion](https://www.youtube.com/watch?v=6YC0lz46sQw) - [ChainGuard Security Platform](https://chainguard.dev/) ## 📝 Summary - Panel discussion on how AI transforms risk ownership and accountability in engineering organizations - Three perspectives: startup (Field renewable energy), scaleup (ChainGuard), established corporate (Aviva insurance) - Key insight: Traditional security models fail at AI's machine speed - need automated controls and systems - Risk surface expands beyond engineering to business users creating production systems via vibe coding - Practical approaches range from AI registers to upstream vulnerability prevention ## 📖 Main Content The threat landscape has fundamentally shifted from static vulnerabilities to dynamic, machine-speed risks. Two-thirds of organizations report security exploits involving vulnerable LLM-generated code, with AI coding assistants producing code 4x faster but 10x riskier than human-written code. The panel explores three organizational contexts: Field (startup) maintains engineering ownership despite expanded contributor base, ChainGuard (scaleup) faces new threats from non-technical teams building customer-facing tools, and Aviva (corporate) sees accelerated timelines but persistent ownership challenges. Key themes include the failure of human-speed security controls, the need for machine-speed defensive systems, and practical approaches like AI registers, upstream vulnerability prevention, and automated guardrails embedded in development workflows. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/6YC0lz46sQw?t=0) — [H1] AI Risk Statistics and Panel Introduction - Key idea: Two-thirds of organizations face LLM exploit incidents with significant security impact - Evidence: "AI generated code is also linked to around one in five security breaches discovered" #### ⏱️ [05:23](https://youtu.be/6YC0lz46sQw?t=323) — [H2] Panelist Introductions and Organizational Context - Key idea: Three different organizational scales provide diverse perspectives on AI risk - Evidence: Aisha (Aviva insurance), Mikan (Field renewable energy), Alex (ChainGuard security) #### ⏱️ [08:15](https://youtu.be/6YC0lz46sQw?t=495) — [H1] Risk Ownership in Dynamic AI Environments - Key idea: Accountability models must adapt to expanded risk surfaces and new contributor types - Evidence: "Risk ownership and this idea of accountability changed in the last year or year and a half" #### ⏱️ [12:30](https://youtu.be/6YC0lz46sQw?t=750) — [H3] Field's Build-It-Own-It Model for AI Risk - Key idea: Engineering retains ownership despite non-technical contributors using AI tools - Evidence: "Folks within our organization are getting paged at 3 in the morning if there's a problem" #### ⏱️ [15:45](https://youtu.be/6YC0lz46sQw?t=945) — [H2] ChainGuard's Cross-Functional Risk Challenge - Key idea: AI enables non-engineering teams to create customer-facing products without security expertise - Evidence: "Sales folks like vibe coding something putting it in front of a customer" #### ⏱️ [19:12](https://youtu.be/6YC0lz46sQw?t=1152) — [H1] Corporate Struggle with Accelerated AI Timelines - Key idea: Existing ownership problems compound when AI accelerates development velocity - Evidence: "Time between a vulnerability is zero day being out and that getting exploited that is just narrowing" #### ⏱️ [22:34](https://youtu.be/6YC0lz46sQw?t=1354) — [H2] Machine-Speed Controls for Dynamic Risks - Key idea: Security controls must operate at machine speed to match AI-generated threats - Evidence: "Dependencies get introduced and then they're exploited in a matter of minutes" #### ⏱️ [25:18](https://youtu.be/6YC0lz46sQw?t=1518) — [H3] Make Safe Path the Default Path - Key idea: Automated safeguards should enable rather than block AI-assisted development - Evidence: "We make the easiest path we make the default path the safe one" #### ⏱️ [28:47](https://youtu.be/6YC0lz46sQw?t=1727) — [H1] Foundation-First Approach to AI Security - Key idea: Organizations must secure fundamentals before addressing AI-specific risks - Evidence: "We've got to get the basics right. All the essentials. So leaving AI aside, are we doing what we're supposed to be doing?" #### ⏱️ [32:15](https://youtu.be/6YC0lz46sQw?t=1935) — [H2] Team Restructuring for Cross-Functional AI Development - Key idea: Cross-functional collaboration increases when AI enables direct business-to-engineering workflows - Evidence: "Dev and business units where there is a shortcut from where it would be a product feature now it is an agentic workflow" #### ⏱️ [35:42](https://youtu.be/6YC0lz46sQw?t=2142) — [H3] Building Security into AI Agent Instructions - Key idea: Embed security behaviors in AI agents rather than training humans - Evidence: "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" #### ⏱️ [39:08](https://youtu.be/6YC0lz46sQw?t=2348) — [H1] AI Register as Practical First Step - Key idea: Manual inventory of AI usage provides essential visibility for large organizations - Evidence: "Start with an AI register and ownership register... treat it like you would to any security risk and inventorying of your assets" #### ⏱️ [42:30](https://youtu.be/6YC0lz46sQw?t=2550) — [H2] Incident Playbooks at Agentic Scale - Key idea: Response and recovery capabilities must match machine-speed threat velocity - Evidence: "How do we make that playbook executable faster... if the threats are faster than human speed then our response and recovery needs to match that as well" ## 📚 References - [Lead Dev Panel Discussion](https://www.youtube.com/watch?v=6YC0lz46sQw) - [ChainGuard Security Solutions](https://chainguard.dev/) - [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework) ## 🗣️ Paraphrase - Traditional security models break down when AI operates at machine speed, requiring automated controls that match threat velocity rather than human-based processes - Risk ownership becomes complex when non-technical teams can create production systems through vibe coding, necessitating cross-functional collaboration and embedded safeguards - Practical implementation starts with basic security fundamentals and AI visibility through registers, then builds machine-speed defensive capabilities and incident response systems ## 📰 Newsletter **AI Security at Machine Speed: Rethinking Risk Ownership** Engineering leaders are grappling with a fundamental shift: AI-generated code creates vulnerabilities faster than humans can detect them. This panel discussion reveals practical strategies from three organizational contexts. Key insight: Make the safe path the default path. Instead of training every team member on security, embed safeguards directly into AI agents and development workflows. **Immediate actions:** - Create an AI usage register (even manually) - Implement upstream vulnerability prevention - Build machine-speed incident response playbooks The future of secure development isn't about slowing down AI—it's about security systems that match AI's velocity. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer education: Create AI security workshops covering agentic risks and vibe coding safeguards - Developer experience: Integrate security checks into AI-assisted development workflows and IDE plugins - Developer marketing: Promote secure-by-default AI development patterns and toolchain recommendations - Community management: Moderate discussions around AI security practices and incident response #### OSPO - Policy & Governance: Develop AI agent usage policies and cross-functional responsibility matrices - Security Management: Implement upstream vulnerability scanning for AI-generated dependencies - Software Inventory: Extend SBOM tracking to include AI-generated code and agent interactions - Developer Support: Provide AI security training and automated safeguard tooling - Strategic Alignment: Establish KPIs for machine-speed threat response and recovery #### Community - Maintainers: Support governance templates for AI-assisted development and security practices - Contributors: Create onboarding programs for AI security awareness and safe coding practices - Sponsors: Fund security tooling and automated safeguard development for open source projects #### WordPress - Core: Integrate AI security considerations into development workflows and code review processes - Core Performance: Profile AI-generated code for performance and security impact - Security: Develop automated scanning for AI-generated vulnerabilities and prompt injection risks - Documentation: Create AI security guidelines for plugin and theme developers - Community: Establish AI security working groups and incident response protocols ## 🧪 Hypotheses - Organizations with machine-speed security controls will have 60% fewer AI-related security incidents than those relying on human-based processes - Cross-functional AI development teams will identify security issues 3x faster when using embedded safeguards versus traditional training approaches - Companies implementing AI registers and upstream prevention will reduce vulnerability exposure time from days to hours - Incident response capabilities that match AI threat velocity will minimize breach impact by 75% ### 📊 Methodology - Comparative analysis of security incident rates across different organizational security models - Time-to-detection studies measuring human versus machine-speed security controls - Cross-functional collaboration effectiveness surveys before and after AI safeguard implementation - Incident response time analysis for traditional versus agentic playbook execution ### ❓ Questions - How can organizations balance AI development velocity with comprehensive security without creating bottlenecks? - What specific metrics should teams use to measure the effectiveness of machine-speed security controls? - How should incident response playbooks evolve to address agent-to-agent security interactions and cascading failures? ### 🔮 Future Research - Development of standardized AI security maturity models for different organizational scales - Investigation of cross-organizational AI threat intelligence sharing mechanisms - Study of human-AI collaboration patterns in security incident response and recovery ### 💡 Implications - Practice: Security teams must shift from reactive monitoring to proactive upstream prevention systems - Policy: Organizations need new governance frameworks that account for non-technical teams creating production systems - Security: Traditional vulnerability management models require fundamental redesign for machine-speed threats - Education: Security training must evolve from human-centered to AI-agent-embedded approaches - Funding: Investment priorities should favor automated safeguards and machine-speed response capabilities ### 🧠 Learning Styles Assessment Reading level estimate: 12th Grade #### 👀 Visual learners - Present: Panel discussion format with multiple organizational perspectives - Improve: Risk surface diagrams, AI threat landscape visualizations, organizational structure charts #### 🔊 Aural learners - Present: Full video discussion with expert dialogue and Q&A format - Improve: Shorter audio segments focused on specific implementation strategies #### 🗣️ Verbal learners - Present: Clear terminology definitions and practical examples from each organization - Improve: Glossary of AI security terms and analogies comparing traditional vs. AI-era security #### 🧩 Kinesthetic learners - Present: Practical 90-day implementation suggestions and hands-on recommendations - Improve: Step-by-step checklists for AI register creation and security control implementation #### 🧠 Logical learners - Present: Risk assessment frameworks and organizational comparison matrix - Improve: Decision trees for security control selection and risk prioritization flowcharts #### 🧑‍🤝‍🧑 Social learners - Present: Multi-perspective panel discussion with cross-functional insights - Improve: Facilitated workshop guides for cross-team AI security planning sessions #### 🧘‍♀️ Solitary learners - Present: Individual reflection prompts about organizational AI readiness - Improve: Self-assessment tools for AI security maturity and personal implementation planning #### 🌿 Naturalistic learners - Present: Ecosystem thinking about interconnected AI security risks - Improve: Broader context about AI security's role in digital infrastructure resilience ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading hierarchy and logical content structure - Improve: More descriptive timestamps and section labels for navigation #### Keyboard navigation - Present: Standard video player controls and text-based transcript - Improve: Chapter navigation and skip-to-section functionality #### Contrast and readability - Present: High contrast text and clear visual hierarchy - Improve: Larger text options and improved color coding for risk levels #### Text resizing and reflow - Present: Responsive design supporting zoom functionality - Improve: Optimized layout for various screen sizes and zoom levels #### Media and captions - Present: Full transcript available for video content - Improve: Synchronized captions and downloadable transcript options #### Forms and interactions - Present: Simple Q&A submission interface - Improve: More accessible form validation and error messaging ### 🌍 DEIB Assessment #### Cultural breadth - Present: Multiple organizational contexts and international perspectives - Improve: More diverse geographic examples and cultural security considerations #### Inclusive language - Present: Professional, accessible terminology with technical definitions - Improve: Plain-language summaries and reduced technical jargon #### Neurodiversity support - Present: Well-structured content with clear section breaks - Improve: More visual breaks and varied content presentation formats #### Representation - Present: Diverse panel with different organizational roles and backgrounds - Improve: More gender balance and varied industry representation #### Psychological safety - Present: Respectful discussion of security challenges and mistakes - Improve: More emphasis on learning from failures and collaborative problem-solving ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Panel provides logical progression from problem identification to solution implementation - Inductive strength: Multiple organizational examples support broader conclusions about AI security trends - Causal reasoning: Clear cause-and-effect relationships between AI adoption and security risk changes - Analogical strength: Effective comparisons between traditional and AI-era security approaches #### Fallacies - Appeal to Authority: Some reliance on panelist expertise without supporting evidence, but mitigated by practical examples - False Dichotomy: Occasional oversimplification of security versus speed tradeoffs, needs more nuanced discussion #### Tone of voice - Overall tone: Professional and practical with collaborative problem-solving focus, appropriate urgency without alarmism ### 🛡️ DARVO Analysis - Deny: No defensive denials present - panelists acknowledge security challenges openly - Attack: No attacks on critics or security concerns - constructive discussion throughout - Reverse victim/offender: No victim blaming - focus on systemic solutions rather than individual failures - Emotional cues and rhetoric: Balanced presentation with appropriate concern but solution-focused approach ## 🎯 Conclusion The fundamental shift to machine-speed AI threats requires organizations to abandon human-centered security models in favor of automated, embedded --- ## Full Transcript [00:12] Hello everyone and a huge thank you for [00:15] joining us today for our discussion on [00:18] who's responsible for AI risk. A really [00:22] deep and provocative discussion on [00:23] accountable engineering in the age of [00:25] AI. [00:27] This panel discussion is going to [00:29] explore how risk ownership changes in a [00:32] landscape dominated by AI. We're going [00:35] to go into all the things team [00:37] structure, [00:38] culture, individual responsibility, as [00:41] well as some of the technical approaches [00:43] being taken and the capabilities [00:45] organizations are leveraging today to [00:47] remain resilient. So, this is a lead dev [00:50] online panel discussion and it's put on [00:52] in partnership with chainuard. [00:55] ChainGuard is the trusted source for [00:57] open source. They provide hardened, [01:00] secure, and productionready container [01:02] images, language libraries, and OS [01:04] packages that are continuously rebuilt [01:07] from source. Chain Guard secures the [01:09] open-source software and dependencies [01:11] your engineering teams and AI agents [01:14] rely on so you can build and run [01:16] applications faster. Stay compliant and [01:20] eliminate the supply chain risk that [01:22] often comes with using open source [01:24] software. So, a little bit of [01:26] housekeeping before we begin. Our [01:28] discussion will last roughly 45 minutes [01:31] and after that myself and our esteemed [01:33] panelists will head over to the Lead Dev [01:36] Slack channel. We're going to be in the [01:37] panel hyphen Q-N and hyphen A channel. [01:42] And if you missed that, I'll repeat it [01:43] again towards the end of the webinar. We [01:47] will also probably take a few questions, [01:50] so feel free to submit your questions [01:52] through the Q&A feature on Zoom, but if [01:55] we don't get to them, we will respond to [01:57] them in Slack. And now I'm very excited [02:00] for our panelists to introduce [02:02] themselves. They come from a a diverse [02:04] background in startups, scaleups as well [02:07] as established organizations. So why [02:10] don't we start with you Aisha then and [02:12] see and then Alex and I'll tell you a [02:14] bit more about myself after that. [02:18] >> Thanks Sar. Hi everyone. My name is [02:20] Aisha. I'm heading application platform [02:23] security at an insurance company called [02:25] Aviva. Uh prior to Viva I have worked in [02:29] um various different roles within [02:31] security all the way from governance, [02:33] security operations, engineering, [02:35] architecture [02:37] and the list goes on and many tech [02:39] companies as well. Uh currently I look [02:41] after app platform security that also [02:44] includes cloud and cloud infrastructure [02:46] as well as data platforms and SAS [02:48] security. [02:50] Happy to be here. [02:56] Hi folks. Uh my name is Mikan. I head of [02:58] platform engineering at Field. Field is [03:01] a renewable energy company and we have [03:03] an in-house automated energy trading [03:05] platform. Um so my background is from [03:08] financial services uh aerospace [03:10] engineering. Uh I'm really excited to be [03:12] on the panel today as field we're quite [03:14] early in our geni journey and sort of [03:17] keen to share some ideas and and and [03:19] hear some of the questions from the [03:20] audience as well. [03:22] Pleasure to be here. [03:24] >> Yeah. And uh my name is Alex Borage. Um [03:27] I lead the product security team at [03:29] Chenguard. Um you've just had a [03:31] wonderful introduction to what Changard [03:34] do. Um so yeah, my background is is kind [03:36] of on that intersection between security [03:38] and engineering, product security, [03:40] application security. Um yeah, making [03:43] sure that the products that we build as [03:45] an organization are secure and and [03:47] managing the risk uh for our customers. [03:49] Um, and yeah, really excited to be here [03:52] as well. [03:53] >> That's awesome. Thank you all. And I'm [03:56] Maxi and I'll be your panel moderator [03:58] today. A bit about me, I'm an [04:00] experienced engineering leader who's led [04:02] multi-year crossf functional [04:04] transformations and quality, product [04:06] infrastructure, and front-end platforms [04:09] where I modernized systems, improved [04:11] developer velocity, and enabled our [04:13] platforms to scale to billions of users [04:16] globally. Now I'm a Stanford certified [04:18] AI governance executive partner now [04:21] advising small and midsize executive [04:23] teams on pragmatic AI governance [04:26] processes, frameworks and implementation [04:29] roadmaps to make deploying responsible [04:31] AI repeatable and scalable. So this [04:36] discussion strongly aligned with my [04:38] daily work and the need to manage AI [04:40] risk across organizations. If you didn't [04:44] know, and this is coming from lead dev's [04:46] own reporting, twothirds of [04:48] organizations report exploits involving [04:52] vulnerable LLM generated code with [04:55] similar proportions facing prompt [04:57] injection incidents and jailbreaks. [05:00] AI generated code is also linked to [05:03] around one in five security breaches [05:05] discovered. and AI coding assistants. [05:08] Although they can ship code four times [05:10] faster, their code is often 10 times [05:13] riskier. [05:15] So why don't we just get into the [05:17] discussion? Um I feel like we should [05:19] start with a a question for everyone. So [05:22] maybe we'll start with you in Sean, but [05:24] everyone's invited to chime in. The [05:27] threat landscape has shifted from static [05:30] vulnerabilities to highly dynamic risks [05:33] as we've heard. Agentic AI systems that [05:36] autonomously generate and execute code, [05:39] vibe coding that lets non-technical team [05:41] members create production-like systems [05:44] and attack surfaces that are dynamically [05:47] changing in real time. So in this new [05:50] era of AI risk, how has risk ownership [05:54] and this idea of accountability changed [05:57] in the last year or year and a half in [05:59] your organization? [06:02] >> Yeah, that's a it's a really good [06:03] question. Um and I'll answer briefly [06:05] from our perspective at field. Um so as [06:08] I mentioned before we're a renewable [06:09] energy company and so we have a sort of [06:12] broad um business user set. So we've got [06:15] folks in product but we've also got [06:16] folks commercial adjacent and then your [06:18] sort of classical data scientists and [06:20] engineers. And I think with a lot of [06:22] these uh sort of advents we have a lot [06:24] more folks from the sort of analysis [06:25] functions from the commercial functions [06:27] that are able to make contributions. Um [06:30] and so what risk ownership looks like [06:32] for us is by and large the [06:34] accountability still sits um within the [06:37] engineering function u because we we [06:39] operate in sort of build it uh own it [06:41] model. So folks within our organization [06:43] are getting paged at 3 in the morning if [06:46] there's a problem. Um, but what that [06:47] means particularly is that the the sort [06:50] of QA of the artifacts that that do go [06:52] out or anything that will run in our [06:54] production environment sits with us and [06:56] that means we do a lot of that QA [06:58] validating that um folks where they're [07:01] making contributions are fitting in with [07:03] existing patterns. Um, and by and large [07:06] people understand what's going into [07:08] production because they will get pitched [07:09] for it. Um, so in summary, it hasn't [07:12] changed the model too much. uh sort of [07:14] expanded the risk surface if you will or [07:16] the source of risks uh but in terms of [07:18] the accountability uh at field it still [07:20] sits within engineering. [07:23] >> Thank you Alex. How about you? [07:25] >> Yeah. Yeah. So I think my experience is [07:27] is a little bit different in that the [07:30] one of the key things that I'm seeing [07:31] changing is um there are now kind of [07:33] parts of the business outside of [07:35] engineering like outside of the [07:37] traditional places where we would build [07:38] products, features, tools that are now [07:40] able to to to do that thing to to build [07:43] new things for customers. Um you know [07:46] whether this is uh sales folks like vibe [07:49] coding something putting it in front of [07:50] a customer or I don't know things like [07:52] finance building tools for their own [07:53] internal use, right? So there's just [07:55] kind of new uh functions that are able [07:58] to create tools um that maybe don't have [08:00] the the muscle memory, the culture, the [08:02] habits of how to build things securely, [08:04] what things to be aware of, what checks [08:05] you have to go through. And so um while [08:08] we want to enable those parts of the [08:10] business and we don't want to hold [08:11] anybody back, we the the threat [08:14] landscape has changed because threats [08:15] are now popping up in places where as a [08:17] product security organization we would [08:19] never previously have looked or as a [08:21] security organization, right? We would [08:22] we have traditionally been focused on [08:24] what is engineering doing? What is [08:26] coming out of engineering? Whereas now [08:27] we need to like open up our visibility [08:30] and our site to the whole organization [08:33] because new products can come from [08:35] anywhere which means new threats and new [08:36] risks can come from anywhere as well. [08:40] >> I think that's such an interesting uh [08:42] dynamic. So we're we're going to dig [08:44] deeper into this but I want to hear from [08:45] Aisha coming from a more established [08:47] corporate back background. [08:50] >> Yeah, sure. So the the the way I've seen [08:53] is historically and traditionally [08:55] security uh to be very struggled with [08:59] ownership as a whole anyway where you [09:03] know you would have code owners you [09:04] would have your SDLC you would have your [09:07] um pipeline packages and supply chain [09:10] third party all put together so it's um [09:14] in my point of view um AI speeding up um [09:18] code development u software development [09:20] new features is um have added to that [09:23] existing struggle of ownership and the [09:26] gate points of where you want to take [09:28] action to security findings. So um in [09:32] integrating this security into this new [09:36] newly um created way of code generating [09:39] really really fast speed um is is going [09:42] to be one thing. Another thing is that [09:45] existing vulnerabilities that u we're [09:48] seeing across applications and products [09:50] that we have um have vulnerabilities [09:53] um uh that could be reachable and [09:56] exploitable with AI coming in from [09:58] outside as well that time between a [10:01] vulnerability is zero day being out and [10:04] that getting exploited that is just [10:06] narrowing and narrowing down that means [10:09] although there is this ownership and [10:11] speed problems we still need to be even [10:13] faster [10:14] in addressing the issues that we're [10:16] receing. So the struggle is um again [10:20] placing ownership having accountability [10:22] and at which points do we um have um [10:26] security guard rails in the gates that [10:30] will um look after code vulnerabilities. [10:34] >> Got it. And so I think what the the [10:36] theme that I'm or the trend that I'm [10:38] hearing here is that from a smaller [10:41] startup like field they kind of just [10:43] like put that responsibility on edge and [10:46] then as we get to a scaleup like chain [10:48] guard the dynamic um gets a little bit [10:52] more complicated with a little bit more [10:54] partners uh tackling security and risk [10:57] accountability and then within the [10:59] broader corporate function there's a [11:02] need to move quickly to address these [11:04] issues. And we're going to tease a [11:05] little bit more on that in an upcoming [11:07] question. Uh but for now, I think what's [11:10] really standing out and maybe what's on [11:11] everyone's mind is agentic code [11:14] generation and vibe coding, right? Um we [11:18] talked about how they increase the [11:21] software supply chain attack surface in [11:24] ways that like our traditional software [11:26] processes really struggle to handle. So [11:29] the risks are not only dynamic but [11:31] they're transient and they're [11:33] everchanging. So when we get down to [11:36] brass tax, what are some of the con [11:38] concrete controls or practices that you [11:42] have seen effectively reduce this [11:45] expanded risk especially you know that [11:48] context of having non-technical team [11:50] members contributing generated code. So [11:53] Alex why don't we start with you and [11:54] then follow up with Aisha. Yeah. So I [11:57] think you know as you've said the the [12:00] speed at which things change is is now [12:01] operating at a different scale than it [12:03] was before. Um you know where previously [12:05] you might have been able to run some [12:06] security scanning tools or or be able to [12:08] get a snapshot of the state of your [12:11] organization the state of your [12:12] enterprise. uh like we have seen from [12:14] the recent attacks you know just in the [12:16] last few weeks we've had the kind of [12:18] high-profile attacks on on Triby and [12:20] Axios and other organizations that like [12:23] dependencies get introduced and then [12:25] they're exploited in a matter of minutes [12:27] before you're even aware that those are [12:28] dependencies of your organization. And [12:30] so it becomes much less around kind of [12:32] managing your sbombs kind of peace meal [12:34] and much more about what systems do you [12:36] have in place, right? Your your security [12:38] posture is no longer like how much red [12:41] and how much green do you have on your [12:42] dashboard. It's what systems do you have [12:43] that are operating at machine speed to [12:46] protect those things. Um and you know to [12:50] your point about what do we do about new [12:51] parts of the organization that are maybe [12:53] engaging with with activities that they [12:55] didn't before. I think the the key thing [12:58] that the way that chain guard is [12:59] approaching this is you know we make the [13:01] the easiest path we make the default [13:03] path the safe one and if somebody is [13:06] able to do something then then they are [13:09] allowed to do it right so we put in [13:10] place tooling so that you know whoever [13:13] whoever you are in our organization if [13:14] you're able to build something if you're [13:16] able to publish it then we have put the [13:19] safeguards in place to make sure that [13:20] that is then secure um so we don't have [13:23] to rely on education we don't have to [13:25] rely so much on culture building, you [13:27] know, it's the the tooling is there to [13:28] support people um and and enable the [13:32] business to operate as fast as it can [13:33] do. [13:34] >> So, permissions based or rule-based [13:36] tooling capabilities. [13:38] >> Yes. But also, you know, permissions [13:41] about uh what goes out the door, right? [13:43] like we have automated controls in place [13:45] to make sure that before you know [13:47] something that is built in our CI [13:48] pipeline is is published and pushed to a [13:50] customer that it has gone through the [13:52] required checks that we've validated the [13:53] sbombs that it is pulling its [13:54] dependencies from the right place all of [13:56] that sort of thing as well. [13:57] >> Got it. Brilliant. Okay, Aisha. [14:01] >> Yeah, I mean I would I would look at it [14:04] you we've got to get the basics right. [14:06] Okay. All the essentials. So leaving um [14:09] AI aside, are we doing what we're [14:11] supposed to be doing? which um we should [14:14] have been doing yesterday anyway. So do [14:17] we have the right uh checks in place? [14:20] Are we starting from clean slate? So for [14:22] example, the likes of chain guard or [14:24] really lean images and third party [14:26] libraries that you don't need but you're [14:28] inheriting the vulnerabilities from [14:29] there. So get those really really clear [14:33] and right from the beginning. Then [14:35] inventoring of course because what it's [14:38] one thing where you have known [14:40] vulnerabilities that you're checking [14:41] against. It's another thing when a zero [14:43] day comes in and the time it takes for [14:45] you to respond to that right. So know [14:47] exactly what is where and how it it is [14:50] going to get impacted with with enhanced [14:52] context. So of course you know your [14:55] inventorying which show where you you [14:57] want to go for sbombs or even enhanced [15:01] platform views that will really help. [15:04] And the other one is utilize AI in those [15:08] checks as well. So you know if if the [15:11] code is moving at AI pace which is [15:13] machine pace then you got to move it [15:15] machine pace to catch up with that. So [15:18] wherever we're putting in guard rails or [15:20] deny by design deny explicit deny [15:24] anywhere on that on the pipeline where [15:28] we're introducing new code. Um we've got [15:30] to make sure that we have that really [15:32] quick. um response to it. We don't [15:35] necessarily want to slow down teams at [15:38] all, but we also want to have relevant [15:40] enough gates everywhere where we can [15:43] plug in um and uh and um whether it is [15:47] being proactive or we need to respond, [15:50] we have those gates available to us. Um, [15:53] one other thing I've seen from [15:55] traditional application development [15:57] platforms or dev platforms of Saudi [15:59] pipelining is CLC all that you know [16:02] niceness we have and it's sort it's at [16:05] least to me sort of a little bit clear [16:07] as to how this would work out in a more [16:10] speedy fashion with AI generated code um [16:14] and AI generated um newly introduced [16:17] attacks. It's another thing when we're [16:19] looking at a lot of um puzz platforms [16:24] SAS [16:25] >> with low code being introduced with AI [16:29] enabled on top of it as well. they don't [16:31] necessarily fall within the our [16:34] traditional SDLC [16:36] um and um and the security controls and [16:39] they also cannot be compatible with [16:42] those security controls and we just need [16:44] to make sure that we we are kept up with [16:46] that as well and we will be seeing more [16:48] and more organizations relying on uh [16:51] platform specific AI generation or low [16:54] code environments um that's definitely [16:56] top of my mind [16:58] >> absolutely so it sounds like you take a [17:00] principles based approach, right? where [17:02] you start with like what do we have a [17:04] risk assessment an inventory getting [17:06] good and strong on the basics of [17:08] security and then you build on top of [17:10] that um responding to every dynamic part [17:16] of AI like low code and no code [17:18] platforms for example and I think we're [17:20] going to hear more about that approach [17:22] as we get further into the webinar but I [17:24] think that that's such an interesting [17:26] contrast um especially when we think [17:28] about a larger more established [17:30] organization versus uh an organization [17:33] uh that's a scale up. So awesome [17:36] response and what since we talk about a [17:40] a scale up and an established corpor [17:42] corporate background I think I want to [17:44] take it back to kind of the startup [17:47] point of view and so I I'd like to start [17:49] with you on this question in see and in [17:53] a resource constrained startup and maybe [17:56] if we're all managers I think we can all [17:58] identify with the feeling of being [18:00] resource constrained but how how have [18:04] you restructured teams and rituals so [18:06] that risk ownership doesn't become [18:09] diffuse [18:10] when non-engineers use agentic tools or [18:14] vibe coding to build and deploy or just [18:17] generally anyone using different AI [18:20] tools. What practical patterns help [18:22] maintain accountability without killing [18:25] speed, especially as these new risks [18:28] appear that didn't exist in traditional [18:31] development? [18:32] No, thanks. That's a really great [18:34] question. I guess um for a bit of extra [18:36] context, uh so within field the platform [18:39] I mentioned before, the in-house energy [18:41] trading platforms, it's fully automated [18:43] and so this is very much an internal [18:46] business application. It doesn't have um [18:48] sort of average customers in the [18:50] conventional sense. Um and the energy [18:54] industry at least where we operate is [18:56] regulated. So, so we have some [18:58] requirements to be able to there's a lot [19:00] of explanability required in our [19:02] systems. Um, and so I give all of that [19:04] as context um because it then helps [19:07] frame the kinds of contributions um that [19:10] we have and the model that works. Um so [19:12] in our context where we have [19:14] non-engineers using agentic tools um [19:17] generally this tends to pop up in areas [19:20] where it's sort of some analysis some [19:22] analytics um sort of SQL procedures that [19:26] sort of thing to try to slice and dice [19:28] data in multiple different ways um or [19:31] contributions on say we have an internal [19:34] web application that's used for [19:35] controlling uh the trading platform um [19:38] and so generally there's a there's a bit [19:40] of sort of onboarding [19:42] for for non-engineers so that they have [19:43] a an understanding of patterns etc. And [19:46] so I think in terms of the structure of [19:49] the teams I think we've just taken a lot [19:52] of learnings that we've had in the whole [19:54] sort of agile space of folks still using [19:56] that term in general about putting cross [19:59] functional groups together um so that [20:01] they understand one another's context uh [20:02] and what they need to work on. So what [20:04] that means for non-engineers is um you [20:07] know rather than have a a PR came out [20:10] was thrown over the wall landed in CI [20:12] and no one really knows why it's there [20:14] just sort of having that open dialogue [20:16] about sort of what's the problem you're [20:17] trying to solve and talking through [20:19] through approaches because yeah the [20:21] thing to bear in mind is that um but [20:23] some of these folks they won't be [20:24] familiar with the patterns they won't be [20:26] familiar with the code base uh code [20:28] bases and best ways to solve that so I [20:31] think some of the good patterns we've [20:32] just discovered over, you know, the past [20:34] decade or two about how individuals work [20:36] well together still still work here. Um, [20:39] and so to talk about, um, the sort of [20:42] risk ownership, um, when we're talking [20:45] about really critical parts of the [20:46] energy trading platform, particularly [20:48] places that need to be audited, um, what [20:51] we found is that actually those tend to [20:54] be left to the engineers and the [20:55] technical folks just because of the [20:57] level of criticality required in the [20:59] application. Um, so that's generally [21:02] that's generally how it seems to work [21:03] for us. So where things are lower risk, [21:06] the contributions are very very much [21:07] welcome and and it's easier to ramp [21:10] folks onto that. Um, where the level of [21:12] criticality is super high, generally the [21:15] sort of the context you need to be able [21:18] to understand what to do or to make [21:19] improvements is quite high. It's [21:21] basically doing the job. Um, and so we [21:23] we find that there's less risk [21:24] introduced um in those areas of um of [21:27] our platform. [21:28] >> Got it. So it's a riskbased approach. I [21:32] think that's really interesting. Alex, [21:34] how is it over at Chingard? [21:36] >> Yeah. So I think maybe to come at this [21:38] problem from a slightly different [21:39] direction. I think we as the security [21:42] industry have have been kind of fighting [21:44] a losing battle over like building uh [21:47] habits and and and building skills and [21:50] educating nonsecurity specialists. you [21:52] know, we we've kind of been losing that [21:54] battle for the last, I don't know, two [21:55] decades, maybe longer in in, you know, [21:58] security training is something that [22:00] people don't really engage in. They [22:01] don't really learn from. It doesn't [22:02] really change their habits and their [22:03] behaviors and and so now if we're trying [22:05] to roll that out to, you know, people [22:07] outside engineering or or maybe, you [22:09] know, some of the non-traditional parts [22:10] of the org, like I think that that [22:12] barriers and those hurdles just get [22:14] higher and higher. So I think what this [22:16] does is give us an interesting [22:17] opportunity to to come about this from a [22:19] different angle and say rather than [22:20] trying to build the culture in the [22:23] humans in our business, we can try and [22:25] build the behaviors that we want to see [22:27] into the AI agents themselves. um [22:29] particularly as we're seeing the growth [22:30] of skills um and the you know org level [22:34] instructions that we can give to our AI [22:36] agents we could that's where we can now [22:37] plug in the behaviors that we want to [22:39] see the behaviors that we don't want to [22:41] see and that enables us to uh kind of [22:45] level up as an organization in a way [22:48] that is invisible to the people using it [22:49] and in a way that feels frictionless and [22:51] and to your original question you know [22:53] we're all resource constrained you know [22:55] I can create some prompts and then roll [22:56] those out to everyone's AI agents much [22:58] much faster than I can you know get 100 [23:01] people on a call and and do some [23:03] training with them and and level them [23:04] up. [23:05] >> Got it. So the team scale it's no longer [23:07] getting approval for another engineer. [23:10] It's like okay we need another 10 agents [23:11] to execute XYZ thing. And I I completely [23:15] hear you. I uh there's a lot of [23:17] discussions happening around security [23:19] overall. Some people want to take it [23:21] towards security appreciation versus a [23:23] typical uh security training. So, it's [23:25] really interesting to to hear more about [23:28] this as well as what you said about [23:30] building the oversight behaviors you [23:32] kind of want to see into the AI agents [23:35] themselves. I think that's pretty [23:36] innovative. Um, so I don't want to leave [23:40] it there because I definitely want to [23:41] hear about how does all of this [23:43] translate when you're working in a in a [23:46] more established corporation like such [23:48] as insurance. So, Aisha, what is this um [23:52] h how does how is this changing for you? [23:54] So I'm curious specifically about the [23:56] corporate context and agentic risk like [24:00] have they increased cross team [24:02] collaboration for you and if so which [24:04] teams now work more closely [24:07] >> and what the impact of product [24:08] development cycles. [24:11] Yeah, I think that with many [24:12] organizations [24:14] um on a on a startup scale up scale I [24:18] presume there there are a lot of teams [24:20] that may wear multiple hats where it [24:23] requires collaboration um um uh across [24:28] team methods where where you scale out [24:30] in very large corporations and [24:33] organizations [24:35] um the the boundaries are a little bit [24:37] more defined. So when you bring um agent [24:41] AI or AI agents into your existing you [24:44] know applications platforms uh you know [24:47] products that you have etc it definitely [24:50] pushes the boundaries on that. So what I [24:53] what I what I have seen is um we're [24:56] seeing more and more teams that wouldn't [24:58] um otherwise talk to each other starting [25:01] talking for example dev and business [25:04] units um where um the there is a [25:07] shortcut from like I said from where it [25:11] would be a product feature now it is an [25:13] agentic workflow [25:15] uh um in the um in the back end and I've [25:20] seen a lot more moving around data [25:21] platforms data teams as well. So we I'm [25:24] seeing more and more push for well um [25:28] collaboration uh that is can't be [25:30] helped. Uh it's the conversations that [25:33] needs to be had um in order to define [25:36] you know it's architecture how it's [25:38] going to be implemented who's doing what [25:40] and the question of ownership definitely [25:42] comes up uh in those which leads to more [25:45] conversations I guess. [25:47] >> Absolutely. But does it have you seen it [25:49] impact product development cycles or is [25:50] it a situation where it cannot impact [25:53] product development cycles like a [25:54] deadline's a deadline or is there room? [25:58] Uh it's I've seen a push um bring [26:01] forward deadlines uh where um we have [26:05] seen change in in collaboration where [26:07] we've seen we've identified we could be [26:09] more efficient etc. But it's not [26:12] necessarily um [26:15] something that sort of redefined um how [26:18] we dealt with SDLC in at least in this [26:20] large scale. [26:22] >> Got it. [26:24] >> Thank you for that context. And so I [26:26] think um now is a great time to remind [26:29] the audience if you're here and have a [26:31] question definitely use the Zoom Q&A [26:34] feature and we'll see if we can work [26:36] them into our discussion today. Um, so [26:40] Aisha, I'm bringing this back to you [26:42] because I'd love to hear more about [26:44] implementing guard rails for dynamic [26:46] risks. And what what I'm talking about [26:48] here is like at platform scale. Uh, we [26:51] talked about the dynamic risks of [26:53] agentic systems. We talked about agentto [26:55] agent interactions, real-time code [26:57] execution, even shadow agents, right? We [27:00] we have this kind of problem in the [27:02] industry of people using maybe not [27:04] approved AI tools, for example. And so [27:08] when you think about that dynamic set of [27:12] risks, what capabilities or guard rails [27:15] have you and your team implemented? This [27:17] could be observability, [27:19] identity for agents, escalation paths. [27:22] What have you implemented that [27:24] organizations of any size could retrofit [27:27] into their plan? [27:29] >> Yes, certainly. So like I said in the [27:32] previous question as well, we've got to [27:33] make sure we get the basics right. Okay. [27:35] So if you we don't have the foundation [27:38] fundamentals in place with a agentic AI [27:41] or AI agents coming into which whichever [27:44] various form or AI generated code coming [27:47] in it's it will only heighten existing [27:50] existing risks [27:52] um and it will um uh have an impact on [27:55] the blast radius. So what we've done is [27:59] um review of what what gaps have we got [28:02] um in terms of all things security and [28:05] that is from are we um logging in [28:08] correctly? Have we got uh necessary [28:10] controls in place? Are we covering um uh [28:13] vis do we have visibility everywhere? [28:16] And um of course with anything like the [28:19] question of shadow agents where they [28:21] popping up from um depends on uh again [28:25] your existing security controls. If [28:27] you're a little bit more relaxed [28:28] organization where you have um um um [28:32] where you allow a lot more autonomy to [28:34] teams to bring in apps and um and [28:38] solutions or even um on on their desktop [28:42] uh device. [28:44] you'll find a lot of that um in large in [28:46] my organization it was quite restrictive [28:49] to begin with. So we've got a good [28:51] handle of you know what we think uh is [28:54] coming in however it doesn't necessarily [28:56] mean that we have the full visibility. [28:58] So visibility is absolutely the most [29:01] important. And the other ones is [29:03] security controls we need to consider [29:06] um as new security controls with um uh [29:10] use of genai and agentic workflows and [29:14] um AI agents being used whether it is [29:16] something that we're building on our own [29:18] platforms or it is that we're [29:21] third party solution [29:24] are we doing whatever is necessary in [29:26] terms of its the guardrails we need to [29:29] embed into those LMS and the output Are [29:32] we testing it right? And I think it's [29:34] not necessarily just a security [29:36] question. It's a a platform DevOps and [29:40] um product management wide. How do we [29:44] now test [29:46] um the output in a in a way that we can [29:50] rely on. So of course there will be a [29:52] lot of security testing that we've been [29:54] doing um AI specific security testing [29:58] um problem injection attempts perhaps [30:02] adding in another LLM on top of another [30:04] LLM that will look at um security of the [30:08] output in very risky situations. So [30:11] we've considered all options with a risk [30:15] um uh profile uh consideration where the [30:19] risk is really high going with more [30:21] restrictive controls. Um I've also [30:24] recently started looking at enhancing [30:27] existing security posture management we [30:30] have with AI visibility. So um so if [30:34] you're using any existing security uh [30:37] tools you can ensure that they will be [30:39] covering um the likes of cloudbased um [30:45] AI platforms um its configuration [30:49] um its um um uh attack surface etc etc. [30:55] >> Gotcha. Okay. So it's it's a [30:58] multi-pronged approach that even with AI [31:01] now you're seeing the need to partner [31:04] across the organization particularly to [31:07] hit reliability and resilience targets [31:09] but it's still like the foundation of it [31:12] all is that principles-based approach [31:13] you talked about about getting the [31:14] basics right I think that's interesting [31:17] now I'd love to kind of contrast that a [31:19] little bit and hear from like a smaller [31:22] startup so in seeen are there specific [31:24] implement uh specific speific guardrails [31:27] that you've implemented or seen [31:29] implemented within your organization? [31:31] >> Yeah, it's a good question. Um, so as I [31:33] mentioned before, we're we're quite [31:35] early on in our journey and one of the [31:37] main areas that we're starting to focus [31:39] on um is having uh agents perform some [31:43] ad hoc maintenance tasks on our trading [31:45] platform. Um so an example scenario this [31:48] is you know we sometimes have [31:50] maintenance windows on the exchange and [31:52] and there certain there's certain [31:53] requirements in terms of how our clients [31:54] need to behave around these events. Um [31:57] the notifications are quite dynamic. Um [31:59] and so we're thinking about actually can [32:01] can agents just take care of this rather [32:03] than you know the on call uh team member [32:06] needing to manage this and and handhold [32:08] it. Um and what we're thinking about [32:10] specifically around that is [32:12] observability. [32:14] um that's really really crucial for that [32:16] kind of context. Um and particularly um [32:19] thinking about identity and access [32:21] management. So sandboxing as much as we [32:25] can. Um it's no no different to how we [32:29] manage any other application and [32:30] thinking about actually what what [32:32] privileges uh the identity that this [32:34] agent will be be running on this host [32:36] environment. But what privileges will it [32:38] have? others privileges. We're [32:40] comfortable with it having elevated [32:42] controls by default just denied. Um and [32:45] and the same applies as well for for [32:48] members of our development teams where [32:50] folks might be running things like cloud [32:53] code or or codeex locally on the [32:54] desktop. What what authentication [32:57] credentials have they got set up [32:58] locally? because I mean this is working [33:00] on on the file system and we've all read [33:03] the news articles about agents that [33:05] didn't ask for permission before they [33:07] did the thing or the AWS case about [33:09] certain environments getting getting [33:11] deleted and and that that's very very [33:13] likely when you have these inheriting [33:15] credentials that that humans have. So [33:18] for us, we're thinking about how do we [33:19] audit the credentials that our local [33:21] teams have so that actually if they are [33:22] running things like codeex, it is safe [33:25] or at least the roles that have been [33:26] assumed at that time are appropriate for [33:28] the level of work required. [33:31] >> Got it. So it sounds like uh there's a [33:33] use of agents right now for per [33:35] performing ad hoc maintenance task, but [33:38] there is a broader plan to incorporate [33:40] agents into things like AM identity [33:43] access management and observability. [33:46] Awesome. [33:48] Uh, okay. I don't see any questions. So, [33:51] we'll continue with the Q&A that we have [33:54] here. And I might combine because we're [33:56] at the 35 minute mark. So, I might [33:59] combine the last two questions um just [34:02] to get like final input from everyone [34:05] before we open it up to broader Q&A. So [34:08] when we think about individual and [34:10] cultural accountability in a new risk [34:13] category right how do we redefine [34:16] personal and team level responsibility [34:20] in this dynamic environment so that [34:23] velocity doesn't come at the expense of [34:27] accountability [34:29] and let me see I I just made you talk [34:32] for a bit in see so maybe I'll start [34:33] with Alex on this and Alex if you could [34:35] close with what's one one new practice [34:38] someone could take away today and [34:40] implement over the next 90 days. [34:42] >> Yeah. So I think you know we've talked a [34:44] little bit about uh vulnerabilities now [34:46] operating at machine speed and our need [34:48] for like our defensive and and our [34:51] controls to operate at machine speed as [34:52] well. So I think thinking about this in [34:55] terms of like what are the [34:56] responsibilities of of individuals in [34:58] our organization is is maybe not the [35:01] right way to think about it. Right? It's [35:03] it's a case of understanding that no [35:06] humans are going to be able to keep up [35:07] with the new threat landscape. And so [35:10] it's maybe a case of uh educating or [35:13] reorientating people that that that that [35:15] will kind of necessarily be too slow to [35:18] be able to keep up with what we're [35:19] looking at. So, you know, shifting that [35:21] responsibility onto AI agents, onto [35:24] tools, onto systems that we have in [35:26] place that operate at machine speed and [35:27] that that don't operate at human speed. [35:29] um I think is kind of how we need to [35:31] think about accountability. It's not the [35:33] people that are accountable for things, [35:34] it's the tools that we put in place that [35:36] are now accountable for them. Um and [35:40] yeah, to wrap up uh I think you know one [35:43] very concrete uh change that people [35:46] could make is in terms of uh [35:47] understanding their supply chain [35:49] security and and you know moving on to [35:52] uh something that removes [35:54] vulnerabilities, removes risks before [35:56] they're even introduced. Um, so I'll [35:58] I'll do a little plug for chain guard [36:00] here. I think, you know, rather than, [36:02] you know, previous model where you might [36:04] want to monitor vulnerabilities as [36:06] they're introduced, triage them, respond [36:08] to them, and then remove them. We've [36:10] seen that that entire model just doesn't [36:12] work anymore. You can't keep up. So, you [36:14] know, shifting over to something like [36:15] Changard where we will remove those [36:17] vulnerabilities before they're even [36:18] introduced into your environment. Um [36:21] that's just one example of of the way [36:23] that we need to think about uh [36:26] reorientating the speed at which we're [36:27] operating. [36:28] >> Awesome. So addressing the risk upstream [36:31] like before it even gets to you. [36:32] >> Exactly. [36:33] >> Okay. Cool. Uh Aisha, what's one thing [36:37] and then I'll come to you and see, but [36:39] what's one new practice or capability [36:41] that's uh an audience member or someone [36:43] viewing this webinar that they could [36:44] take away and implement in the next 90 [36:47] days? [36:55] I sorry I was on mute. I was um thinking [36:58] of picking one. I couldn't make a [37:00] decision between two. Um so definitely [37:04] one very very practical um advice I can [37:07] give is um if you're a large [37:09] organization where you have concerns [37:11] around AI use and visibility start with [37:16] an AI register and ownership register. [37:20] Um as um easy as it seems it's a and is [37:24] as um manual as it looks. a good place [37:27] to start to understand how your [37:30] organization is utilizing AI and that is [37:33] in many different flavors, right? AI for [37:36] enterprise, AI for um productivity [37:40] within the organization. It could also [37:42] be AI used for code generation as well [37:45] as agentic AI and AI agent use as part [37:47] of your products. So have a registered [37:50] and treat it like treat it like you [37:53] would to any security uh uh risk and [37:57] inventorying of your assets. Um if you [38:00] cannot get this via API at least do it [38:03] manually it's better than nothing. [38:05] Another thing is definitely and [38:07] definitely look at your back end look at [38:10] your data architecture and ensure your [38:12] authentication authorization workflows [38:15] that you're assigning are getting it [38:17] right. Um that's that's [38:21] one thing that I can uh two things that [38:24] I can provide as advice. [38:26] >> Two for the price of one. I love it. And [38:28] so in so we'll close with you here now [38:32] before before you share like your one [38:35] suggestion for 90 90day takeaway. I'm [38:38] curious um when you think about your [38:41] first-line managers, when you think [38:42] about your staff engineers, your IC's, [38:45] I'm curious about what does good look [38:46] like for you in that dynamic [38:49] environment. Right? We heard Alex talk [38:51] about um security and accountability is [38:54] like something humans won't be able to [38:55] keep up with. We've heard Aisha talk [38:57] about um starting with the basics and [39:00] getting those right like with an AI [39:01] register. What does good look like for [39:03] you? and then definitely let us know [39:06] what's your uh 90-day takeaway that [39:09] people can implement. [39:10] >> Sure, absolutely. I think on the topic [39:12] of what good looks like for me, I think [39:16] uh having staff, engineers, having you [39:19] know leads, building systems that make [39:22] this easy for people. I think on on [39:25] subjects like security, I think that's [39:27] generally always been true. um as much [39:29] as we can build systems and whether [39:32] that's processes that are automated or [39:34] or guidelines that we would generally [39:35] have folks follow um I think that that [39:38] for me still remains the the benchmark [39:40] of what is good um and I think you know [39:42] Alex gave a really good answer there [39:44] about um humans not being able to to [39:47] cope with the pace of change and so I [39:49] think it makes sense to build more [39:51] systems you know the more automation [39:53] that helps make this easy for people the [39:54] better um and then I think on the [39:57] subject of sort of 90-day takeaways. I [40:01] think what I'm thinking about a lot [40:03] these days is about the sort of the the [40:05] respond and and recover aspects of of [40:08] the NIST framework, for example. Um, and [40:11] I think, you know, how do we build LLM [40:14] capabilities that make that side of [40:16] things easy? Um, I think there's only so [40:18] much that you would be able to sort of [40:21] prevent in the in the first place, but [40:23] actually how do you make that sort of [40:25] response that response and recovery [40:27] quite easy um when you when you have [40:29] these security incidents. So, I think [40:31] that would be the sort of the main thing [40:32] I'd be thinking about. [40:34] >> Okay, got it. Thank you. But no, [40:36] response and recovery being a a [40:38] near-term goal, but no specific tool. [40:41] Just kind of like addressing it [40:42] internally. [40:43] >> Uh, I'd be thinking about tools. So for [40:45] example um you know normally [40:47] organizations would have a sort of [40:49] incident playbook for example what [40:51] happens if we have a vulnerability or a [40:53] breach of some sort I'd be thinking [40:55] about how do we how do we make that [40:57] playbook [40:59] executable faster right is this can we [41:02] build a capabilities to actually make [41:05] >> managing the recovery of internets a lot [41:07] faster than it would ordinarily be [41:09] because if the threats if the threats [41:11] are faster than human speed then I think [41:13] similarly our or response and recovery [41:15] for any incidents needs to match that as [41:16] well. [41:18] >> Got it. So basically incident playbook [41:20] at agentic scale. [41:22] >> Yeah. Oh, that's that's a sound bite if [41:24] I ever heard on. Yeah, that's right. [41:26] >> Awesome. Thank you. Uh as we close out, [41:29] let me check to see if we have [41:30] questions. Uh now is a great time to ask [41:32] your questions. Uh or come hang out with [41:35] us in the Slack channel panel hyphen Q-N [41:39] and A and the Lead Dev uh Slack channel. [41:43] But what you essentially heard today and [41:46] learned today, we covered the surface [41:48] area of risk uh that AI introduces, the [41:51] controls our experts have implemented to [41:54] manage these risks, how they've thought [41:56] about restructuring their teams, and [41:58] redesigning partnerships across the [41:59] organization to address these [42:01] challenges, implementing guardrail to [42:04] account for dynamic risk and cultural [42:06] and individual responsibility. [42:09] So, thank you so much for all of the [42:11] good insights in today's panel. [42:14] Panelists, please give yourselves a [42:15] round of applause and let's head over to [42:18] the leadv Slack and thanks again chain [42:21] guard for sponsoring this webinar. Thank [42:24] you and see you next time. Thanks [42:27] everyone.  📄 **Full text:** ![[Full Document Contents/Articles/Accountable Engineering in the Age of AI.md|Accountable Engineering in the Age of AI by YouTube]] ## Highlights - 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 ([View Highlight](https://read.readwise.io/read/01kqzf7as0bm37ffgx7v205ssx)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kqzf7ateby75bse1cz5dk4ct)) - Tags: 👻 ai highlighted - >> 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 ([View Highlight](https://read.readwise.io/read/01kqzf7avgskhkpg8514xmvygc)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kqzf7ay53rsss99wezr9qzvr)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kqzf7b1f3esytpj60t1tbrbw)) - Tags: 👻 ai highlighted - 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 ([View Highlight](https://read.readwise.io/read/01kqzf7b5v5d03y84g0eq9yw67)) - Tags: 👻 ai highlighted