I haven't read through the entire thing yet, but looks conceptually similar to Zenstack (https://zenstack.dev) with the auth plugin and auto-generated APIs, so I'd be interested in a comparison with that.
Fwiw, I went down the path of trying to do something similar with Drizzle and gave up since it was in such a state of flux (this was last year). There are (were) a ton of edge cases around trying to add automatic filters to queries to the point that it was hard to justify not just rolling my own ORM.
Interesting idea. The “permissions-first” bit feels like it wants to be capability-based: you don’t get a raw model/table handle, you get a scoped handle whose type encodes (read|write|delete) + row/domain constraints.
Two pitfalls I’d watch:
1) Don’t pretend you can out-ORM the DB: ultimately enforce in the database (RLS/GRANTs/policies), and treat ORM permissions as a compile-time/ergonomic layer.
2) Make privilege boundaries explicit at function boundaries (who creates the scoped handle?) so you don’t end up with ambient auth context leaking everywhere.
If you can generate SQL that is provably policy-complete (or at least auditable), that’s a big win.
The idea behind this spec is to give users full access to their own data. For example, ORM-backed data could be consumed by an MCP server, an autonomous agent, or a vibe-coded app. The goal is to make the data layer flexible and interoperable so that any client can build on top of it.
Looking ahead, I believe the best product managers will be the end users themselves. They'll want to vibe-code their own frontends and connect them to a secure backend.
That raises a key question: how do we design a backend that's secure, safe, and robust enough to support a wide range of use cases while still being extensible enough for user-driven customization?
I haven't read through the entire thing yet, but looks conceptually similar to Zenstack (https://zenstack.dev) with the auth plugin and auto-generated APIs, so I'd be interested in a comparison with that.
Fwiw, I went down the path of trying to do something similar with Drizzle and gave up since it was in such a state of flux (this was last year). There are (were) a ton of edge cases around trying to add automatic filters to queries to the point that it was hard to justify not just rolling my own ORM.
Interesting idea. The “permissions-first” bit feels like it wants to be capability-based: you don’t get a raw model/table handle, you get a scoped handle whose type encodes (read|write|delete) + row/domain constraints.
Two pitfalls I’d watch: 1) Don’t pretend you can out-ORM the DB: ultimately enforce in the database (RLS/GRANTs/policies), and treat ORM permissions as a compile-time/ergonomic layer. 2) Make privilege boundaries explicit at function boundaries (who creates the scoped handle?) so you don’t end up with ambient auth context leaking everywhere.
If you can generate SQL that is provably policy-complete (or at least auditable), that’s a big win.
The idea behind this spec is to give users full access to their own data. For example, ORM-backed data could be consumed by an MCP server, an autonomous agent, or a vibe-coded app. The goal is to make the data layer flexible and interoperable so that any client can build on top of it. Looking ahead, I believe the best product managers will be the end users themselves. They'll want to vibe-code their own frontends and connect them to a secure backend.
That raises a key question: how do we design a backend that's secure, safe, and robust enough to support a wide range of use cases while still being extensible enough for user-driven customization?
This closely aligns with what I expect ZenStack could help in the AI era, which you could tell from the two demos I created :
-[MCP](https://zenstack.dev/blog/database-to-mcp)
-[Agent](https://zenstack.dev/blog/ai-agen)
From my experience, a declarative and flexible AuthZ layer is the cornerstone of everything.
There are a few differences between ZenStack and the proposed specs — see this comparison: https://claude-zenstack-comparison-page-8lwqi-superapp-docs....
Check out Zanzibar / SpiceDB / ReBAC and "Macaroon Auth" (disambiguating search phrase) for what modern permission systems can be