Questions
The ShellToken with prefix matching (allowed=["kubectl get pods"]) is doing a lot of heavy lifting for security. Prefix matching on shell commands is notoriously tricky - kubectl get pods; rm -rf / might match the prefix depending on implementation. The README doesn't address how argument injection is handled. This is probably the sharpest edge in the whole design.
The MultiUseShellToken somewhat undermines the elegance of linearity. Once you have "use N times," you're back to a budget/quota model rather than a truly linear one. It's pragmatically necessary (you obviously need to read logs more than once), but it's worth acknowledging the trade-off more explicitly.
Next up:
The biggest gap is composability - what happens when an agent needs capabilities it wasn't granted? Can it request additional tokens from a supervisor agent or human? Right now it just fails, which is safe but potentially limiting for more complex workflows. A protocol for "capability negotiation" would make this much more powerful.
Considerations
Also, the tight coupling to Anthropic's API is fine for a v1 but worth flagging. The token/capability layer is model-agnostic in principle - it would be nice to see that separation made explicit so the same capability sets could wrap OpenAI function calling or any other tool-use protocol.
Questions
The ShellToken with prefix matching (allowed=["kubectl get pods"]) is doing a lot of heavy lifting for security. Prefix matching on shell commands is notoriously tricky - kubectl get pods; rm -rf / might match the prefix depending on implementation. The README doesn't address how argument injection is handled. This is probably the sharpest edge in the whole design.
The MultiUseShellToken somewhat undermines the elegance of linearity. Once you have "use N times," you're back to a budget/quota model rather than a truly linear one. It's pragmatically necessary (you obviously need to read logs more than once), but it's worth acknowledging the trade-off more explicitly.
Next up:
The biggest gap is composability - what happens when an agent needs capabilities it wasn't granted? Can it request additional tokens from a supervisor agent or human? Right now it just fails, which is safe but potentially limiting for more complex workflows. A protocol for "capability negotiation" would make this much more powerful.
Considerations
Also, the tight coupling to Anthropic's API is fine for a v1 but worth flagging. The token/capability layer is model-agnostic in principle - it would be nice to see that separation made explicit so the same capability sets could wrap OpenAI function calling or any other tool-use protocol.