Feature Request: Positive Service Role Identity Signal for Secure Backend-to-Backend Invocation We are building a financial marketplace with payout processing and enforcement logic. We need secure backend-to-backend orchestration between functions. Currently: base44.asServiceRole.functions.invoke() is supported. However, there is no positive signal inside the callee to confirm that the request originated from service-role invocation. auth.me() returning null is ambiguous (could be service role OR unauthenticated public request). Custom headers cannot be attached via functions.invoke(). This creates a security gap for sensitive functions (payouts, enforcement, audit logic). Current Workaround We must use a shared secret stored in environment variables and pass it in the request body. While viable, this is not ideal because: It relies on manual secret management. It increases implementation complexity. It is less clean than platform-native identity propagation. It can be misused if developers follow unsafe auth.me() === null patterns. Requested Improvements We request one of the following secure patterns: A guaranteed positive runtime signal such as: req.isServiceRole === true base44.auth.isServiceRole() or a trusted internal header injected by the platform. Ability to attach custom headers when using functions.invoke(). Automatic identity propagation so that service-role invocations resolve as a privileged internal identity distinguishable from unauthenticated requests. Why This Matters For financial systems, payouts, audit enforcement, and reliability scoring require strict authorization boundaries. The inability to positively identify internal service calls forces developers into workarounds that increase risk. This capability would significantly improve Base44’s suitability for high-security backend orchestration and financial applications.