niyikiza

We built an open source governance tool called Tenuo that allows you to define exactly what an agent can do for a given tasks. Works for local filesystem, network, mcp servers, etc.

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

https://github.com/tenuo-ai/claude-governance

I guess they should include tuition cost as well.

We've been using Tenuo which for task-scoped authorization.

Its integration for Claude Code: https://github.com/tenuo-ai/claude-governance

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

Means you can basically host your own AS

there are some emerging mechanisms for offline verification that don't require AS in the OAuth WG. (I'm working on one of them)

What would the benefit be? A mega agent that does everything?

There are some well documented advantages of decomposition...that's why the industry favours microservices over monoloths.

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.

Full draft's here if you want to pick it apart: https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenu...

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

Some clever workarounds wrt process management & POSIX compatibility

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.

My understanding is that when it's something that requires user action they'd directly send comms to customers.

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.

[1] https://niyikiza.com/posts/capability-delegation/

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

I SAY AYE.

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.

>harnesses should have more assertive layers of control and constraint

Been saying this for a while and mostly getting blank stares. In-context "controls" as the primary safety mechanism is going to be a bitter lesson for our industry. What you want is a deterministic check outside the model's reasoning that decides allow/deny without consulting its opinion. Cryptographic if the record needs to survive a compromised orchestrator, and open source. If your control is a string the model can read, the model can ignore it. If it can write it, it can forge it. I'm surprised how strange that idea sounds to some people.

Disclosure: I'm working on an open source authorization tool for agents.

Reminds me of the riddle[1][2] from Game of Thrones / A Clash of Kings:

Lord Varys: Three great men sit in a room: a king, a priest, and a rich man. Between them stands a common sellsword. Each great man bids the sellsword kill the other two. Who lives, who dies? Tyrion Lannister: Depends on the sellsword. Lord Varys: Does it? He has neither crown, nor gold, nor favor with the gods. Tyrion Lannister: He has a sword, the power of life and death. Lord Varys: But if it's swordsmen who rule, why do we pretend kings hold all the power? When Ned Stark lost his head, who was truly responsible? Joffrey? The executioner? Or something else? Tyrion Lannister: I've decided I don't like riddles. [pause] Lord Varys: Power resides where men believe it resides. It's a trick. A shadow on the wall. And a very small man can cast a very large shadow.

[1] https://www.imdb.com/title/tt2070135/characters/nm0384152/ [2] https://www.goodreads.com/quotes/503606-oh-i-think-not-varys...

Speaking of fantansies...another approach would be holder binding: DPoP (RFC 9449) has been stable for a couple of years, AWS SigV4 does it too. The key holder proves control at call time, so a captured token without the key is useless.

I took that course too and ruined my life...by making me think writing a compiler could be fun. The course itself was worth the money I paid for the program.

Was just at [Un]prompted conference where this was a live debate. The conversation is shifting but not fast enough. I've been screaming about this for a while: we can't win the prompt war, we need to move the enforcement out of the untrusted input channel and into the execution layer to truly achieve deterministic guarantees.

There are emerging proposals that get this right, and some of us are taking it further. An IETF draft[0] proposes cryptographically enforced argument constraints at the tool boundary, with delegation chains that can only narrow scope at every hop. The token makes out-of-scope actions structurally impossible.

Disclosure: I wrote the 00 draft

[0] https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenu...

We've been working on that with tenuo: https://github.com/tenuo-ai/tenuo

Task-scoped "warrants", attenuating with delegation, and enforced cryptographically at tool call.

Macaroons/Biscuits for agents basically.

Cool project! I went to a Korean university more than 190 years ago and can only speak basic Korean but going through your examples seem to be improving my Korean vocabulary!

We've been working on a warrant model that ensures task-scoped authorization: constrain your agents to specific tools and specific arguments, cryptographically enforced at the MCP tool boundary. Even a fully compromised agent can't reach outside its warrant. Open source. github.com/tenuo-ai/tenuo

The boundary also needs to hold if the agent is compromised. Proxying keys is the right instinct. We took the same approach at the action layer: cryptographic warrants scoped to the task, delegation-aware, verified at the MCP tool boundary before execution. Open source core. https://github.com/tenuo-ai/tenuo

The two-layer framing is right. Sandbox-exec contains local blast radius, and that's important. But if the agent already has a credential in memory, sandboxing the filesystem doesn't help. I've been working on a primitive for scoped authorization at the tool call level: what was this agent allowed to do, for which task, signed by whom. The core is open-sourced: https://github.com/tenuo-ai/tenuo