{
  "id": 15140596,
  "title": "递归的尽头：Agent 自举",
  "url": "https://urgent.news/2026/10/17/agent",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-17T06:53:16.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/maref/di-gui-de-jin-tou-agent-zi-ju-9b8"
  },
  "original_language": "en",
  "account": "On the third night, the page displayed the same line from two nights prior: policy.deny agent=catalog-sync tool=inventory.write reason=not_in_allowlist. The action of catalog-sync had been writing to inventory every twenty minutes for six months, and the list remained unchanged despite the business evolving. The permission layer governed a dozen or so agents, each linked to a few internal APIs. Initially, the allowlist was static, clearly defining what each agent could do. However, a release split a service, moving half the tool names, rendering the list technically correct but operationally ineffective.\n\nThe issue arose from a reconciliation loop that kept asking for permissions until a human intervened, causing the system to deny legitimate requests. This led to a week-long effort to patch the list, ultimately transitioning to dynamic authorization. In this new system, agents submit scoped requests against their grants, which are approved or denied by on-call personnel. The boundary of authorization adapts to business changes, with each modification documented.\n\nThe core problem lies in recursion within the system. An agent can spawn sub-agents, register new MCP servers, or modify its prompt, all of which allow it to alter the trust boundaries. A child agent at depth 3 capable of registering a server could create tools it wasn't granted, while a sub-agent with the ability to rewrite its parent's system prompt could change its own restrictions. This recursive nature negates the significance of the depth setting and emphasizes the importance of capabilities that cannot be delegated.\n\nTo address this, the system now issues a lease to every spawn, ensuring the agent cannot hold a writable copy of its own limits. Instead, it can query its permissions through the orchestrator. The orchestrator grants capabilities based on specific requests, preventing unauthorized actions and avoiding the pitfalls of capability inheritance. Each child agent receives a limited set of capabilities derived from the parent, and registering an MCP server is a deliberate, human-decided action.\n\nMemory management also posed a significant challenge, as agents write to their own namespaces, and shared reads could introduce unintended directives. To mitigate this, writes are namespaced to the lease, and promoted notes carry the lease ID, providing a clear return address for any issues. This design ensures that errors are traceable and that recursion remains a controlled process.",
  "summary": "The third night, the page was the same line I'd read the two nights before: policy.deny agent=catalog-sync tool=inventory.write reason=not_in_allowlist catalog-sync had been writing to inventory every twenty minutes for six months. It was still supposed to. The list hadn't changed. The business had. We owned the permission layer for an internal agent ecosystem — a dozen-ish agents at the time,…",
  "key_points": [
    "Recursive agents can spawn sub-agents, modify prompts, and alter trust boundaries.",
    "System now issues leases to prevent agents from holding writable copies of their own limits.",
    "Memory management improved by namespacing writes to leases and carrying lease IDs in promoted notes."
  ],
  "editors_take": "Shifting from static allowlists to lease-based orchestration prevents recursive agents from bypassing security boundaries by ensuring that sub-agents cannot unilaterally rewrite their own permissions or delegate unauthorized capabilities.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}