Marico's space

能不能测出一个 AI 编程 Agent 越过工具边界的频率有多高——在免费服务器上安全测试，不碰一个真实文件？完全可以：给它一堆假工具，只记录调用日志，在假文件里埋陷阱指令，然后对着日志打分。这篇就是我自己搭的测试框架，亲测有效，而且只要能跑 Python 的地方就能跑——包括免费档次的服务器加免费模型接口，我就是这么跑的。 上周又刷到一个帖子讨论 AI Agent 越来越多功能——Shell

最近在研究CompTIA Security+ (SY0-701)认证的内容，发现安全架构这块知识点挺多而且挺重要。这篇把相关概念捋一遍，方便以后复习，也给同样在准备考试的同学做个参考。 安全架构（Security Architecture）简单说就是保护信息、网络和关键运营的技术系统设计。对于想在国防部(DoD)这类军事和政府机构从事网络安全的同学来说，理解不同架构如何提升安全性、可用性、韧性和

部署是 AI Agent 运行中断最常见的原因。不是崩溃，不是超时——就是一次普通的下午发布，而一个 14 步的运行任务刚好卡在第 9 步。 Pod 收到 SIGTERM，内存里的东西全没了。如果任务重试，就得从零开始，把那 9 步重新跑一遍，副作用也重新执行一遍。 要让这个过程变得可靠，需要四件独立的东西，但团队通常只做了其中一件就觉得万事大吉了。 1. 进程外部的状态 如果你用 La

最近在给一个客服 AI Agent 做安全加固，踩了几个权限控制的坑，这篇把核心问题说清楚。 大多数 Agent 的起步都是一样的：给它配一个服务账号，绑定到系统上，再写几个工具调用，基本就能跑了。 但问题在于，你实际上造出了一个"能做任何用户能做的事"的组件，唯一驱动它的是语言模型，而它读取的内容可能来自工单、网页或者用户上传的文档。所以"Agent 什么都能做"到"Agent 做了不该做的

做过公开表单接口的应该都有过这种经历：接口跑得好好的，突然有一天数据库账单翻了几倍，查日志才发现有个客户端在不断重试，一秒钟请求了上千次。这种事情发生一次就够刻骨铭心了。 现在每个有公开接口的项目，我都会上这套防护方案。 1. 用 UPSTASH 做速率限制 Upstash 的 Redis 方案对 Next.js 很友好，专门为无服务器场景设计，每次请求不需要保持连接。 npm inst

最近折腾了 AI Agent 的权限继承问题，踩了几个坑，这篇把核心问题说清楚。 当一个 AI Agent 需要做实际工作时，最危险但省事的做法就是给它一个 API Key，然后祈祷 prompt 能管住它。 这条路走不通。一个有用的 Agent 现在可以读取工单、创建 issue、更新 CRM 记录、运行查询、触发工作流、调用内部工具。如果这些都通过一个宽泛的 Key 来做，你有的不是用户权

最近在给项目接 Ace Data Cloud 的登录功能，官方文档写得很散，自己踩了几个坑才跑通。这篇把 OAuth 2.0 配合 PKCE 的完整流程梳理一遍，包括注册应用、生成授权链接、换取令牌、调 API，都覆盖到。 能做什么 如果你需要代表用户访问 Ace Data Cloud 的资源，让用户手动复制 API Key 是个很糟糕的体验。更合理的做法是用 OAuth 2.0 授权码流程

"同样的问题，今天花了四十秒。上周只要十秒。" 又是第2、3部分那位测试同学。她问Agent："我能退掉上一单的那件蓝色外套吗？"这个问题需要两次工具调用：一次查订单，一次读退换政策。上周大概十秒搞定。那天花了四十秒。 什么都没变。没有发布新版本，没有改配置，没有新数据。代码一周没动过。 但我解释不了，因为我没有任何一个步骤的具体耗时。我有日志，但那是一堆HTTP层的文本堆砌。我说不清那多出

最近看到 Pillar Security 披露的 Google ADK（Agent Development Kit，智能体开发工具包）安全漏洞，忍不住想聊聊这事儿。AI 工作流自动化听着很爽，但权限管理一旦没到位，分分钟被人拿来做坏事。这篇把漏洞的来龙去脉和技术细节捋清楚，看完你就知道现在 Agent 系统里那些"自动化"到底埋了多少雷。 自动化仓库里的利用路径 核心风险在于一个 triag

最近在整理Google AI产品线，发现NotebookLM改名这事儿比我想象的要复杂一些——不只是换个名字那么简单，实际的访问权限部署是分阶段的。这篇把我查到的信息整理一下，顺便说说对实际使用的影响。 简单说就是：Gemini Notebook（原NotebookLM）确实在扩大覆盖范围，但官方说的是"分阶段发布"，不是所有订阅用户同时拿到。有几个坑值得注意，特别是如果你打算基于这个产品设计工