David Mytton，Arcjet CEO – 采访系列

David Mytton， 是 Arcjet 的创始人和 CEO，这是一家面向开发者的安全初创公司，帮助团队将强大的保护措施（如 bot 检测、速率限制、电子邮件验证、攻击缓解和数据删除）直接嵌入应用程序代码，他于 2023 年 6 月接任 CEO 一职。他还联合创办了 Console，一份广受欢迎的开发工具新闻通讯和播客，并曾担任过 Seedcamp 的专家驻地顾问等咨询角色，此前他曾在 StackPath 负责产品工程，之后他的云监控公司被收购，同时他一直对可持续计算保持着浓厚的兴趣，并积极撰写技术主题的文章。

Arcjet 以“安全即代码”（security-as-code）的理念为基础，允许开发人员通过简单的 SDK 集成来保护应用程序，安全逻辑与业务逻辑并置，实现低延迟、上下文感知的决策，并消除了对单独基础设施的需求；该平台支持诸如 bot 阻塞、速率限制和敏感数据过滤等保护措施，并继续通过诸如本地 AI 安全模型和扩展框架支持等功能演进，反映出其使应用程序的内置安全成为默认设置的使命。 (fly.io）

您在基础设施标准化程度远不如今天的情况下创立了 Server Density，并最终将其发展并出售。回顾过去，您从中学习到的关于为开发人员构建和运营生产系统的最重要的经验是什么，您又是如何将这些经验运用到您今天对软件的思考中？

大多数开发者工具都能赢得演示，但输掉了生产。让开发人员安装任何新东西都很困难，因此“快速开始”必须是无摩擦的 – 但这只是基本要求。真正的失败模式是“它可以工作”之后发生的事情：产品变得受到限制，所以严肃的团队很快会感到沮丧并将其移除。

这就是为什么 Arcjet 的内置应用程序安全性是为两个现实而设计的：您需要一个立即的解决方案来解决注册垃圾邮件、账户欺诈、bot 攻击、API 滥用等问题，您还需要一个到高级控制的逃生口 – 每用户配额、基于风险的规则和上下文感知决策 – 而无需重写一切。

产品不是 UI。产品是运行时行为、边缘情况、示例和开发人员可以信任的参考文档。

基于您之前的经验，您是什么时候开始创立 Arcjet 的，为什么您觉得下一次重大应用程序安全转变需要发生在代码内部，而不是在网络或基础设施层？

周界安全性是在优化错误的东西。开发人员在代码中构建和交付应用程序，而不是在仪表板中 – 而 AI 编码代理不会“点击”安全控制台来保护应用程序。

如果您的保护措施不能以代码形式表达、在拉取请求中审查、在 CI 中测试并与应用程序一起部署，那么它就不是“面向开发人员的安全性”。

Arcjet 之所以存在，是因为安全性属于应用程序层：版本控制、可测试、可观察，并且与业务逻辑紧密相关，意图实际上就在那里。

Arcjet 将 AI 驱动的威胁检测直接嵌入应用程序请求处理程序。从技术角度来看，与传统的周界安全工具相比，内置的代码方法有什么优势？

在请求处理程序内部，您拥有身份、会话状态、购买历史、账户年龄、功能标志和数据库真相。您可以做出这样的决定：“这看起来很奇怪，但这是一个忠实的客户 – 增加验证而不是阻塞。”网络代理无法做到这一点，因为它不知道“客户”是什么。

目标不是最大化阻塞。目标是使用上下文感知安全性来最小化假阳性，因为最昂贵的安全错误是阻塞合法的结账或锁定真实用户。

AI Dramatically 改变了滥用行为的经济效益，从 bot 抓取和垃圾邮件注册到自动化 API 利用。您今天在生产中看到最常见的攻击类型是什么，它们又是如何随着攻击者采用更先进的 AI 系统而演变的？

AI 的生产力收益也帮助了攻击者！最大的转变是体积和迭代速度：更多的凭证填充、更多的自动注册垃圾邮件、更多的 bot 抓取、更多的 API 探测和更快的新漏洞“武器化”。

我们还看到攻击者运行更紧密的反馈循环：他们测试防御、适应提示和有效载荷、轮换基础设施，并继续尝试直到他们成功。目前，这一切都是关于速度而不是复杂性。

仍然有太少的人遵循最佳实践，例如使用密码管理器、部署具有抗钓鱼的密码管理器或硬件密钥的双因素身份验证，并保持依赖项更新。随着攻击量的增加，这将变得越来越重要。

安全领域最大的紧张关系之一是保护应用程序而不减慢开发速度。使用 Arcjet 的团队如何将安全性集成到工作流中，同时保持快速的发布周期？

Arcjet 可以在任何环境中运行，包括在笔记本电脑上的编码环境中。这意味着开发人员可以在不部署到生产环境的情况下测试它。这是一个显著的优势，因为您可以在不需要特殊权限和不影响生产环境的情况下验证和演示集成。这解决了安全团队强迫开发人员采用会阻碍他们工作的工具的经典问题。

Arcjet 已经在 AI 本地产品和电子商务平台上获得了早期的牵引力。是什么使得这些环境特别容易受到现代自动化攻击，为什么传统的防御措施往往不足？

这两个类别有一个共同点，即每个滥用请求都有直接的成本。

AI 产品为令牌和推理付费 – 攻击者将您的利润率转变为他们的游乐场，通过抓取、自动化和免费层次的耕作。电子商务付费欺诈、退款、库存滥用和账户接管。两者都对假阳性非常敏感，因为阻塞真实用户实际上就是收入损失。

传统防御主要保护带宽和基础设施。现代攻击者针对业务逻辑：注册流程、结账流程、促销逻辑、账户恢复和 API 端点。这就是为什么通用周界控制和“用 CAPTCHA 解决它”的方法越来越不够用。

构建安全软件与构建可观察性或监控软件相比，有着非常不同的权衡。与您之前的基础设施工具经验相比，开发安全产品最让您惊讶的是什么？

在可观察性方面，客户信任您是可用的。在安全性方面，客户信任您是安全的，并且不会成为他们的最新供应链漏洞。

构建安全产品意味着运行安全公司。我们使用框架，如 SOC 2，尽量减少第三方依赖，并将开发人员的笔记本电脑和工具访问视为生产资产。这意味着大量的监控和快速响应潜在问题。

随着应用程序越来越多地依赖 AI 代理代表用户行事，开发人员应该如何重新思考应用程序层面的身份、意图和信任等概念？

当 AI 代理代表用户行事时，身份不再是二进制登录状态，而是一个委托问题：谁在行为，代表谁，以什么权限，多久，并且有何约束。

开发人员应该转向持续验证：将每个请求视为需要一个新的信任决策，基于上下文 – 用户历史、设备信号、会话行为和操作风险。“意图”是从行为中推断出来的，而不是在头部声明的。

这意味着在高风险操作周围构建步骤（验证、速率限制、摩擦），例如密码重置、结账和令牌创建 – 并使这些控制措施内置于代码中，应用程序可以区分忠实的客户和具有被窃 cookie 的 bot。

展望未来，随着 AI 生成的流量继续增长，您预计内置的、上下文感知的安全性在未来几年内将如何演变？

周界工具不会消失 – 但它们将成为处理网络最佳的东西的粗略过滤器，例如 DDoS 攻击。精确的决策将在应用程序内部发生，使用真正的上下文。

如果内置安全性成为现代应用程序的默认模型，那么这对开发人员如何测试、部署和推理生产系统中的安全性意味着什么？

如果内置安全性成为标准，团队将以与测试正确性相同的方式测试滥用：安全单元测试、可重放的攻击模拟和 CI 检查风险端点。

更大的转变是，AI 编码代理将以代码的形式实现安全性，而不是仪表板配置。代理只能可靠地提出、审查和验证保护措施，当控制措施在存储库中时：策略、规则、测试和仪表。 如果“安全层”是一个 Web UI，代理无法测试更改以安全地交付。

这就是“安全代码”获胜的真正原因 – 它符合现代软件（和现代 AI 辅助开发）实际上是如何构建的。

感谢这次精彩的采访，希望了解更多的读者可以访问 Arcjet。