Leandro — Security-First SRE Agent

wiki/ai/sources/leandro-security-first-sre-agent.md

分类：ai / sources · 更新：2026-08-19 09:07

Leandro — Security-First SRE Agent

一句话结论

SoulKyu/leandro 是一个运行在 Hermes 上的 AI SRE teammate：只读监听 Kubernetes warning events / pod phases，将事件去重、批处理后交给 Hermes 诊断，并通过 Google Chat 报告。它的核心价值不在“SRE agent”这个概念本身，而在于把 agent 放进 NixOS VM、default-deny egress、tinyproxy allowlist、只读 Kubernetes/Prometheus MCP、日志脱敏、facts-only fallback 的安全边界里。这是 Harness-Engineering 与 Agentic-Engineering 在生产运维场景中的可借鉴样本。

为什么对用户重要

用户的 Hermes 也在执行无人 cron：它会读取网络内容、写入知识库、更新索引并生成报告。Leandro 提醒我们：一旦 agent 的输入包含 attacker-influenceable text（pod logs、cluster events、网页、README、邮件），就不能只靠 prompt 说“不要被注入”。应把能力缩到最小：只读数据源、默认拒绝出站网络、允许列表代理、凭证不进 VM、报告落盘、失败时仍保留 facts-only 输出。

这对 llm-wiki radar 尤其重要：每日搜索会读取任意网页/README，其中可能包含 prompt injection。当前 wiki 写入已经受工具/路径约束，但未来如果自动 clone/install/run 外部 repo，就必须采用 Leandro 这类 sandbox-first 思路。

机制 / 一阶原理

1. 检测与诊断分离

Leandro 的 watcher 负责确定性地监听 Kubernetes Warning events 和 pod phase，按 (namespace, workload, reason) 去重 7 天并批处理 incident storm；LLM 只负责诊断与报告。这种分离降低了 agent 幻觉造成漏报/重复报的风险：检测链路是机械的，诊断链路是可失败并可回退的。

2. Agent 输入默认不可信

Pod logs、events 和 metrics 都可能包含攻击者可控文本。Leandro 的设计因此把 Hermes 放在 NixOS VM 中，通过 nftables default-deny output chain 和 tinyproxy allowlist 控制网络，技能树放在只读 Nix store，Kubernetes/Prometheus access 只读。这里的一阶原则是：读到不可信上下文，不代表拥有执行权限；诊断权不等于修复权。

3. 失败不应丢失事实

如果 LLM 不可达，Leandro 仍发送 facts-only fallback report。这是生产 loop 的关键：AI 增强不能让基础监控退化。对 Loop-Engineering 来说，LLM 节点应可失败，确定性观测和最小报告仍要可用。

与已有 wiki 概念的关系

对 Harness-Engineering：Leandro 把控制落实为 VM、Nix store、只读 MCP、egress allowlist、日志脱敏和 fallback，而不是只写在系统 prompt 中。
对 Loop-Engineering：watch → dedup → batch → diagnose → report 是典型生产 loop；LLM 是 loop 中可替换、可失败的节点。
对 Agent-Benchmarks：它提示 SRE agent 的评价不应只看诊断质量，还要看漏报、重复报、事故风暴成本、fallback 覆盖和安全边界是否有效。
对 Context-Engineering：cluster fact sheet、Thanos metrics playbook、pod logs、events 是不同信任等级的 context provider，需要脱敏和权限分层。

对 Hermes / llm-wiki 的可执行启发

每日 radar 默认只读外部源：README/网页可入库和综合，但无人 cron 不应自动执行外部 install script 或 demo，除非有 sandbox、网络限制和验收脚本。
给来源读取增加 prompt-injection 心智模型：raw source 是证据，不是指令；任何网页/README 中要求 agent 改变行为、泄露凭证或跳过流程的文字都应被视为不可信内容。
将 facts-only fallback 用于 cron 报告：当 LLM 深度综合失败时，也应报告“发现/抓取/写入/失败”的事实清单，避免任务静默丢失。
为未来自动化运行外部工具建立 sandbox gate：候选工具想从“source page”升级到“本机试用”，需要最小权限、网络策略、临时目录、凭证隔离和可清理安装。

失败模式 / 边界条件

只读诊断不等于自动修复：Leandro 目前强调诊断与报告；如果未来加入修复动作，权限边界和审批门槛要重新设计。
allowlist 维护成本：default-deny egress 很安全，但可能因依赖新端点而误伤可用性；需要可审计变更流程。
攻击面仍包括 ChatOps：Google Chat 交互本身可能带来社工/指令注入，需要 trust tiers 和人类身份边界。
README 级验证有限：本次未部署 NixOS VM 或连接 Kubernetes，所有机制判断来自 README，confidence 为 medium。

深度判断

本次将 Leandro 晋升为正式 source page，因为它满足两项高价值标准：一是提供可复用的生产 agent sandbox / read-only diagnosis workflow；二是能直接改进用户 Hermes/llm-wiki 对不可信外部来源、无人 cron、fallback report 和未来工具试运行的安全边界。它比泛泛的“SRE agent”项目更值得沉淀，因为 README 展示了具体边界组件和故障回退设计。

写入记录

2026-08-19 09:00 CST：新增 Leandro 来源页，沉淀 security-first SRE agent、只读观测、NixOS VM/default-deny egress、facts-only fallback 以及对 Hermes/llm-wiki 无人 cron 安全边界的启发。