An Android agent can encounter sensitive content in more places than its final screenshot. Screen trees, action arguments, task prompts, app storage, replay manifests and CI artifacts may all contain user data. Decide what each recipient actually needs before copying a whole trace into another system.
This is an engineering data-handling guide, not a claim of a compliance certification or a particular retention guarantee. Use a harmless test account for the first integration, and check the current terms and deployment requirements for your own use case.
Separate the credential from the task
Your Mobilebox API key authorizes the caller. The task prompt describes the intended work. The Android app may have its own account credentials and session. Keep those three roles separate: a phone-control key does not belong in a note the agent writes, and an app password does not belong in a public operation example.
An MCP client should load its bearer credential through its protected configuration. A direct API integration should read it from a secret mechanism. The key hygiene guide covers ownership and rotation; the agent guide explains the control contract without requiring a real key in a prompt.
Prefer the smallest useful evidence
If your assertion is “the test marker is present”, keep the relevant observed field and operation result. A full screenshot may reveal unrelated notifications or account details. Conversely, a text tree can include more sensitive readable content than the pixels you intended to crop. “It is text” does not mean it is harmless.
For a debugging report, useful non-secret context includes the app package/version, operation sequence, returned error code, runtime settings and the exact harmless marker used. Add broader artifacts only when they help establish the failure. The screenshot-versus-tree guide explains the evidence trade-off.
Inspect export paths, not only the phone
| Boundary | Practical question |
|---|---|
| Agent/model input | Which screen content and action arguments are sent to the model provider? |
| CI logs | Are headers, environment dumps or typed values printed? |
| Artifact storage | Who can download the screenshot or trace, and for how long? |
| Shared task/chat | Does the copied evidence include a live credential or account identifier? |
| Public demo | Are every screen and response safe to publish together? |
A replay can be fully recorded and still leak real data. Labeling it “recorded” answers the live-versus-replay question, not the privacy question. The public Mobilebox demo uses harmless note text and a manifest without API keys or provider tokens; repeat that review for your own capture rather than assuming every future recording is safe.
Understand what stopping preserves
Parking stops the running phone while retaining stored app data. It does not remove an app account from that sandbox. Deleting a phone removes that local sandbox’s data, but it does not revoke a remote account session, delete server-side records, or remove artifacts you already uploaded elsewhere.
Plan those operations independently. If a test logs in to a third-party staging account, decide whether its remote session needs revocation. If a CI system saved a screenshot, use that system’s artifact controls. If a key appeared in a transcript, revoke it rather than relying on editing a local copy.
Test the boundaries with synthetic data
Before using a real account, run the workflow with clearly synthetic text and inspect every output destination. Confirm that the expected assertion is still possible after removing unnecessary fields. Verify that cleanup reports its actual result and does not claim deletion when a request failed.
Keep separate policies for disposable tests and retained agent workspaces. The fresh-versus-persistent guide describes those lifecycle choices, while workflow evaluation shows how to retain enough evidence to judge a task without keeping every byte it encountered. The API reference defines the available lifecycle operations.