Surfaced during the v0.1.0 review (PR #2). Filing as v0.2 work since the mitigation is policy-side and doesn't change the wire format.
§9.1 says an approver's grant on an ASK MAY include an intent_extension with scope: "session", and the Guardian MUST append the granted capabilities to Intent.parsed. There's no bound on how many times this can happen in one session, no cooldown, and no rule that an extension must cite an already-parsed capability.
The failure mode: a malicious agent starts under a narrow Intent like ["read public docs"], then over the course of a session repeatedly ASKs for adjacent capabilities. ["read internal docs"], then ["network.egress to slack.com"], then more. Each ASK is framed as the natural next step. Under consent fatigue, an approver who would never grant the full capability set up front grants it one step at a time. The audit chain shows clean grants. IBAC's central capability-narrowing claim (§8.4) is procedurally defeated.
Proposed direction:
ask-details.json SHOULD recommend a Guardian-side cap on intent_extension count per session- Normative rule that an
intent_extension MUST either (a) cite a parsed capability already present that it narrows or specializes, or (b) be flagged in the audit chain as a scope-broadening grant
- Trace event for every intent_extension with a session-cumulative counter so anomaly detection has signal
Why deferred from v0.1.0: the mitigation lives in policy and approver UI, not the wire format. v0.1.0 can ship without breaking IBAC. v0.2 should land the cap before any production IBAC deployment.
References: specification.md §9.1, defer-details.json, ask-details.json
Surfaced during the v0.1.0 review (PR #2). Filing as v0.2 work since the mitigation is policy-side and doesn't change the wire format.
§9.1 says an approver's grant on an ASK MAY include an
intent_extensionwithscope: "session", and the Guardian MUST append the granted capabilities toIntent.parsed. There's no bound on how many times this can happen in one session, no cooldown, and no rule that an extension must cite an already-parsed capability.The failure mode: a malicious agent starts under a narrow Intent like
["read public docs"], then over the course of a session repeatedly ASKs for adjacent capabilities.["read internal docs"], then["network.egress to slack.com"], then more. Each ASK is framed as the natural next step. Under consent fatigue, an approver who would never grant the full capability set up front grants it one step at a time. The audit chain shows clean grants. IBAC's central capability-narrowing claim (§8.4) is procedurally defeated.Proposed direction:
ask-details.jsonSHOULD recommend a Guardian-side cap onintent_extensioncount per sessionintent_extensionMUST either (a) cite a parsed capability already present that it narrows or specializes, or (b) be flagged in the audit chain as a scope-broadening grantWhy deferred from v0.1.0: the mitigation lives in policy and approver UI, not the wire format. v0.1.0 can ship without breaking IBAC. v0.2 should land the cap before any production IBAC deployment.
References:
specification.md§9.1,defer-details.json,ask-details.json