|
|
|
|
|
by jonnyasmar
23 days ago
|
|
The "no LLM in the decision path" framing is exactly the cut I'd want here. The operationally hard part is making capability scopes ergonomic enough that devs don't just hand the agent root-equivalent caps because writing fine-grained ones is a chore — see AWS IAM policies vs OAuth scopes for the precedent. Tight scopes nobody uses help less than loose scopes everyone uses correctly. Two questions on the threat model: 1. Can the LLM influence the capability presented to the tool? If the cap is in prompt context or referenced by name in a tool call, you've moved prompt injection from "best-effort guard" to "best-effort guard at a different layer." 2. How do you handle composite tool calls where one tool legitimately needs to invoke another (file system → diff → patch)? The capability has to flow but not amplify. |
|