Question about cross-organization admin operations via application credentials

Hi, I'm evaluating Casdoor for a multi-organization setup and ran into some behavior I'd like to understand better. Not sure if this is by design or if I'm misconfiguring something.

Setup
Self-hosted Casdoor, version: v2.357.0
Created a new organization org-A (not built-in)
Created an application app-A under org-A
Got client_id / client_secret for app-A

Observed behavior
Using app-A's credentials with HTTP Basic Auth, I can perform cross-organization admin operations:
bash

Delete a different organization (org-B), using app-A's credentials

curl --location 'https://my-casdoor/api/delete-organization' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic some_base64_value' \
--data ' {
            "owner": "admin",
            "name": "test",
            "createdTime": "2026-04-27T12:05:25+08:00",
            "displayName": "test",
            "websiteUrl": "https://door.casdoor.com",
            ...
        }'

→ succeeds, org-B is deleted

I also noticed:
After deleting org-A itself using app-A's credentials, those same credentials still work and can continue operating on other organizations.
The same operation via Bearer token (obtained through client_credentials grant) is rejected with Unauthorized operation. Only Basic Auth allows it.

What I expected
Based on the docs ("client credentials give that org's admin-level access"), I assumed app-A's credentials would only have admin access scoped to org-A, not to other organizations.
My questions
Is this the intended behavior? i.e. are application credentials in Casdoor effectively global-admin-equivalent when used via Basic Auth, regardless of which organization owns the application?
If yes, is there a recommended way to scope an application's API access to its own organization only?

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.

@wovk5721 fixed in: https://github.com/casdoor/casdoor/commit/b9b3cfff7f2fb2d45c2b1a6727359eb5ada7dfbe

@wovk5721 fixed in: https://github.com/casdoor/casdoor/commit/27a3e73c7215f37a7c41a26e3f46cbb2ac33801a