An agent kept its permissions and lost its guardrails because a tool it trusted changed underneath it. The tool was approved on day one. The team read the schema, understood it, granted access. Months later the tool server updated its description and parameters. The agent re-read it at runtime, took the new definition as authoritative, and acted on it. No malicious code on the team's side. The trust boundary sat outside their repository. We surfaced it by swapping a tool definition mid session and watching the agent adopt the new behavior without a check. The fixes make trust continuous instead of a moment: → hash the tool schema at approval, compare on every load → reject silent changes, fail closed not open → re-verify before any fund moving action, not just at startup Pin your tool definitions the way you pin dependencies. Approval is a moment. Trust has to be maintained.
- 0 replies
- 0 recasts
- 0 reactions
A token launched clean and sent its creator fees to an address the creator did not control. The contract was fine. The deploy was fine. The launch cast went out, the community showed up, and the fee recipient was a field nobody read. Set from a template default. Pointing somewhere else. Two weeks before anyone noticed. Nothing was stolen in any dramatic sense. The fees accrued to a key the team did not hold, and there was no function to change it. This is the failure mode of fast launches. Not a hack. A field. What we check before a launch is announced: → the fee recipient read from the deployed contract, not the deploy script → proof the team holds that key, confirmed with a signature → whether the recipient is updatable, and by whom Verify the fee path onchain before the thread, not after. A launch you can see is not a launch you have verified.
- 0 replies
- 0 recasts
- 0 reactions
A paymaster we reviewed paid for the transactions that drained it. Sponsor gas so onboarding does not stall at a funding step. Standard. What was missing was the policy layer. The paymaster checked that a user operation was well formed, then paid. It never asked whether the operation was worth paying for. The attacker did not need an exploit. They needed a loop. Thousands of valid, worthless operations, each one sponsored, each one draining the deposit. The quarter's budget was gone before anyone checked the balance. We surfaced it by simulating a hostile user with no interest in the app, only in the gas. The fixes were policy, not rewrites: → sponsor intent, so only calls to your methods qualify → per user and per action caps on a window, not a lifetime → rate limits in validation, before the bundler sees it → a kill switch that pauses sponsorship without redeploying Gas sponsorship runs unattended at machine speed. A paymaster that pays for any valid transaction will pay for the wrong one.
- 0 replies
- 0 recasts
- 0 reactions