I have previous experience at Stripe in IAM, have been working on this for a while. If you have any questions or suggestions let me know here, on Github or wherever else you find me.
On a more theoretical level, I’m interested in the idea of building customized access subsets through a templated schema on individual APIs. The mechanisms are a little different, git is local with a remote mirror handled by the daemon, Stripe is more simple with more-or-less static requests, and the Vercel CLI opens a connection where it runs through a series of requests within a window with a pre-defined grant. But underneath the technical aspects remains the same idea of customizing access with an almost arbitrary precision.
There’s a quote from the West Wing about money in politics that I’ll paraphrase here. “Money in politics is like water on pavement, it will find every crack.” I believe this to be increasingly true for authorization surfaces in the age of agentic AI. Pre-defined roles and keys will have extraneous permissions for any one task you might trust an agent with. You couple these excess permissions across a number of providers and the combinatorial growth in possible actions start getting more and more dangerous. Cermet is an attempt to get ahead of that.
haha i just downloaded pi after browsing HN for a bit. i'm really trying to get off the anthropic train before the subsidies explode and we're left holding onto codebases we don't understand and can't afford.
What models do you use for the diff level edits? My concerns would be speed, though I'm coming from letting opus ruminate for minutes at a time so my heuristics may be off.
I use a $200/mo OpenAI Codex sub. Throughout the workday I run an average of 2 concurrent agents of GPT 5.5 with high reasoning on fast mode and use less than half of my subscription usage.
For more interactive/active usage you might be better off using the low reasoning level, but I have usually found high to be a good balance of intelligence and generation speed.
I'm working on a credential broker that would keep credentials vaulted and parcel out access on a per-grant basis. Is that something you'd find useful or is your setup comprehensive enough? We would be allowing people to draft access policies with natural language, I figured it would be useful for things like vercel, stripe access etc.
Not at all would i ever within the current technology constraints trust a "natural language model" to secure access to my own credentials, i will always keep it as completely isolated from anything at all i would consider 'risky' and pre-define before it begins what it could possibly access through a brand new VM with only the absolute minimal access to any git repo's and completely restrict to the extent that is allowable, it's ability to do anything outside of it's own playground. The playground is disposable, the potential for the LLM to access any of my own accounts and wreak havoc on the trust in my network is unacceptable under any rules....
fwiw, i built something simple like this into my harness thing (github.com/0gsd/enough). may not be complicated enough to do per application nowadays vs. needing a modularized outside solution, but it is certainly a good idea that seems to work!
On a more theoretical level, I’m interested in the idea of building customized access subsets through a templated schema on individual APIs. The mechanisms are a little different, git is local with a remote mirror handled by the daemon, Stripe is more simple with more-or-less static requests, and the Vercel CLI opens a connection where it runs through a series of requests within a window with a pre-defined grant. But underneath the technical aspects remains the same idea of customizing access with an almost arbitrary precision.
There’s a quote from the West Wing about money in politics that I’ll paraphrase here. “Money in politics is like water on pavement, it will find every crack.” I believe this to be increasingly true for authorization surfaces in the age of agentic AI. Pre-defined roles and keys will have extraneous permissions for any one task you might trust an agent with. You couple these excess permissions across a number of providers and the combinatorial growth in possible actions start getting more and more dangerous. Cermet is an attempt to get ahead of that.