NatWest Deploys NetOrca Multi-Agent AI to Triage 10,000 Firewall Rules

AI Agents That Operate Infrastructure - Lessons from a Tier 1 bank deployment With NetOrca — Ai4

Ai4

By pairing independent AI models to assess pre-validated Git declarations, banks can safely automate 8,000 routine firewall reviews each year and transform one-off approvals into continuous posture checks.

AI-assisted summary of AI Agents That Operate Infrastructure - Lessons from a Tier 1 bank deployment With NetOrca — original source. Check the original for full context.

Source published: 2026-08-14

Detailed notes

## Background Published by Ai4 on YouTube on August 14, 2026, this presentation features NetOrca founder Scott Rowlandson discussing production AI agent deployment at NatWest Bank. The talk focuses on moving beyond basic copilots to autonomous infrastructure operators that plan, validate, and execute changes safely within enterprise and regulated banking environments.

## TL;DR Scott Rowlandson explains how NetOrca transformed enterprise infrastructure provisioning across 500 bank development teams by replacing legacy ticketing with Git-based declarative orchestration. Building on this clean operational foundation, NetOrca Pack uses multi-agent loops with paired, independently isolated frontier models to evaluate configuration plans and trigger self-healing workflows before executing changes through tools like Terraform and Ansible. The architecture is proven in production by triaging over 10,000 annual firewall rules, automating roughly 80% of low- and medium-risk requests while routing anomalies to security engineers. Ultimately, this approach turns static, one-time approvals into continuous compliance posture assessments and automated disaster recovery checks.

## Atmosphere & style The talk carries a pragmatic, technical, and battle-tested tone, stripping away speculative AI hype to focus on the unglamorous realities of enterprise IT operations. Rowlandson speaks with the composed, authoritative clarity of a practitioner who has solved real compliance, governance, and architectural bottlenecks inside a major regulated bank. Listening to the session feels like an insider engineering walkthrough, providing a reassuring and structured blueprint for deploying autonomous agents into high-stakes production environments.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=4s) Cross-team enterprise infrastructure provisioning has historically suffered from slow, manual processes like email attachments and legacy ticketing queues. - [00:04](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=4s) NetOrca replaced ticketing at NatWest Bank with a Git-based declarative orchestration platform across 500 internal developer teams. - [00:04](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=4s) Clean, pre-validated declarative intent from Git workflows provides the necessary foundation and high-quality input for autonomous AI agents. - [01:04](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=64s) To meet strict enterprise and banking compliance, NetOrca avoids proprietary models and instead routes agent actions through the bank's approved internal LLMs. - [01:04](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=64s) The NetOrca Pack architecture uses an iterative multi-agent loop where separate configuration and verification agents check each other before execution. - [01:04](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=64s) AI agents are decoupled from direct provisioning; agents handle operational reasoning, while battle-tested tools like Terraform, Ansible, and CloudFormation execute changes. - [03:27](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=207s) Manual firewall rule evaluation is a major enterprise bottleneck, with the bank processing over 10,000 requests annually amid shrinking security staff. - [03:27](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=207s) The automated triage pipeline uses two independent frontier models (such as Claude and ChatGPT) evaluating rules in complete isolation to prevent sycophancy and cognitive bias. - [03:27](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=207s) Firewall requests are categorized into Low, Medium, and High risk, enabling automatic approval for up to 8,000 routine requests while reserving human review for high-risk anomalies. - [06:01](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=361s) Automating evaluation shifts security from static, one-time manual sign-offs to continuous posture assessment that re-checks active rules whenever policies or applications change. - [06:01](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=361s) The multi-agent evaluation framework generalizes beyond firewalls to workflows like continuous disaster recovery parity and cross-region posture validation.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=4s) Replacing Enterprise Ticketing with Declarative Git-Based Orchestration

Scott Rowlandson, founder of the London-based startup NetOrca, introduces their work deploying infrastructure automation into production at a Tier 1 UK bank (NatWest Bank). In massive enterprise environments, service-providing infrastructure teams must deliver services to hundreds of consuming developer teams. Historically, this relationship has been mediated by legacy ticketing systems and manual administrative overhead. As Rowlandson describes it, requesting infrastructure from another team is notoriously slow and poorly validated, often devolving into "attaching a spreadsheet to an email" and waiting weeks for manual execution.

NetOrca was built to eliminate this friction by shifting cross-team provisioning into a Git-based orchestration workflow. Service teams publish reusable infrastructure services through the platform, allowing consuming developer teams to declare their requirements directly within their existing Git repositories and native development workflows. The platform tracks declarative intent, maintains state, and manages change tracking end-to-end. While originally designed to drive deterministic enterprise automation, NetOrca discovered that this validated, declarative foundation provided the exact operational substrate required to run autonomous AI agents in production.

- **Scale of deployment**: Implemented across 500 internal development teams within the bank. - **Core operational shift**: Replacing ticketing queues, spreadsheets, and emails with Git-based declarative service consumption and continuous state management. - **Foundation for AI**: Clean, pre-validated customer intent serves as high-quality input for autonomous agents, avoiding the pitfall of feeding messy, uncurated documentation into an LLM.

[01:04](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=64s) NetOrca Pack: Self-Healing Multi-Agent AI on Regulated Bank Infrastructure

To bring agentic workflows into production, NetOrca introduced NetOrca Pack, an orchestration add-on that intercepts declared service states and triggers self-healing agent loops. Operating inside heavily regulated banking environments imposes strict governance hurdles: organizations will not accept unvetted external models or opaque third-party training pipelines. NetOrca bypasses this barrier by refusing to sell proprietary LLMs or fine-tuned weights, instead routing all actions via API calls directly into the bank's own pre-approved, internally hosted foundation models.

The system relies on an iterative, multi-agent architecture featuring a config layer, a verification layer, and an execution layer. Rather than trusting a single model run, the platform pits multiple models against each other: one agent generates the configuration plan, while an independent model verifies it. If the configuration and verification layers disagree, or if runtime validation fails, the execution layer triggers a self-healing loop to re-evaluate and iterate on the decision before any downstream code is executed. Once the agent loop reaches consensus, the decision feeds directly into platform-agnostic automation tools such as Ansible, Terraform, or AWS CloudFormation.

```mermaid flowchart TD accTitle: NetOrca Agentic Orchestration Architecture subgraph Input ["Declarative Intent"] A["500 Internal Dev Teams"] --> B["Git Request / State Change"] B --> C["NetOrca Change Instance"] end

subgraph AgentLoop ["NetOrca Pack Multi-Agent Loop"] C --> D["Config Agent"] D --> E["Verify Agent"] E -->|Discrepancy / Failure| D E -->|Consensus Reached| F["Execute Layer"] end

subgraph Downstream ["Traditional Automation"] F --> G["Ansible / Terraform / CloudFormation"] end ```

- **Compliance approach**: Integrates directly with the enterprise's internally approved models via API calls to satisfy stringent governance and regulatory standards. - **Multi-agent checks**: Utilizes paired models (e.g., pairing high-reasoning models with secondary verification models) to review and challenge planned actions. - **Execution decoupling**: AI agents make the operational decisions, while standard, battle-tested tools (Terraform, Ansible, CloudFormation) handle the physical infrastructure provisioning.

[03:27](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=207s) Enterprise Use Case: Triaging 10,000+ Firewall Rules

When NetOrca partnered with the bank to target high-friction, high-value operations, firewall rule assessment immediately stood out. In a large bank, hundreds of applications continuously request network access to speak to the public internet or communicate across internal segments. Traditionally, every single firewall rule required a human cybersecurity engineer to manually verify the request against complex enterprise criteria. This created an unsustainable operational bottleneck: the bank processed over 10,000 firewall rules annually while dealing with a shrinking security staff and escalating security scrutiny.

To solve this, NetOrca deployed the agent loop as an automated triage engine. When a developer submits a firewall rule declaration, the platform gathers policy-as-code rules, pre-approved traffic patterns, and customer attestation documentation (contextual proof of why the application requires connectivity). Two distinct frontier models (such as Claude and ChatGPT) assess the request in complete isolation from one another. Rowlandson emphasizes that neither model sees the other's assessment, preventing cognitive bias and sycophancy.

```mermaid flowchart LR accTitle: Firewall Rule Triage Pipeline subgraph Context ["Context Ingestion"] A["Firewall Rule Declaration"] B["Policy as Code"] C["Customer Attestation Docs"] end

subgraph Evaluation ["Independent Assessment"] Context --> D["Model A (e.g. Claude)"] Context --> E["Model B (e.g. ChatGPT)"] end

subgraph Triage ["Risk Bucketing"] D & E --> F{"Triage Engine"} F -->|Low Risk: Dev-to-Dev| G["Auto-Approved to Automation"] F -->|Medium Risk: Standard Policy| G F -->|High Risk: Policy Anomaly| H["Manual Security Review"] end ```

The system does not claim complete autonomy; instead, it acts as an intelligent triage pipeline that classifies incoming rules into three risk categories: - **Low Risk**: Standard rules matching strict pre-approved patterns (such as dev-to-dev network traffic) are assessed as safe and automatically forwarded to provisioning pipelines without requiring human intervention. - **Medium Risk**: Common operational requests backed by valid attestation and standard policy alignment that can be handled with minimal manual friction. - **High Risk**: Anomalous, sensitive, or policy-divergent rules that are immediately escalated to human security engineers for thorough inspection. - **Operational impact**: Rowlandson projects that approximately 8,000 of the bank's 10,000 annual rules fall cleanly into the low-to-medium range, eliminating an overwhelming percentage of repetitive manual labor.

[06:01](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=361s) From One-and-Done Approvals to Continuous Assessment and Beyond

Rowlandson highlights a fundamental architectural flaw in traditional infrastructure operations: enterprise firewall rules are historically assessed only once when initially requested and are never re-evaluated. Years later, applications change, original development teams disband, but stale rules remain active in firewalls because nobody knows who approved them or whether they are still necessary. By replacing static human sign-offs with an automated, agentic evaluation loop, NetOrca converts firewall validation into a continuous posture assessment.

Because re-running the agent loop carries negligible incremental friction, the platform can continuously re-assess deployed rules whenever enterprise policies are updated or customer attestations evolve. Banks can evaluate their entire firewall estate on an hourly, daily, or weekly cadence, turning operational security into a configurable dial: "How secure do you want to be? How much do you want to check these things?"

Once established, this agentic decision-making pattern generalizes across diverse enterprise workflows. The bank is already adapting the exact same loop to conduct automated Disaster Recovery (DR) posture checks, verifying whether secondary network zones maintain parity and determining whether rules must be deployed across regions. Ultimately, the system bridges the gap between raw AI reasoning and enterprise execution, turning complex operational decisions into repeatable, continuous, and fully auditable actions across existing infrastructure platforms.

## Notable quotes > [00:04](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=4s) attaching a spreadsheet to an email — Scott Rowlandson

> Modern “AIOps” mostly means better alerts and nicer dashboards. — Scott Rowlandson

> The hard part, actually operating infrastructure, still relies on humans writing integrations, stitching together tools, and executing runbooks under pressure. — Scott Rowlandson

> instead of building and maintaining bespoke integrations, we give the agent the API documentation (or OpenAPI spec), plus a small set of operational guardrails, and it generates the required calls, validates the outcome, and self-heals when the real world pushes back — Scott Rowlandson

> how we prevent an agent from “doing the wrong thing” when it’s confident but incorrect. — Scott Rowlandson

> planning → execution → validation → repair loop (and why “tool calling” alone isn’t enough) — Scott Rowlandson

> how you debug agent actions like you debug humans (audit trails, structured step logs, reproducible runs) — Scott Rowlandson

> [06:01](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=361s) How secure do you want to be? How much do you want to check these things? — Scott Rowlandson

> moving beyond copilots and into agentic operations that ship real changes plus the production lessons that only show up when you run this stuff for real. — Scott Rowlandson

## Mentioned Scott Rowlandson, NetOrca, NatWest Bank, NetOrca Pack, Ansible, Terraform, AWS CloudFormation, Claude, ChatGPT, OpenAPI, Ai4

## Video description Scott Rowlandson - Founder, NetOrca

Modern “AIOps” mostly means better alerts and nicer dashboards. The hard part, actually operating infrastructure, still relies on humans writing integrations, stitching together tools, and executing runbooks under pressure.

In this session I’ll show a different pattern: AI agents as operators, where the agent can plan and execute real changes safely across your existing systems. The key is a “universal executor” approach: instead of building and maintaining bespoke integrations, we give the agent the API documentation (or OpenAPI spec), plus a small set of operational guardrails, and it generates the required calls, validates the outcome, and self-heals when the real world pushes back (rate limits, inconsistent schemas, partial failures, missing permissions, stale state, etc.).

I’ll walk through what we built at NetOrca (our self-service infrastructure orchestration platform) and what we learned running it in production at NatWest Bank — at enterprise scale, with real constraints and real consequences. You’ll see how we handle the messy parts people skip in demos: idempotency, retries, rollback strategies, state-machine concurrency, noisy or contradictory API docs, safe prompting, and how we prevent an agent from “doing the wrong thing” when it’s confident but incorrect.

We’ll cover: The architecture: planning → execution → validation → repair loop (and why “tool calling” alone isn’t enough) How to make “docs → execution” reliable in the face of bad specs and unpredictable APIs Guardrails that work in practice (scopes, allowlists, policy checks, change windows, blast-radius limits) Observability: how you debug agent actions like you debug humans (audit trails, structured step logs, reproducible runs) What enterprise adoption actually looks like: trust-building, controlled rollout, and the line between automation and autonomy

If you’re building agentic systems for infrastructure, DevOps, network/security ops, or internal platforms, you’ll leave with a concrete blueprint for moving beyond copilots and into agentic operations that ship real changes plus the production lessons that only show up when you run this stuff for real.

[Source](https://www.youtube.com/watch?v=ONd4veLQ_Io)

中文简报

NatWest部署NetOrca多智能体AI分流处理10,000条防火墙规则通过配对独立AI模型来评估经预验证的Git声明，银行每年可安全地自动化完成8,000次常规防火墙审查，并将一次性审批转变为持续的态势检查。 Scott Rowlandson解释了NetOrca如何通过基于Git的声明式编排取代传统工单流程，从而重塑该银行500个开发团队的企业基础设施配置。在这一清晰的操作基础上，NetOrca Pack利用成对、相互隔离的前沿模型组成的多智能体循环来评估配置计划，并在通过Terraform和Ansible等工具执行变更之前触发自愈工作流。该架构已在生产环境中得到验证，每年可分流处理超过10,000条防火墙规则，自动处理约80%的中低风险请求，同时将异常情况转交给安全工程师。最终，这种方法将静态的一次性审批转变为持续的合规态势评估和自动化灾难恢复检查。英国国民西敏寺银行（NatWest Bank）通过 NetOrca 将 500 个内部开发团队原本低效的工单与邮件审批流程替换为基于 Git 的声明式编排，为生产级 AI Agent 运行提供了高质量的声明式输入基础。 (0:04) NetOrca Pack 采用自愈式多 Agent 架构，直接调用银行内部预先批准的大语言模型，由独立的配置与验证 Agent 互相校验，并在达成共识后解耦交由 Terraform、Ansible 等成熟工具落地执行。 (1:04) 针对银行每年超过 10,000 条防火墙规则的审批瓶颈，平台引入两套互相隔离的前沿模型（如 Claude 和 ChatGPT）进行独立评估，消除了认知偏见并成功将绝大多数低风险规则自动分流放行。 (3:27) 该架构将传统的“一次性人工审批”转变为高频持续的合规态势评估，使企业能够按需定期重审存量规则，并已逐步拓展至灾难恢复（DR）环境的自动化一致性校验。 (6:01)

Reading summary

Deploying autonomous AI agents in regulated banking infrastructure requires a pre-validated, declarative foundation rather than messy ticketing systems, according to NetOrca founder Scott Rowlandson. Speaking on their implementation at NatWest Bank, Rowlandson explains how pairing independent models to evaluate declarative requests enables automated triage and continuous policy auditing without replacing human control over high-risk decisions. Declarative Git Workflows as Substrates for Production AI (0:04) Traditional enterprise infrastructure requests between service teams and consuming developer units are mediated by legacy ticketing queues, emails, and spreadsheets, often taking weeks to execute. NetOrca replaced this manual overhead across 500 internal development teams at NatWest Bank with a Git-based orchestration system where developers declare requirements directly in their repositories while the platform maintains continuous state. Rowlandson notes that this transition to structured, pre-validated customer intent created the operational substrate necessary for AI. By substituting unstructured emails and tickets with clean declarative inputs, the platform avoids feeding uncurated documentation into large language models. Dual-Agent Verification for Regulated Infrastructure Governance (1:04) To satisfy strict banking governance without introducing unvetted external models, the NetOrca Pack architecture routes operational requests exclusively to the bank's pre-approved, internally hosted foundation models via API calls. The platform explicitly avoids providing proprietary models or fine-tuned weights. The system uses an iterative multi-agent loop where a configuration agent devises a provisioning plan and an independent verification agent reviews it. Discrepancies or runtime validation failures trigger an automated self-healing loop to re-evaluate the configuration. Once consensus is reached, execution is decoupled from the AI and handed off to deterministic provisioning tools including Terraform, Ansible, or AWS CloudFormation. Isolated Model Triage for High-Volume Firewall Requests (3:27) NatWest Bank faced an operational bottleneck processing over 10,000 firewall rules annually amidst security staffing constraints and growing scrutiny. To triage this volume, NetOrca feeds rule declarations alongside policy-as-code and customer attestation documents to two distinct frontier models, such as Claude and ChatGPT. Crucially, Rowlandson states that each model reviews the request in isolation without visibility into the other's assessment, preventing cognitive bias and sycophancy. The engine categorizes rules into three risk tiers rather than claiming full autonomy. Low-risk rules matching pre-approved patterns (such as dev-to-dev traffic) flow straight to automated execution pipelines, medium-risk rules pass with standard policy alignment, and high-risk anomalies route directly to human cybersecurity engineers. Rowlandson projects that approximately 8,000 of the bank's 10,000 annual rules fit low-to-medium tiers, removing the bulk of repetitive manual evaluation. Transitioning from One-Time Approvals to Continuous Assessment (6:01) Historically, enterprise firewall rules were evaluated only at creation, leaving abandoned rules active years later after applications shifted or teams disbanded. Because automated agent evaluations carry negligible incremental overhead, the bank can re-evaluate active rules on an hourly, daily, or weekly cadence against updated policies or altered attestations. Rowlandson indicates that this agentic evaluation pattern is also expanding to other operational domains, such as automated Disaster Recovery posture checks to verify configuration parity across secondary network zones and regions. NetOrca's deployment demonstrates that operational AI in high-compliance environments functions most effectively as an isolated triage and verification mechanism layered on top of declarative Git workflows and battle-tested execution tools, though edge-case security risks still require final human oversight.

精炼阅读摘要

NetOrca 创始人 Scott Rowlandson 阐述了其为英国一级银行 NatWest Bank 部署基础设施自动化的实践，指出将传统工单转为基于 Git 的声明式编排，是引入自主 AI 智能体并实现基础设施可靠运营的前提条件。该方案通过多模型相互校验与自愈循环，在高度受监管的银行环境中实现了十万级配置的智能分流与持续合规审计。声明式编排重塑跨团队协作并奠定 AI 基石 (0:04) 在 NatWest Bank 等大型企业环境中，中心化的基础设施团队需要向多达 500 个内部开发团队交付底层服务。Rowlandson 指出，过去这一交互长期受制于传统的服务台工单系统，流程往往沦为在电子邮件中附带电子表格并经历数周的人工等待，不仅交付周期漫长，且缺乏严格的输入验证机制。NetOrca 通过建立基于 Git 的声明式服务编排平台，允许服务团队发布可复用的服务模板，而消费端开发者则直接在其原生的 Git 仓库与开发工作流中以代码形式声明资源需求，由平台进行统一的端到端状态管理与变更追踪。这一架构重构的核心价值不仅在于消除跨团队协作的摩擦，更在于为引入生产级 AI 智能体提供了高质量的底层基底。传统将混乱、未经整理的企业非结构化文档直接输入大语言模型（LLM）的做法极易引发故障；而 NetOrca 收集到的是高度清晰、经过前期格式与意图校验的开发者声明数据。这为后续自主智能体的精确理解、逻辑推理与无偏差执行提供了可信的数据载体。双模型博弈验证与自愈循环满足严苛金融合规 (1:04) 受监管银行对数据安全和模型审计有着极高的治理门槛，坚决抵制不可控的外部模型或黑盒式的第三方微调训练。为此，NetOrca Pack 插件放弃了打包出售专有 LLM 权重的做法，完全通过标准 API 直接调用银行内部托管并完成合规准入的基础大模型，确保数据完全停留在金融机构的安全边界以内。在架构设计上，系统构建了一个包含配置层、验证层和执行层的迭代式多智能体闭环。系统摒弃了单次模型运行的信任假设，而是引入双模型博弈机制：由配置智能体生成初步配置方案，再由独立的验证智能体进行对立性审核。一旦两个层级出现判断分歧，或者运行时检查未通过，执行层将立即拦截变更并触发自愈循环重新评估，直至模型间达成一致。最终批准的指令会被解耦并移交给 Ansible、Terraform 或 AWS CloudFormation 等久经实战检验的既有自动化工具执行，确保 AI 专注于逻辑决策，而物理变更始终处于确定性工具的掌控之中。独立双模型分流万条防火墙规则以缓解安全瓶颈 (3:27) NatWest Bank 每年需处理超过 10,000 条防火墙网络策略变更请求，过去每一条规则都需要网络安全工程师依据复杂的合规标准进行人工比对。面对收紧的安全编制与不断上升的合规审查压力，人工审核成为了严重的效率瓶颈。NetOrca 将多智能体系统落地为防火墙自动化分流引擎，当开发者提交网络访问声明时，系统会自动聚合策略即代码（Policy-as-Code）、预先批准的流量模式以及业务团队提供的上下文证明文档。为杜绝认知偏差与模型阿谀现象，评估流程同时接入两个不同的前沿模型（例如 Claude 与 ChatGPT）进行完全隔离的背靠背审查，双方互不可见对方的分析过程。该系统并非追求不可控的全盘自动化，而是根据评估结果实现三级风险分流：针对开发环境互访等低风险流量直接放行至自动化部署管线；针对符合既定策略的中风险请求实施低阻力流转；仅将偏离基线的高风险与异常流量呈报给人工工程师进行深度复核。Rowlandson 预估，该行每年约有 8,000 条规则属于低至中等风险，这意味着绝大多数重复性手工审核负担得以被系统免除。打破单次审批局限转向全生命周期持续态势感知 (6:01) Rowlandson 强调，传统基础设施运维存在严重的机制缺陷：防火墙规则往往呈现“一次审批、终身留存”的特征。随着时间推移，业务应用发生迁移或原始开发团队解散，大量不再使用的过期规则仍长期滞留在防火墙策略库中，造成巨大的安全敞口和审计盲区。由于自动化智能体复核的边际成本极低，NetOrca 促使防火墙管控从静态的单次准入转变为连续的态势评估。企业可以根据自身的合规诉求，将安全检查配置为按小时、按天或按周自动全量重查。一旦企业全局合规策略发生更新，或者应用归属证明发生变化，系统能即时重新评估存量规则的合法性。目前，NatWest Bank 正将这一决策模式推广至灾难恢复（DR）态势检查中，利用智能体自动校验异地灾备网络区域的策略一致性，判断规则是否需要跨区域部署，从而将复杂的运维决策转化为可审计、可持续运行的企业级合规标准。 NetOrca 在一级银行的落地经验表明，AI 智能体在企业基础设施中的应用价值不在于取代底层执行工具，而在于作为上层决策与合规分流引擎。然而，该架构的有效性高度建立在前端清晰的声明式 Git 编排基础之上；若企业未能建立标准化的意图表达规范，智能体依然难以在复杂的传统运维孤岛中发挥预期作用。

Detailed notes — zh

## Background 该视频由 YouTube 频道 Ai4 于 2026 年 8 月 14 日发布，主讲人为 NetOrca 创始人 Scott Rowlandson。视频介绍指出，本次分享聚焦于英国一级银行国民西敏寺银行（NatWest Bank）的企业级落地实践，深入探讨如何构建超越普通 Copilot 的 AI Agent 基础设施运维闭环，在严苛监管和生产约束下安全执行系统变更与自愈修复。 ## TL;DR NetOrca 以面向 500 多个开发团队的声明式 Git 编排体系为底座，推出了专为强监管金融场景设计的多智能体决策与自愈架构。该方案直接调用银行内部合规托管的模型 API，通过高阶配置模型与独立验证模型的交叉校验和自愈重试机制，有效规避模型幻觉与单点偏差。在年均超 10,000 条的防火墙规则评估场景中，系统结合策略即代码与合规证明进行智能分流，将占总量约 80% 的中低风险规则全自动放行，仅高风险规则交由安全工程师人工审核。这不仅大幅缓解了安全团队的审批积压，更将传统静态的“一次性审批”升级为按需调节频率的“持续性动态评估”，并已横向拓展至容灾等运维合规场景。 ## Atmosphere & style 整场演讲呈现出高度专业、务实且聚焦企业落地痛点的技术工程师风格，摒弃了空洞的 AI 概念炒作。主讲人语调沉稳笃定，条理清晰地从传统工单协作的现实阻碍层层剖析至多 Agent 架构的严密工程防线。听感如同置身于一场含金量极高的一级银行架构复盘会议，让听众在真实的生产约束、合规边界与降本增效指标中，切实感受到 Agentic 自动化在严苛企业环境中扎实落地的力量与严谨美感。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=4s) NetOrca 与英国一级银行（NatWest）合作，致力于解决传统工单系统和邮件传递表格导致的跨团队协作与资源交付低效瓶颈。 - [00:20](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=20s) 平台构建了以 Git 为核心的声明式编排底座，支持 500 多个内部开发团队直接通过代码仓库发起基础设施与资源变更请求。 - [01:00](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=60s) 基于 Git 的声明式意图、强数据校验与完整状态追踪机制，为上层构建可靠的智能体自动化（Agentic Automation）提供了天然的支撑土壤。 - [01:26](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=86s) 面对金融强监管环境，系统直接调用银行内部已合规审批托管的模型 API，无需采购未经认证的外部模型或从零训练私有大模型。 - [01:50](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=110s) 架构采用多智能体交叉校验机制，由高阶配置生成层与独立的轻量验证层协同对比，有效避免单点模型幻觉。 - [02:15](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=135s) 引入自愈重试闭环（Self-Healing Loop），当多模型校验产生分歧或遇到执行阻碍时，执行层可主动重新触发并修正决策。 - [02:40](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=160s) 多 Agent 闭环达成决策共识后，输出将无缝对接 Ansible、Terraform 等传统基础设施自动化工具链，实现安全的平台无关落地。 - [03:27](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=207s) 锁定银行业高痛点场景——每年超 10,000 条的防火墙规则评估，解决安全团队缩编与合规标准日趋严苛带来的人工审查积压。 - [04:00](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=240s) 杜绝裸模型直接推理，向 Agent 注入防火墙规则、策略即代码（Policy as Code）与合规证明文件（Attestation）以提供完整上下文。 - [04:25](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=265s) 采用多模型独立并行评审策略（如 Claude 与 ChatGPT 分别审查），禁止模型间透传审批结果以消除从众偏差。 - [04:50](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=290s) 通过风险分流（Triage）机制精准分工：高风险规则路由至安全工程师人工复核，中低风险规则经多模型校验后直接免人工放行。 - [05:30](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=330s) 在银行每年 10,000+ 条防火墙规则中，该方案预计可将约 8,000 条中低风险规则全自动处理，显著削减机械性人工消耗。 - [06:01](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=361s) 颠覆传统防火墙“一次性审批即无人问津”的盲区，转向在策略更新或团队变更时可随时重算的持续性动态评估（Continuous Assessment）。 - [06:40](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=400s) 将安全合规评估转变为可按需调节的“成本杠杆”，企业可根据预算和安全诉求自由将检查周期设定为按小时、天或周运行。 - [07:15](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=435s) “声明式输入 → Agent 审查分流 → 自动化落地”架构具备高度通用性，已成功横向扩展至灾难恢复（DR）合规检查等多个运维场景。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=4s) NetOrca 的企业背景与基于 Git 的自动化编排底座演讲者 Scott Rowlandson 是总部位于伦敦的初创公司 NetOrca 的创始人。他首先介绍了 NetOrca 正在与英国一家一级（Tier 1）银行客户（即 NatWest Bank）合作的生产级落地案例。在大型企业内部，传统服务提供团队（如网络、基础设施、安全团队）与消费团队（如应用开发团队）之间的协作模式往往严重受阻于繁重的工单系统。申请某项资源不仅周期漫长，缺乏有效校验，而且通常伴随着“通过邮件发送电子表格”这种低效且容易出错的做法。为了打破这种瓶颈，NetOrca 构建了一个面向大型企业的自动化编排平台： - **服务提供端**：基础设施或平台服务团队在 NetOrca 平台上定义并发布标准化的服务能力。 - **服务消费端**：500 多个内部开发团队直接通过他们日常工作的 Git 仓库（代码库）来发起资源与服务请求。 - **状态与变更管理**：将原先基于工单的流程彻底转变为以 Git 为核心的声明式变更流程，对整个系统的状态及变更历史进行严密追踪。尽管这套架构最初是为纯自动化场景设计的，但随着企业客户对引入 AI 及 AI Agent 的需求日益迫切，团队敏锐地发现：这套能够管理声明式意图、保障良好数据校验与状态追踪的底座，恰好是运行智能体自动化（Agentic Automation）的理想土壤。 --- ### [01:26](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=86s) 针对受监管行业的 Agentic 架构：多智能体决策与自愈循环为了在严格受监管的金融行业中安全引入 AI，NetOrca 推出了核心扩展组件——NetOrca Pack。该架构从客户发起的服务请求（声明式意图状态）出发，触发一个具备自愈能力的实时 AI Agent 执行闭环。针对银行等强监管合规要求，NetOrca 采取了明确的技术路径：平台绝不向银行兜售未经认证的外部模型，也不要求客户从零训练私有大模型，而是**直接调用银行内部已经通过合规审批并托管的模型 API**。这一策略帮助平台顺利通过了企业安全与合规治理的严苛审查。 ```mermaid flowchart TD accTitle: NetOrca 多智能体决策与自愈架构 subgraph Input ["声明式意图输入"] A["500+ 开发团队 (Git 声明)"] --> B["NetOrca 变更实例"] end subgraph AgentLoop ["多智能体决策与自愈循环"] B --> C["配置生成层 (如 GPT-4o / Claude)"] C --> D["验证检查层 (独立模型/Agent)"] D -- "校验通过" --> E["执行决策层 (Execute Layer)"] D -- "存在分歧 / 校验失败" --> F["自愈重试触发 (Re-trigger)"] F --> C end subgraph Automation ["传统自动化基础设施"] E --> G["Ansible / Terraform / CloudFormation 等"] end ``` 在系统执行流程中，多 Agent 协同与自愈机制具体表现为： - **多智能体交叉校验**：利用配置层（Config Layer，例如调用高阶模型）生成初始决策，再由独立的验证层（Verify Layer，例如轻量高效模型）进行检查与对比，避免单点幻觉。 - **自愈与重试机制（Self-Healing Loop）**：当配置层与验证层产生分歧、决策未能通过校验或 API 执行遇阻时，执行层（Execute Layer）有权主动发起重试（Re-trigger），在闭环内持续修正。 - **平台无关的自动化对接**：一旦多智能体闭环达成一致决策，输出将无缝对接至企业现有的自动化工具链（如 Ansible、Terraform、AWS CloudFormation 等），在实际执行基础设施变更之前构筑起严密的决策结构。 --- ### [03:27](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=207s) 破局金融高价值场景：10,000+ 防火墙规则评估与三级分流为了在银行落地高价值业务场景，NetOrca 锁定了痛点极其突出的业务——**防火墙规则评估（Firewall Rule Assessment）**。在大型银行中，成百上千的应用频繁需要申请访问外网或与其他内部团队系统互联，每年会产生 10,000 条以上的防火墙规则变更请求。过去，每条规则都必须由安全工程师依据复杂的合规标准逐一手动审核；然而面对安全团队规模缩减与安全标准日益严苛的双重压力，人工逐条审查已导致严重的效率瓶颈与积压。 NetOrca 将该流程转化为可自动化的 Agent 决策管道： ```mermaid flowchart LR accTitle: 防火墙规则智能分流评估流程 subgraph Sources ["输入上下文"] S1["防火墙规则声明"] S2["策略即代码 (Policy as Code)"] S3["客户合规认证文档 (Attestation)"] end subgraph Assessment ["多模型独立评估"] S1 & S2 & S3 --> M1["模型 A 独立审查 (如 Claude)"] S1 & S2 & S3 --> M2["模型 B 独立审查 (如 ChatGPT)"] end subgraph Triage ["风险分级与分流"] M1 & M2 --> T["智能分流 (Triage)"] T -->|高风险| H["安全工程师人工介入审批"] T -->|中 / 低风险 (如 Dev-to-Dev)| L["直接放行并触发自动化部署"] end ``` 该方案的核心落地点包括： - **完整上下文注入**：向 Agent 注入防火墙规则声明、预审批清单、安全团队制定的“策略即代码（Policy as Code）”以及应用所有者提供的预先合规证明（Attestation），杜绝裸模型直接推理。 - **防偏见独立评审**：让不同的主流模型（如 Claude 与 ChatGPT）分别进行独立评估，严格禁止将前一个模型的审批结果透传给下一个模型，防止模型间产生从众偏差。 - **风险分级分流（Triage Step）**：系统明确定位为“智能分流与初审”，而非简单粗暴地取代所有人： - **高风险（High Risk）**：路由给专业安全工程师进行重点人工复核。 - **中/低风险（Medium/Low Risk）**：如完全符合策略的开发环境互访规则（Dev-to-Dev），经独立多模型验证后直接免人工放行。 - **显著降本增效**：在全行每年 10,000+ 条防火墙规则中，预计约有 **8,000 条**属于中低风险范围，从而削减了绝大多数繁杂的人工机械审查工作。 --- ### [06:01](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=361s) 范式革新：从“一次性审批”到“按需持续评估”及场景横向扩展传统企业运维中，防火墙规则等安全配置存在致命的“一次性审批”盲区——规则往往仅在创建时被检查一次，此后数年便无人问津。两三年后，随着组织调整或团队解散，企业经常出现“谁批准了这条规则、该规则归属何人”的幽灵资产隐患。而引入 AI Agent 后，安全治理模式被彻底重塑为**持续性评估（Continuous Assessment）**： - **策略变更动态重算**：当企业的全局安全策略发生更新，或团队的合规认证发生变化时，系统可以全量重新触发 AI 评估闭环，生成最新的合规报告。 - **成本与安全程度的弹性调节**：安全检查不再受限于有限的人力，而是转变为一个“成本杠杆（Cost Lever）”——企业可以根据安全预算与防御诉求，自由将评估周期设定为按小时、按天或按周运行，"想要多高的安全性，就可以调高多大的检查频率"。这种**“声明式输入 → Agent 审查分流 → 自动化落地”**的可审计、可复用模式已展现出强大的可复制性。例如在**灾难恢复（Disaster Recovery, DR）合规检查**中，Agent 同样可以自主评估某项配置是否需要同步部署至异地备用网络环境。最后，Scott 总结道，NetOrca 已经成功在生产环境中将 AI 用于基础设施自动化前置决策的全流程，并在展区提供完整的现场 Demo 演示。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=4s) 申请某项资源不仅周期漫长，缺乏有效校验，而且通常伴随着“通过邮件发送电子表格”这种低效且容易出错的做法。 — Scott Rowlandson > [00:04](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=4s) 这套能够管理声明式意图、保障良好数据校验与状态追踪的底座，恰好是运行智能体自动化（Agentic Automation）的理想土壤。 — Scott Rowlandson > [01:26](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=86s) 直接调用银行内部已经通过合规审批并托管的模型 API。 — Scott Rowlandson > [01:26](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=86s) 利用配置层（Config Layer，例如调用高阶模型）生成初始决策，再由独立的验证层（Verify Layer，例如轻量高效模型）进行检查与对比，避免单点幻觉。 — Scott Rowlandson > [01:26](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=86s) 在实际执行基础设施变更之前构筑起严密的决策结构。 — Scott Rowlandson > [03:27](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=207s) 面对安全团队规模缩减与安全标准日益严苛的双重压力，人工逐条审查已导致严重的效率瓶颈与积压。 — Scott Rowlandson > [03:27](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=207s) 让不同的主流模型（如 Claude 与 ChatGPT）分别进行独立评估，严格禁止将前一个模型的审批结果透传给下一个模型，防止模型间产生从众偏差。 — Scott Rowlandson > [03:27](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=207s) 系统明确定位为“智能分流与初审”，而非简单粗暴地取代所有人。 — Scott Rowlandson > [03:27](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=207s) 在全行每年 10,000+ 条防火墙规则中，预计约有 8,000 条属于中低风险范围，从而削减了绝大多数繁杂的人工机械审查工作。 — Scott Rowlandson > [06:01](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=361s) 规则往往仅在创建时被检查一次，此后数年便无人问津。两三年后，随着组织调整或团队解散，企业经常出现“谁批准了这条规则、该规则归属何人”的幽灵资产隐患。 — Scott Rowlandson > [06:01](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=361s) 安全检查不再受限于有限的人力，而是转变为一个“成本杠杆（Cost Lever）”——企业可以根据安全预算与防御诉求，自由将评估周期设定为按小时、按天或按周运行，“想要多高的安全性，就可以调高多大的检查频率”。 — Scott Rowlandson > [06:01](https://www.youtube.com/watch?v=ONd4veLQ_Io&t=361s) 声明式输入 → Agent 审查分流 → 自动化落地 — Scott Rowlandson ## Mentioned Scott Rowlandson, NetOrca, NetOrca Pack, NatWest Bank, Git, GPT-4o, Claude, ChatGPT, Ansible, Terraform, AWS CloudFormation, Policy as Code ## Video description Scott Rowlandson - Founder, NetOrca Modern “AIOps” mostly means better alerts and nicer dashboards. The hard part, actually operating infrastructure, still relies on humans writing integrations, stitching together tools, and executing runbooks under pressure. In this session I’ll show a different pattern: AI agents as operators, where the agent can plan and execute real changes safely across your existing systems. The key is a “universal executor” approach: instead of building and maintaining bespoke integrations, we give the agent the API documentation (or OpenAPI spec), plus a small set of operational guardrails, and it generates the required calls, validates the outcome, and self-heals when the real world pushes back (rate limits, inconsistent schemas, partial failures, missing permissions, stale state, etc.). I’ll walk through what we built at NetOrca (our self-service infrastructure orchestration platform) and what we learned running it in production at NatWest Bank — at enterprise scale, with real constraints and real consequences. You’ll see how we handle the messy parts people skip in demos: idempotency, retries, rollback strategies, state-machine concurrency, noisy or contradictory API docs, safe prompting, and how we prevent an agent from “doing the wrong thing” when it’s confident but incorrect. We’ll cover: The architecture: planning → execution → validation → repair loop (and why “tool calling” alone isn’t enough) How to make “docs → execution” reliable in the face of bad specs and unpredictable APIs Guardrails that work in practice (scopes, allowlists, policy checks, change windows, blast-radius limits) Observability: how you debug agent actions like you debug humans (audit trails, structured step logs, reproducible runs) What enterprise adoption actually looks like: trust-building, controlled rollout, and the line between automation and autonomy If you’re building agentic systems for infrastructure, DevOps, network/security ops, or internal platforms, you’ll leave with a concrete blueprint for moving beyond copilots and into agentic operations that ship real changes plus the production lessons that only show up when you run this stuff for real. [Source](https://www.youtube.com/watch?v=ONd4veLQ_Io)

Source quotes

[0:04] Scott Rowlandson: 申请某项资源不仅周期漫长，缺乏有效校验，而且通常伴随着“通过邮件发送电子表格”这种低效且容易出错的做法。 [0:04] Scott Rowlandson: 这套能够管理声明式意图、保障良好数据校验与状态追踪的底座，恰好是运行智能体自动化（Agentic Automation）的理想土壤。 [1:26] Scott Rowlandson: 直接调用银行内部已经通过合规审批并托管的模型 API。 [1:26] Scott Rowlandson: 利用配置层（Config Layer，例如调用高阶模型）生成初始决策，再由独立的验证层（Verify Layer，例如轻量高效模型）进行检查与对比，避免单点幻觉。 [1:26] Scott Rowlandson: 在实际执行基础设施变更之前构筑起严密的决策结构。 [3:27] Scott Rowlandson: 面对安全团队规模缩减与安全标准日益严苛的双重压力，人工逐条审查已导致严重的效率瓶颈与积压。 [3:27] Scott Rowlandson: 让不同的主流模型（如 Claude 与 ChatGPT）分别进行独立评估，严格禁止将前一个模型的审批结果透传给下一个模型，防止模型间产生从众偏差。 [3:27] Scott Rowlandson: 系统明确定位为“智能分流与初审”，而非简单粗暴地取代所有人。 [3:27] Scott Rowlandson: 在全行每年 10,000+ 条防火墙规则中，预计约有 8,000 条属于中低风险范围，从而削减了绝大多数繁杂的人工机械审查工作。 [6:01] Scott Rowlandson: 规则往往仅在创建时被检查一次，此后数年便无人问津。两三年后，随着组织调整或团队解散，企业经常出现“谁批准了这条规则、该规则归属何人”的幽灵资产隐患。 [6:01] Scott Rowlandson: 安全检查不再受限于有限的人力，而是转变为一个“成本杠杆（Cost Lever）”——企业可以根据安全预算与防御诉求，自由将评估周期设定为按小时、按天或按周运行，“想要多高的安全性，就可以调高多大的检查频率”。 [6:01] Scott Rowlandson: 声明式输入 → Agent 审查分流 → 自动化落地

Source quotes

[0:04] Scott Rowlandson: attaching a spreadsheet to an email Scott Rowlandson: Modern “AIOps” mostly means better alerts and nicer dashboards. Scott Rowlandson: The hard part, actually operating infrastructure, still relies on humans writing integrations, stitching together tools, and executing runbooks under pressure. Scott Rowlandson: instead of building and maintaining bespoke integrations, we give the agent the API documentation (or OpenAPI spec), plus a small set of operational guardrails, and it generates the required calls, validates the outcome, and self-heals when the real world pushes back Scott Rowlandson: how we prevent an agent from “doing the wrong thing” when it’s confident but incorrect. Scott Rowlandson: planning → execution → validation → repair loop (and why “tool calling” alone isn’t enough) Scott Rowlandson: how you debug agent actions like you debug humans (audit trails, structured step logs, reproducible runs) [6:01] Scott Rowlandson: How secure do you want to be? How much do you want to check these things? Scott Rowlandson: moving beyond copilots and into agentic operations that ship real changes plus the production lessons that only show up when you run this stuff for real.

Original transcript

[0:04] Hey everyone. Hope you are all well this morning. My name is Scott Rollinson. I'm the founder of [0:09] Netacea. And I just want to take you through a little bit what we've been doing with one of our [0:14] tier one banking customers in the UK. We're a London-based startup. [0:18] So, to give you a bit of background information, Netacea is a automation orchestration platform. [0:25] And what we do is go into large enterprises and we give service providing teams within [0:30] that organization the ability to offer a service via our platform and then consuming teams like [0:34] developer teams to consume that that service via a Git repository or where they work as a [0:39] as a development team. And basically, the idea is that we kind of replace the old-school [0:44] ticketing-based systems that you've probably all seen at enterprise. Requesting something [0:49] from another team takes a long time. It's not well validated. You know, it's often attaching [0:53] a spreadsheet to an email, that kind of thing. And we move it to a Git-based process. And then [0:58] we track the the state and the change management of that. Now, this was all built to do automation. [1:04] You know, and and the savings we give to the enterprise is about automation. But what we found [1:08] very quickly and as AI and AI agents started to to come into those customer requirements, [1:14] that same setup that is good for automation works really well for agentic automation or or bringing [1:20] AI agents into it. So, basically, what we've released and we've got running in production with [1:26] our customer now is Netacea Pack, which is our add-on. And the idea is we take a customer state, [1:31] so we take a request of a service, and we trigger a self-healing agentic AI live off the back of it, [1:38] which can effectively do anything. And working in regulated industries, we're not selling them [1:43] LLMs. We're not selling them custom-trained models that they need to do. We're making API calls to [1:48] the models that they have internally. And that's what gets us past the governance and gets thing [1:52] in place. And the the idea is you can use multiple agents, so one agent checking another [1:58] and self-healing part is we give it the ability to re-trigger. So, if something fails or a decision's [2:03] not correct or it's not, you know, the config and verify layer maybe disagree, then the execute [2:09] layer has the ability to make a decision to re- to re-trigger that. And it's all, as I said, based on [2:16] a change managed declarative customer intent. So, we're starting with good validated data and then [2:22] using that to trigger AI agents. As opposed to, you know, let's just grab our old documentation, [2:28] send it to the AI agents. Let's start with something that's very highly automatable, [2:32] send it to AI agents and then give us the ability to iterate on that problem and and go through it. [2:38] Now, basically the process works like this. Um, and we've deployed this at scale. So, [2:43] on the left side we've got customers, so we've got 500 internal teams within this customer. [2:48] They put a request through to NetOrchestra. A change instance goes and then the loop triggers [2:52] to make a decision. And, you know, one of the examples is using GPT-56 Soul as the [2:58] the config, the first first iteration of AI agents, and then GPT-5 Mini, [3:03] um, which is now probably uh Luna, uh as the the check step for that. And then getting that to [3:09] make a decision that we would then treat uh feed into traditional automation. So, whether that's [3:16] Ansible, Terraform, AWS CloudFormation, it doesn't matter. We're platform agnostic. [3:20] But, the point is we create a structure to make decisions before that automation happens. Now, [3:27] this process has been in place for a while, but we we went to the customer and said, "Okay, [3:31] you know, we have the ability to do this. What are some high-value outcomes that we can actually [3:35] um put this process in place for?" And the case that came up very quickly was [3:41] firewall rule assessment. So, if you're in a large enterprise like a bank, um a lot of people request [3:46] firewall rules. They need a They need a app that needs to talk to the internet or needs to talk to [3:51] other teams within the enterprise. And normally what happens is that rule has to be assessed [3:56] versus criteria. So, you need a security engineer to come in and check every rule effectively [4:01] and make sure things are okay. Um and that inherently creates a scale problem, [4:06] especially as we're going to more cybersecurity focused. They want to check everything. So, [4:10] this customer had 10,000 plus firewall rules per year, that a declining security team, [4:15] but they wanted more accuracy, which is is it's creating a problem in and of itself. Um and so the [4:21] solution where we've got in production now is to say, "Well, can we can we take that information, [4:26] get it in a automatable way, and use this AI loop to make a decision on it?" Um and the the idea [4:32] there is we get a firewall rule declaration, we feed into the loop um policies, so the policy as [4:39] code, so what security wants, what the firewall rules should be, and what's pre-approved. And [4:45] then we also have some some customer attestation, so maybe some pre-approved documentation that the [4:52] customer's done on behalf saying our our app's going to talk to these things. Um [4:56] and we add that as context to the AI. So, we're not just we're sitting with a bare model here. [5:02] And then we get, you know, Claude, ChatGPT to independently make an assessment. [5:08] So, we don't send the approval from one to the approval of other cuz that would bias it. So, we [5:12] independently get to them to make an assessment. And that basically takes the place of what what [5:17] a security engineer would do individually. We treat this as a triage step. So, importantly, [5:22] we don't say this is the final approval. What we do is put them into high, medium, and low buckets. [5:28] So, basically, a high risk needs to go to a security engineer for manual approval, [5:32] but low risk, if it meets all the criteria and AI's independently assessed that, then why do [5:37] you need a security engineer to check that if it's a dev-to-dev rule or something like that? [5:41] And that's where we start to get, you know, real high efficiencies from, you know, 10,000 rules. [5:47] It's it's in production now, but slowly starting to be used. But I'm I'm predicting that probably [5:52] 8,000 of those are going to be in the medium blue range. So, we've cut out a huge amount of work. [5:56] And then after that, you know, the traditional automation fires off and there we go. [6:01] And the real powerful thing here is you traditionally with firewall rules you would assess [6:05] once on the way in and you never look at that again. Now, the ability for AI that AI provides to [6:11] us is the ability to continuously assessment. So, if our enterprise policy changes, if our customer [6:17] attestation changes, we can re-trigger this loop and get a fresh assessment. That's something that [6:23] would never happen in enterprises. You get an approval once from 2 years ago, [6:26] no one ever look at it again. 3 years later that team's disbanded or who owns this firewall rule, [6:32] you know, who approved this? So, now we can do a, you know, hourly, daily, weekly, whatever. And it [6:37] just becomes a cost lever. How secure you want to be? How much do you want to check these things? [6:43] And so, the idea is we we create less work by creating a triage system and a triage system not a [6:49] full on remove everyone approve. Um we create more security cuz it's continuous assessment just not [6:56] just a one and done and forget about it. And and like I said, it's a dial up in how much security [7:02] you want to create. Not a, you know, set amount. And the same pattern we found once we put that in [7:10] starts to repeat for a whole lot of use cases. So, that same firewall assessment [7:15] um allows us to do disaster recovery checks. So, that's to see if maybe a rule needs to be deployed [7:22] to another uh part of the network. Can we make an assessment from that? And effectively we then say, [7:28] "Well, okay, we take that existing automation ecosystem and any decision we want to make [7:33] on the back of that before we trigger the automation, we can now do with AI [7:37] and we can now do it in a repeatable, auditable manner um that's continuous, not just one-off. [7:44] And basically, that's what what I wanted to talk to you about today. That's in production. [7:48] We've got a booth down in the startup stage. So, come talk to us. I can do a live demo of that, [7:54] and I can do a bunch of other use cases. So, thanks for your attention, and enjoy the day.