Summary

The ACP tool needs to also be an API that can be invoked by the app on itself at runtime, when deployed to user's computers. For example there could be a manifest attribute or tag that puts the sandbox into non-enforcing mode, in which any attempt to use a capability which isn't already listed in the manifest causes a log event that is retrievable by the app.

Pitch

Sandboxing an app is risky. There might be an obscure feature or scenario you don't test which nonetheless users depend on. If you work out your capability list by doing some local tests, deploy the sandbox and then break your users they will be mad and you'll probably give up. After all, this type of opt-in app isolation is purely voluntary and "good citizen" behavior, not something that actually benefits the app developer directly.

This outcome can be avoided by allowing a long "soak period" in which the permissions list is shipping to end user deployments, and the sandbox is running, but missing capabilities don't cause access denied errors. Instead they are recorded in a place where the app can easily retrieve them, for instance to post as part of telemetry back to its home servers. If the developer has missed something they will then notice when they get reports of sandbox false positives and can investigate.