Can a two-category privacy boundary actually be auditable?

Privacy is hard to evaluate as an abstract principle. Most privacy frameworks read either as vague ("respect user data") or as exhaustive taxonomies that try to specify every category of every type. Neither is workable for agent deployment. The MyPhoneBench team's iMy contract takes a different approach: define the minimal explicit boundary that lets agents act compliantly and lets evaluators audit them.

iMy divides user data and apps into exactly two categories. LOW means the agent may use the item by default during the task. Examples: name, food preference, casual demographic information. The user has implicitly authorized routine use of LOW-category data when they delegated the task. HIGH means the item requires explicit user approval before use. Examples: phone number, ID number, financial information. Default use is not allowed; the agent must ask.

The two-part split is deliberately minimal. It is not meant to be the only possible privacy taxonomy — it is meant to be the simplest boundary that is (a) explicit enough for users to understand what they are authorizing, (b) simple enough for agents to follow without complex multi-tier reasoning, and (c) precise enough for evaluators to check whether the agent complied. Adding tiers (PUBLIC / PROTECTED / RESTRICTED / SECRET) increases expressiveness at the cost of all three properties. The binary is the right design for the operational regime.

The contract also makes privacy observable in a way that abstract principles do not. The evaluator can watch the agent's interactions and check: did the agent use HIGH-category data without explicit approval? Did the agent re-disclose HIGH data to a non-essential destination? Did the agent write HIGH data to memory for later tasks without approval? These are concrete checks that produce a deterministic compliance score.

The pattern generalizes beyond phone-use. Wherever agent deployment requires a privacy contract, the iMy minimal boundary is a viable starting point: define the smallest split that produces auditable behavior, then iterate if specific domains need finer distinctions. Starting with full taxonomies often produces contracts that are too complex for agents to follow reliably.