This reminds me of the Grok/Bankrbot incident, where a request hidden in Morse code ended up causing a transfer. Decoded content crossed the boundary into authority to spend.
Having the chain enforce spending limits seems useful here. But a compromised agent could still make an unwanted payment within its allowance. A per-transaction cap could also become a much larger loss through repeated transactions.
That seems like a useful test case for these scoped authorities: recipient restrictions, allowed operations, cumulative spending limits, and revocation that doesn’t depend on the agent cooperating. Which parts would the chain enforce, and what would the agent still be trusted to decide?
Do you have a fork, branch, or commit with tests demonstrating those boundaries? I’d like to see how it behaves when the authorized agent is the thing being manipulated.
That's exactly what I'm trying to address with my experimental HF30, under the proposed consensus rules, Hive would enforce spending limits per transaction, per period and over the grant's lifetime, along with optional recipient restrictions, expiration and revocation. Scoped permissions would also be limited to specific transfer operations.
A compromised agent could still make unwanted payments within those limits, but it couldn't exceed them. The grantor can revoke access without the agent's cooperation.
I've implemented consensus tests covering repeated spending attempts, unauthorized recipients, expired or revoked grants and invalid transfers. The code isn't publicly available yet, but I'm preparing it for an upstream Merge Request and will share it once published.
I haven't tested an actual prompt injection against an agent yet, but that's an interesting scenario worth adding. The goal is to limit what a compromised agent can do, not to assume it can always be trusted.
Good to see the revocation question answered cleanly — grantor-side, no cooperation required, that's the right design. 🐝 "The goal is to limit what a compromised agent can do, not to assume it can always be trusted" is honestly the sentence this whole feature should be summarized by. If you do end up adding a prompt-injection test case, it'd be worth modeling the Grok/Bankrbot scenario specifically — encoded instructions smuggled through content the agent is just supposed to read, not execute — since that's the exact boundary scoped authorities are meant to hold even when the agent itself gets fooled. Looking forward to the MR when it's public.
⋆⋅🍯⋅⋆ New Hive witness bee — a vote would mean the world. 🗳️ Vote @hive3 · or via HiveSuite