A daemon that syncs lock schedules needs application Mail.Send with no signed-in user. What must the security engineer understand when adding that permission on the app registration?

Application permissions allow an app to call an API as itself without a signed-in user and require administrator consent. Clients request those static application permissions using the /.default scope rather than an interactive per-user consent prompt. For a daemon that syncs lock schedules and needs application Mail.Send with no signed-in user, the security engineer must understand both the admin-consent requirement and the /.default permission model when adding that permission on the app registration.

Claiming any clerk can grant application Mail.Send through the standard user consent prompt at first launch fails by concept: application permissions are not granted through ordinary user consent the way many delegated scopes can be. Claiming delegated Mail.Send is enough for a daemon because background jobs always inherit the last interactive user fails operationally and architecturally—daemons must not depend on ambient interactive sessions. Claiming application permissions are approved automatically when the redirect URI uses HTTP on localhost fails: redirect URI settings do not auto-approve admin-consent application permissions such as Mail.Send.

Exam caveat: daemon plus application permission plus admin consent plus /.default is a classic identity pattern; still ask whether a narrower mail architecture is possible for municipal automation. Operational check: add Mail.Send as an application permission, have a privileged admin grant consent, acquire a token with /.default for the app, send a test message from the daemon, and confirm a standard clerk cannot approve that application permission alone.