Arcjet 的 CEO David Mytton – 采访系列

David Mytton, 是 Arcjet 的创始人和 CEO，这是一家专注于开发者安全的初创公司，帮助团队将强大的保护措施，如 bot 检测、速率限制、电子邮件验证、攻击缓解和数据编辑，直接嵌入应用程序代码。他还联合创办了 Console，一份广泛关注的开发工具新闻稿和播客，并曾担任过 Seedcamp 的专家驻地、StackPath 的产品工程负责人等职务，同时也对可持续计算和技术话题保持着浓厚的兴趣。

Arcjet 以“安全即代码”的理念为基础，允许开发者通过简单的 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 探测和更快的“武器化”新漏洞。

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

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

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

Arcjet 可以在任何环境中运行，包括在笔记本电脑上的编码环境中。这意味着开发者可以在不部署到生产环境的情况下测试它。这是一个显著的优势，因为您可以在不需要特殊权限和不影响生产环境的情况下验证和演示集成。

Arcjet 已经在 AI 本地产品和电子商务平台上获得了早期的关注。这些环境为什么特别容易受到现代自动化攻击，而传统的防御措施又为什么容易失败？

这两个类别共享一个相似之处：每个滥用请求都有直接的成本。

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

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

构建安全软件与构建可观察性或监控软件相比，有很大的不同。您在开发安全产品方面最大的惊喜是什么，尤其是与您之前的基础设施工具经验相比？

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

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

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

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

开发者应该转向持续验证：根据上下文对每个请求进行新的信任决策 – 用户历史、设备信号、会话行为和操作风险。意图是从行为中推断出来的，而不是在头部声明的。

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

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

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

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

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

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

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

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