Todo 14 grant skill - #11
Conversation
With git worktrees .images is often a symlink into the primary checkout's image cache, and a trailing-slash pattern matches only real directories -- so the symlink showed as untracked and was easy to commit by accident. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Phil says: 1. The agent proposes an IAM policy and waits 2. Operator examines and grants it using a script (grant.py) not writable by the VM; the script reads and displays the grant to avoid a TOCTOU switcheroo. The grant does create an actual role since AWS has limited ability to issue "one off" IAM scoping (you can do it, but it's severely length-limited.) Claude says: grant.py runs on the host from the repo root, not shared/, so the guest cannot rewrite the command between the operator reviewing it and running it, and it applies the exact policy bytes it printed and confirmed before issuing 1-hour STS credentials to shared/aws/credentials. The guest half is a skill in shared/skills reached via a ~/.claude/skills symlink that runcmd creates once. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
This is obviously dangerous and I'd like scrutiny on both the security posture as well as the human interface here. |
ddellacosta
left a comment
ddellacosta
left a comment
There was a problem hiding this comment.
I guess fundamentally the riskiest thing to me here is if I enable some permission that I didn't think through carefully. The boundaries between host/guest wrt grant.py access seem solid to me, and I appreciate that the skill includes something that describes all the proposed permissions, and that there's a test confirming the vm can't modify grant.py. In the end I think it's most likely that we ourselves may get used to rubber-stamping whatever permissions it provides us so whatever helps us guard against that is a plus I think...will keep thinking on it though.
| in the repo root, outside the shared mount: if the guest could rewrite it | ||
| between the operator's review and their run, the review would be | ||
| meaningless (a TOCTOU on the human checkpoint). The guest may only write | ||
| the *policy* file under shared/, which grant.py displays and confirms. |
There was a problem hiding this comment.
may get used to rubber-stamping
This is my fear, too, especially for "actually we need one more permission," are we really going to re-review the whole thing carefully?
I am wondering if syntax coloring for Put/Delete regexed IAM actions might help? Maybe a global "no more than X without an extra mollyguard you have to type besides "y"?
2 participants
Add a skill and a script that can be used to generate, review, and grant duration-limited STS credentials for agent use.