I'm working on a Claude Code governance tool that allows to define deterministic policies for tool call that can be enforced across a fleet and will be in effect even when individual users run with --dangerously-skip-permissions
Because procurement is hard. Changing vendors is a big undertaking for big companies. They are certainly not going to be switching vendors every time there is an incident
I agree with the coarse permissions point, and I wouldn't bank on those services adding finer-grained scopes.
The idea in my draft is to do the attenuation and verification before the call reaches the service, enforced at the boundary, like the proxy setup you're describing. And the token wouldn't be a bearer token per se; there's proof of possession, and the constraints narrow at each hop and travel with the token, so the boundary can verify the chain itself rather than rely on a central authority. The design is inspired by macaroons and other capability-based access control work.
There's some active discussions on task level authz and multi-hop delegation in the OAuth WG right now. WorkOS wrote a good overview of the open drafts [1]. (Disclosure: one of them is mine.)
[1] https://workos.com/blog/oauth-multi-hop-delegation-ai-agents
Agree with the meta point. I worked in Korea and Japan and loved the culture but when I moved to the west I was surprised to see how people over here fantasize about their (imo inefficient) corporate cultures.
This particular article was decently nuanced though.
Probably the best option after sending a mass email when customers need to take action.
The status page is for reliability issues impacting end users & the blog is for in-depth analysis.
Building tenuo.ai (https://github.com/tenuo-ai/tenuo): task-scoped authorization for AI agents. Rust implementation of capabilities + cryptographic offline verification.
My analogy[1] has been that we need a valet key: capped speed, geofenced, short ttl, can't open trunk/glovebox, etc. That way we don't have to say pretty please to the valet and hope that they won't get ideas.
I have to agree here...of all things that went wrong here, I don't think the API surface is to blame. You need to have deterministic control & escalation mechanism on your agents whether they are calling an API or any other tool
Yeah, people calibrate trust to the median behaviour of the model and get burned by the tail.
What makes it harder is that even people who do see the holes often respond with better prompts and more elaborate context. Same trust-the-model move one level up. Hyperscalers aren't incentivized to fight that instinct either. Every "fix" routes more tokens through their meter.
Two things get called "hooks" here. Exit code 2 + stderr is a real control. JSON in stdout degrades to a string in the model's tool-result context, where the model is correctly trained to resist instructions because that's where prompt injections show up. OP hit the second one. It's popular because the ergonomics are friendlier, but for any serious control you want to use deterministic execution guards outside of the agent's reasoning layer.
Disclosure: I'm working on an open source authorization tool for agents.
Building Tenuo (github.com/tenuo-ai/tenuo)
dev at tenuo.ai