wovk5721

Follow-up: API enforcer policies appear to be hardcoded at startup

Following up on my earlier question about cross-organization admin operations via application credentials.
I did some more digging and found what seems to be the underlying mechanism. Sharing here in case it helps clarify, and I have a question at the end.
What I found
Casdoor's admin API authorization is enforced by the built-in api-enforcer (Casbin). I confirmed this by checking the runtime logs:

[I] (172.21.0.1) subOwner = app, subName = test_app, method = GET,
urlPath = /api/get-organizations, obj.Owner = , obj.Name = , result = allow

Looking at the api-enforcer's policy table, there are two wildcard policies:
p, built-in, *, *, *, *, *
p, app, *, *, *, *, *
These match any subject of type built-in or app against any method, URL path, and object — which explains why any application's credentials (via Basic Auth) can perform cross-organization admin operations: the wildcard policy permits everything.
The part I'd like to confirm
I tried modifying the casbin_rule table directly to scope these policies (e.g., restricting app subjects to their own organization). However, the modifications are reverted on every restart.
Looking at authz/authz.go, it appears the initial policies are seeded in code at startup and overwrite any customization in the database.

My questions

Is my understanding correct — that the default api-enforcer policies are hardcoded and not intended to be user-customizable through the database?
Is there an officially supported way to restrict these policies (e.g., to enforce per-organization scoping for application credentials) without forking and modifying the source code?
If not currently supported, is this something the team would consider as a feature — exposing the api-enforcer policies as configurable, so operators can apply least-privilege scoping?

Context for why this matters to us: we're evaluating Casdoor for a multi-organization deployment where external customers would be onboarded as applications. Under the current behavior, any leaked client_secret would grant instance-wide admin access regardless of which organization the application belongs to, which is a blocker for our use case.