Building AMW, a permit and receipt gateway for AI agent actions. Looking for blunt feedback from agent builders.
Demo key: https://t.co/QlWKtyS3nS
What confused you? What's missing before you'd trust it on a real write?
@kartikb753@encrypt_wizard@neatlogs Replaying the exact request and response pair before a fix ships is the right bar. Random inputs never hit the timeout path. How do you capture that pair in prod without leaking payload data into fixtures? Happy to compare notes: [email protected]
@RohanBhanotAI@WalletOfAgents@nvidia Sorry for the slow reply. My lean is park, not reject: the claim waits until a person reissues, so nothing runs on a grant nobody saw. Would park still cause pain in your overnight loops? Happy to go deeper: [email protected]
@yoshibuild Steal away, that is the point of sharing it. Secrets and network are the right first two, since a silent fail there is the costly one. What does your refusal record keep today? If you want to compare notes: [email protected]
@hazemomier Agreed that a widen is rare enough to push to the owner every time. Sharing one source with the receipt trail feels right, so the alert and the audit never disagree. Would you push on every widen or only past a threshold? Notes welcome: [email protected]
@ferlogs_ Caller minted and carried with the message is the cleanest answer I've seen. A restarted worker inherits the key instead of inventing one. What happens when the caller itself retries with a new message after a crash? Happy to swap notes: [email protected]
@paulopierrondi A duplicate send being worse than a late one is the line I keep coming back to. Backoff with a hard cap, then stop and ping, matches what I see. Who gets the ping in your setup, the owner of the tool or the owner of the run? Glad to compare: [email protected]
@sudheerdotai Keeping trace ids out of the key makes sense, otherwise every retry looks like a new call. Key on what policy names, digest the rest for forensics. How do you decide which args policy names when a tool adds a field? Notes welcome: [email protected]
@shipkitsdev@philippberner@grinich Fair point. If a working key sits in env, the agent finds it, so friction alone just trains the bypass. Inventory first. How do you find the keys an agent can already reach today? Happy to swap notes: [email protected]
@gagu_sh@starbuxman Lookup first, then a write that dedupes on the key anyway, is the belt and suspenders version I like. What do you do when the second system has no lookup by key at all? Glad to compare notes: [email protected]
@bobbyhalljr_dev Agreed, one ticket. Once the reference ID and the request hash live apart, nobody can prove which call the status check settled. Who closes the ticket in your setup, the poller or a person? If you want to compare notes: [email protected]
@nullbnd Typed scope is the better cut: domain, prefix or enum survives harmless rewording and still catches a real target change. On empty then filled mid call, I lean toward treating the fill as a new ask. Would you allow fills inside the scope? Notes: [email protected]
When a capped agent tool call fails, should it give the slot back? In AMW it does only if the call never dispatched. Once the request left, a timeout or upstream error keeps the slot, since the side effect may have landed. How do you count these?
@chaliy Signing the tool request is the part I care about most too: it lets an auditor check what was asked, not just what ran. Do you sign the request before the call goes out, or the result after? Happy to compare designs: [email protected]
@WalletOfAgents@umang147@apify Thank you for testing this so carefully and posting the results. Both rough edges are noted, thank you: the conflict code and the mcp_context naming. Which would you want tested next, the daily cap or the upstream hang path? If you want to compare notes: [email protected]
@adrianhsuu@adrianhsuu Agreed, and that's the case that worries me most: right tool, wrong target. Per argument checks like an allowlist of tables or a row count ceiling close most of it. Would you gate on the argument itself, or on a dry run that shows what it would touch?
@YogiYaramchitti@YogiYaramchitti Fair push. On money movers I'd want both too: caps decide what can happen, the record proves what did. I'd still pick B if forced, since a cap without a record leaves you guessing after the fact. Which do you wire in first on a new tool, the cap or the log?
@Nick_Researcher I build in this layer, so I am biased. The gap I see most is retries: a permission check passes, the response is lost, and the retry runs the action again. I return the original receipt on a same key retry. Does your map split authorization from replay safety?
@MarcoSalzmann80@hedera Boundaries are half of it. The other half is the timeout after a payment goes out. In the gateway I built, a payment whose response was lost is flagged for a person to check instead of being resent. How do Agent Accounts report a transfer that may have settled?
@secnorainfosec Consent fatigue is why I put the check in front of the tool instead of in a chat dialog. It reads the call the agent actually sends, and a denial comes back with a reason like cap reached so the agent can stop and ask. Which bypass showed up most in your testing?