KnowledgeAnswersSensitivityInstruction

This field is for backward compatibility.

Controls whether a top-level intent is multi-account approved. NLU will do go/cross-account-understanding only for intents with this bit on. Also, this bit should be propagated to user turn Attentionl Entities to extend protection of cross-account data to next turns. In principle fulfillment services (e.g., Monastery) should only dispatch such intents to multi-account approved fulfillers (schemas), at least when the user has a linked dasher account. The Assistant runtime policy engine should treat a query as dasher data if 1) this bit is true in the string redaction, and 2) the user has a linked dasher account, and apply a more restrictive rule for whitelisting, regardless of the actual account provenance in Sensitivity. Example: [User logged in to their personal gmail account.] Q1: "Schedule a meeting tiltled okr review at 3pm". Assistant: "Should I scheduled it on your xyz@gmail.com account?" Q2: "No, add it to my xyz@bigcorp.com account." We don't know Q1 is dasher data until Q2. To prevent leaking of Q1 to non-dasher approved binaries, this bit should be used as a proactive measure. It might introduce some over-triggering (e.g., user says "Yes" in Q2), but is much better than blindly treating every query as dasher, not considering whether it actually triggers any multi-account capable intents or not (see b/164420114 for example).