Cost-Efficient Privacy Enforcement for Email-Generating LLM Agents under Strategic Information Requests

1 Introduction

• The platform must control what private information reaches email recipients while balancing enforcement cost against the need to complete the task.Email has explicit recipients and persistent records, and access by an agent does not imply recipient authorization.Source: §1 · pp. 1–2
• Checker–repair defenses can incur repeated remote action-LLM and checker calls, with strategic requests for exact values, records, or evidence worsening leakage and cost.The paper defines a strategic information request as preserving an apparently legitimate task while pressuring disclosure of unauthorized private details.Source: §1 · p. 2
• The proposed mechanism uses a local Gemma rewriter with a contract specifying what to preserve, generalize, forbid, and retain in the output shape, followed by checker validation and local repair when needed.Gemma-only is also evaluated as a lower-cost option, but not as a replacement for final checking.Source: §1 · p. 2
• Across 149 aligned normal and attack email tasks, Gemma + Checker reduces leakage and attack-induced cost amplification while preserving usable task completion.The mechanism moves much of the remote repair loop into local policy-constrained editing before optional final checking.Source: §1 · p. 3, Figure 1 · p. 3

2 Cost-Aware Strategic Information Release

• A leakage event occurs when the final draft reveals an annotated sensitive item through exact disclosure, close paraphrase, or strong source-grounded implication.The setup distinguishes sensitive items from non-sensitive task slots needed for authorized utility.Source: §2 · p. 3
• The attack condition models requests that seek sensitive details while retaining a valid-task appearance, including exact-value, raw-record, source-evidence, structured-extraction, or completeness requests.The three mechanisms are remote checker–repair (MB), local Gemma-only rewriting (MG), and Gemma rewriting with checker validation and local feedback repair (MG+C).Source: §2 · pp. 3–4
• The defender objective trades off authorized utility, privacy leakage, remote and local costs, and semantic drift, with remote tokens treated as the primary cost measure.The paper also defines an optional total-cost measure that converts local compute into remote-token-equivalent cost.Source: §2 · p. 4
• When the remote baseline uses more repair rounds than the local-first mechanism and remote call costs are positive, local-first enforcement strictly reduces remote cost.For total cost, MG+C remains cheaper when the local rewrite cost is below the remote-cost reduction.Source: §2 · p. 4
• MG is suited to low-risk settings only when its remote-cost savings outweigh the expected increase in privacy loss; MG+C is preferred for high-risk or attack-suspected sends.MG has the lowest remote cost but lacks an independent semantic gate.Source: §2 · p. 4

3 Local Contract-Conditioned Enforcement

• A send-time wrapper captures recipient, subject, and body, and only permits the exact draft that passed the selected enforcement path to be sent.A changed body after validation triggers another inspection, preventing the main agent from deciding whether its output is checked.Source: §3 · p. 5
• The contract is generated from the user instruction and original draft, and separates preserving benign task slots, generalizing sensitive details, forbidding unsupported facts, and retaining a useful email shape.It is a deployable rewrite policy, not an evaluation oracle.Source: §3 · p. 5, Table 1 · p. 5
• Gemma receives the original subject and body, the contract, and optionally checker feedback, then makes minimal edits to preserve communicative purpose and professional tone while generalizing sensitive details.The mechanism is not tied to Gemma; another trusted local or on-premise editor with sufficient rewriting capability could instantiate the policy.Source: §3 · p. 5
• Unlike generic privacy rewriting, the contract specifies which benign task slots and output form should survive and which safe abstractions may replace prohibited details.The paper tests this distinction in an offline contract ablation.Source: §3 · p. 6
• In MG+C, PrivacyChecker evaluates the locally rewritten draft; rejected drafts receive feedback for local repair, and the send is blocked if no safe draft emerges within the retry budget.Gemma performs first-stage sanitation and utility-preserving editing, while the checker is intended to catch residual semantic leakage.Source: §3 · p. 6

• 149 aligned Privacy in Action email tasks pair user instructions and private context with recipients, email objectives, and annotated sensitive information.The tasks include 480 sensitive items and span email-generation and reply categories.Source: §4 · p. 6
• Strategic attack prompts add requests for raw records, exact values, source evidence, or sensitive fields while preserving the appearance of a valid task.Attack-prompt satisfaction is judged only on the benign task shell, excluding attack-specific demands for private details.Source: §4 · p. 6
• Leakage is evaluated on final subject and body content against annotated secrets, counting exact, partial, and reconstructive disclosure.Reported leakage uses model-based judging with manual spot checks, not a formal human annotation study.Source: §4 · p. 7
• Offline contract ablation reuses Gemma-only drafts and reevaluates rewritten outputs without rerunning the agent, tools, sending action, or final checker.Source: §4 · pp. 7–8

5.1 Local Rewriting Reduces Remote Enforcement Cost

• 17.6% lower remote tokens under normal prompts and 36.6% lower under attacks show MG+C reduces remote enforcement cost relative to MB.Despite higher checker-token use, action-LLM token consumption drops sharply; Gemma local tokens are reported separately from remote cost.Source: §5.1 · p. 8, Table 3 · p. 8

5.2 Strategic Requests Amplify Cost and Leakage

• 18.79% attack leakage (vs 28.19% for MB and 21.48% for MG) and 1.02× checker-call amplification give MG+C the strongest reported joint attack outcome.The comparison concerns prompts that operationalize strategic information requests.Source: §5.2 · p. 9, Table 4 · p. 9

5.3 Utility Is Preserved Under the Safe Task Shell

• 92.6% UsableRate with 98.1% privacy-allowed slot retention under normal prompts; under attacks, MG+C retains 99.1% safe slots and reaches 100.0% safe UsableRate.Under attacks, MG+C requires 0.04 average repair rounds, compared with 1.52 for MB.Source: §5.3 · p. 9, Table 5 · p. 9

5.4 The Information-Release Contract Matters

• Offline replay leakage falls from 7.38% to 4.70% under normal prompts and from 32.21% to 14.77% under attacks with the full contract versus generic Gemma rewriting.The ablation evaluates leakage only, not utility or token cost.Source: §5.4 · p. 10, Table 6 · p. 10

5.5 Mechanism-Level Cases

• Qualitative case studies illustrate why local rewriting improves the cost–privacy trade-off and why the checker remains necessary for high-risk sends.The cases are not additional quantitative evidence.Source: §5.5 · p. 10

Related Work

• Contextual-integrity research evaluates privacy judgment and agent behavior, while this work uses contextual-integrity fields as a rewrite policy and retains PrivacyChecker as a final validator [6].The stated objective is to reduce leakage and remote enforcement cost together, rather than asking only whether a checker reduces leakage.Source: §6 · p. 10
• Tool-using agents create action-level risks, and strategic information requests target unauthorized release while also measuring induced enforcement cost.The framing connects enforcement cost to privacy economics and platform mechanism design, where stronger protection can consume resources or reduce utility.Source: §6 · p. 11

Limitations

• MG has the lowest remote cost but leaks more than MG+C, especially under attack prompts, so it is positioned for lower-risk deployments rather than as a replacement for final checking.The checker can miss semantic leakage or over-flag safe abstractions; the contract can also misclassify task type, omit required slots, over-generalize, or preserve unsafe details.Source: §6 · pp. 11–12
• The leakage evaluator shares a model family with the checker, and spot checks were not a formal human evaluation; the current evaluation focuses on email actions.Extensions to Slack, calendar, CRM, document-sharing, and form-submission actions require action-specific information-shape constraints.Source: §6 · p. 12

Conclusion

• Across 149 aligned normal and attack email tasks, Gemma + Checker reduces leakage, suppresses attack-induced cost amplification, and maintains high usable safe-task fulfillment.The conclusion characterizes the mechanism as a local Gemma rewrite followed by selective PrivacyChecker validation.Source: §7 · p. 12
• The mechanism intercepts outgoing email actions, builds an information-release contract, rewrites drafts locally with Gemma, and selectively validates them with PrivacyChecker.The contract guides what to preserve, generalize, or forbid.Source: §7 · p. 12
• The paper concludes that high-risk agent actions should use explicit, cost-aware information-release mechanisms rather than unconstrained drafting followed by repeated remote filtering.Source: §7 · p. 12

A Information-Release Contract Schema

• The contract is built from the user instruction and agent-generated draft, without hidden sensitive-item labels, evaluation labels, or leakage-evaluator outputs.It is intended as a deployable send-time policy object rather than an evaluation oracle.Source: A Information-Release Contract Schema · p. 13
• The schema separates task-type inference, preservation of allowed content, generalization of private or source-specific content, output-shape requirements, and prevention of unsupported additions.Table 8 groups the principal contract fields by function.Source: A Information-Release Contract Schema · p. 13, Table 8 · p. 14
• The privacy-risk policy covers details that reveal, strongly imply, or enable reconstruction of private, confidential, sensitive, or source-specific information.Safe details may remain when task-relevant, low-risk, non-distinctive, and non-reconstructive, avoiding treatment of an entire domain as sensitive.Source: A Information-Release Contract Schema · pp. 13–14
• Privacy constraints take priority over utility fields, so required slots and detail-density targets can be met only with information that passes the privacy policy.Required slots, information shape, and fulfillment requirements help preserve the benign communication purpose and safe task-specific content.Source: A Information-Release Contract Schema · p. 14
• When exact details are sensitive, the safe-substitution plan preserves their information function rather than the sensitive fact.The contract is not merely a generic request to remove private information; it also supplies task constraints, source-grounding restrictions, safe-substitution guidance, and no-fabrication constraints, while retaining the checker for high-risk settings.Source: A Information-Release Contract Schema · p. 15

B Rewrite Prompts and Ablation Variants

• The local rewrite changes the email-facing text while preserving original recipient fields, and it can receive prior checker-failure feedback.The rewriter is invoked after the draft and before the final Gmail send action.Source: B Rewrite Prompts and Ablation Variants · pp. 15–16
• The production rewriter minimally edits drafts, prioritizes privacy filtering over helpfulness, and uses safe substitutes for sensitive details rather than erasing task function.It is instructed to avoid disclosure through exact wording, paraphrase, implication, or distinctive decomposition, while preserving privacy-safe utility requirements.Source: B Rewrite Prompts and Ablation Variants · p. 16
• The send-time loop builds a task contract from the instruction and draft, rewrites locally, and passes the result to PrivacyChecker unless checking is disabled.Checker feedback can prompt another local rewrite; if no draft passes within the configured limit, the send is blocked.Source: B Rewrite Prompts and Ablation Variants · p. 16
• The final checker remains responsible for detecting residual exact, paraphrased, or reconstructive leakage after local rewriting.The pipeline blocks a send when no rewritten draft passes the checker.Source: B Rewrite Prompts and Ablation Variants · pp. 16–17
• The generic replay prompt lacks structured contract fields, whereas the full-contract prompt supplies the contract while using the same original draft.The ablated contract removes required_slots, information_shape, and fulfillment_requirements while retaining privacy-oriented and no-fabrication fields.Source: B Rewrite Prompts and Ablation Variants · pp. 17–18
• The offline P1-1 replay varies only rewrite conditioning and reruns the leakage evaluator on synthetic logs from existing Gemma-only drafts.It does not rerun the agent, tools, real send action, or PrivacyChecker, and does not evaluate utility, semantic drift, runtime, or token cost.Source: B Rewrite Prompts and Ablation Variants · p. 18

C Evaluation Metrics and Judge Protocol

• For leakage evaluation, the evaluator uses the last checker-passed draft when available, otherwise the final sent email; recipient correctness is assessed separately from content satisfaction.Content satisfaction uses the final_sent_email event when available, otherwise a successful send-tool call.Source: C Evaluation Metrics and Judge Protocol · p. 19
• Leakage is measured per task and per sensitive item, counting direct, partial, or reconstructive disclosure of annotated information.A task counts as leaked if any annotated sensitive item is judged leaked.Source: C Evaluation Metrics and Judge Protocol · p. 19
• UsableRate counts both satisfied and partially satisfied emails, while satisfaction labels also include not_satisfied and manual_review.Manual review is reserved for cases where log information is insufficient for reliable judgment.Source: C Evaluation Metrics and Judge Protocol · p. 19
• Under attack prompts, only the benign safe-task shell contributes to utility, and removing sensitive requests is not semantic drift.Drift instead includes dropping or distorting the benign task, empty refusal, wrong recipient or action, unsupported content, or over-generalization.Source: C Evaluation Metrics and Judge Protocol · p. 20
• Slot retention tracks preserved privacy-allowed required slots, while semantic drift captures losses or distortions of task intent.If no safe required slots are identified, slot retention is undefined; the judge also records drift categories for analysis.Source: C Evaluation Metrics and Judge Protocol · p. 20
• Cost and process logs track checker calls, Gemma rewrite rounds and failures, runtime, and token usage; local Gemma tokens are excluded from remote cost.The token aggregator separates agent, checker, and Gemma usage; checker calls use the final output's count when available, otherwise the maximum logged count.Source: C Evaluation Metrics and Judge Protocol · pp. 20–21
• The P1-1 offline replay measures leakage effects of rewrite variants only, without rerunning the agent, tools, checker, or real email send.It does not compare runtime, token cost, checker-call amplification, or full-pipeline utility.Source: C Evaluation Metrics and Judge Protocol · p. 21

D.1 Offline Replay for Contract Ablation

• Replay rewrites existing drafts without rerunning the agent, calling Gmail or Notion, sending email, or rerunning PrivacyChecker.Generated logs are synthetic artifacts with simulated send events and actual_email_sent=false.Source: §D.1 · pp. 21–22
• Each replay starts from the original user instruction, information-release contract, and upstream agent draft recorded in the execution log.The original draft is taken from the logged Gemma rewrite request arguments.Source: §D.1 · p. 21
• The compared variants are generic Gemma rewriting, the full contract, and a contract with required slots, information shape, and fulfillment requirements emptied.Other contract fields remain unchanged in the utility-shape ablation.Source: §D.1 · p. 21
• Holding each item's original draft fixed makes leakage differences attributable to rewrite-conditioning variants, but replay cannot compare full-pipeline utility or operating costs.Runtime, token cost, checker-call amplification, and recipient correctness are outside this replay's scope.Source: §D.1 · p. 22

D.2 Residual Semantic Leakage in Gemma-Only

• Gemma-only left cues that caused two of three annotated sensitive items to be judged leaked, while Gemma + Checker yielded zero leaked items.The Gemma + Checker email preserved the benign coordination task while abstracting the wording.Source: §D.2 · p. 23
• The residual disclosures came from combinations of health-management, respiratory-care, environmental-trigger, and activity-clearance language that enabled reconstruction.The remaining phrases were less explicit than the original private facts.Source: §D.2 · p. 23
• The example distinguishes direct redaction from semantic privacy enforcement: the checker evaluates the rewritten email and can trigger further abstraction when implications remain.The full mechanism therefore uses Gemma for initial leakage reduction but retains the checker as the final safety layer.Source: §D.2 · pp. 23–24