Answer First
Definition: Mobile automation credentials are the secrets a script needs to act as a logged-in account on a managed Android device: usernames and passwords, API tokens, session cookies, and one-time passwords (OTPs). The real question is not what they are, but where they live when the script runs — and in most automation setups, the answer is: everywhere except where they belong.
Why: Every task that logs in, syncs, or posts needs a credential at some point, and the path of least resistance is to put it inside the script itself. That works until the script is shared, the task log is reviewed, or the screenshot is attached to a ticket — at which point the credential stops being a secret. The pain is growing because more and more scripts are generated by non-developers with AI assistants, and a model will happily embed a login and a token if that is what the prompt asks for. Storing credentials centrally, injecting them at run time, rotating them on expiry, and scrubbing them out of evidence artifacts is not an app feature. It is an operating discipline — and it is the difference between a credential that can be revoked and one that is already public.
Example: A routine AutoJS task opens an app, signs in, and posts a status update. The script begins with var password = "...". When it runs, the task log captures the session token returned by the login response, and the evidence screenshot shows the two-factor code sitting in a notification. One task, three places the credential now lives — the script file, the log, and the screenshot — none of them the central store. This is the default, not the exception, in script-driven cloud phone work. As we covered in Agentic Automation Security: How to Keep Cloud Phone Account Work Under Control, account work at scale only stays under control when the security layer is explicit rather than improvised.
Key Facts
- Hardcoding is the default. Scripts that log in with a literal password or token outnumber parameterized ones, especially when the script was generated by an AI assistant rather than written against an API contract.
- Credentials spread across four surfaces: script source code, task logs and console output, evidence screenshots and screen recordings, and app data persisted on the device (cookie stores, shared preferences, webview storage).
- The shortest-lived secrets leak most often. Session cookies and OTPs are captured passively — printed by a login call, visible in a notification — so no one deliberately “embeds” them, and therefore no one thinks to protect them.
- Rotation has a hard practical limit. A credential that is captured in a screenshot or log can be rotated after the fact, but anything it authorized in the meantime is done. Scrubbing and avoiding capture matter as much as rotation.
- Central storage has its own practical limits. One store per environment is only better if it has access control, availability, and an audit trail — otherwise you have simply moved the single point of failure.
- This is a recognized weakness class. The OWASP Mobile Application Security Verification Standard (MASVS) separately catalogs sensitive data hardcoded in the app, insertion of sensitive data into logs, and insufficient protection of data in screenshots — the same three surfaces this article covers.
Expert Explanation
Step 1: Inventory where credentials actually live
Before changing anything, find the credentials. Walk one real task end to end and note every place a secret touches:
Script source. The obvious one: var password, const token =, a cookie string pasted into a config block. In AI-generated scripts this is systematic — the generator has no reason not to inline whatever the user pasted into the prompt. Scan scripts for string literals that look like credentials before you trust them.
Task logs. Scripts log liberally because debugging is hard on a device you cannot see. console.log of the login response, a token echoed “for debugging,” an OTP printed because the script needs to read it back. Logs are the quietest leak because they look like operational noise. As our post on AI Agents Need Logs. Mobile Automation Needs Them Even More argues, logs are indispensable — which is exactly why they need a masking policy rather than being turned off.
Evidence screenshots. Cloud phone platforms capture screenshots and recordings so humans can review what a task actually did. Those artifacts are gold for review and gold for leaks: login screens, profile pages, token QR codes, and OTP notifications are all routinely captured. The MASVS explicitly lists insufficient protection of sensitive data in screenshots or screen recordings as a weakness, and the MASTG’s best-practice catalog includes preventing screenshot capture and preventing sensitive data exposure in notifications.
Device app data. The app itself persists cookies and sessions on the device. This is mostly out of the script’s control — the app stores what it stores — but it means a reused device or a restored backup carries sessions forward. The MASTG’s Android data storage testing guidance exists precisely because this data is routinely extractable.
Step 2: Store centrally, inject at run time
The pattern is simple: no credential ever appears in a script file. Scripts declare what they need by key or environment, and the runtime fetches the actual value from a central store at execution start and passes it in — as a parameter, an environment variable, or a config the script reads but never writes. The script contains getSecret("account_login"), never the login itself.
This is exactly the direction the OWASP Secrets Management Cheat Sheet pushes: centralize and standardize secrets, restrict access to them, and keep them out of code. The same cheat sheet is blunt about the lifecycle discipline — creation, rotation, revocation, expiration — and about the rule that secrets must never be logged in plaintext.
Central storage pays off most when it is shared across tasks: rotate one secret in the store and every script that uses it picks up the new value on the next run, instead of you editing twelve copies by hand and missing one.
Step 3: Rotate on expiry — and treat expiry as an operational event
Every credential has a lifetime, and in mobile automation the server usually decides it. Session cookies expire on a schedule the script cannot extend. Tokens get invalidated by the app or by a suspicious-login trigger. OTPs live for seconds. So rotation is not a monthly chore; it is a reaction to signals:
- A task fails with a session-expired or unauthorized error → the credential expired or was revoked; re-authenticate and record the new session.
- A script stops working after an app update → the app changed its auth flow; the stored credential is stale.
- A credential appears in a log, a screenshot, or a shared file → treat it as compromised and rotate immediately, regardless of expiry.
The OWASP Secrets Management guidance on automated rotation and revocation applies directly here: the value of a central store is that rotation is a single operation, and the value of treating expiry as an event is that a failed task tells you a credential changed before a human has to guess why. When a mid-task failure is the first signal something expired, the follow-up matters too — see AI Agent Failed Mid-Task. What Happens Next?.
Step 4: Scrub evidence before human review
Screenshots and logs exist so a human can verify the task did the right thing. That human should never be handed a credential. A scrubbing pass runs between task completion and human review:
- Mask token-shaped strings in logs before they are stored or displayed.
- Redact or drop frames that contain OTP notifications, password fields, or token QR codes.
- Keep the original device-side evidence for audit if you must, but make the review copy the scrubbed one — and make sure the original is access-controlled, not merely hidden.
The honest practical limit: redaction is best-effort. An image redactor can miss text it does not recognize, and a log scrubber can miss a format it does not know. So scrubbing is a second line of defense; the first line is not capturing the secret at all. The discipline connects to the wider point in AI Agents Need Permissions and Audit Trails. Mobile Automation Needs Them Too: audit value and secret hygiene only coexist when the pipeline is designed for both from the start.
Decision Framework
| Approach | Where secrets live | Effort | Leakage risk | Use when |
|---|---|---|---|---|
| Hardcoded in script | Script files, plus logs/screenshots at run time | None | High — shared scripts and AI generation make this the norm | Never, for anything beyond throwaway local tests |
| Local config on device | On-device file or app data | Low | Medium — device backups and app data extraction expose it | Single device, single operator, short-lived credentials |
| Runtime injection from a store | Central store, fetched per task | Medium | Low — nothing in code; logs/screenshots still need masking | More than a few scripts or operators; shared fleet |
| Central store + rotation + scrubbing | Central store only; artifacts masked | High | Lowest — rotation contains any single leak | Compliance pressure, or any leak you cannot detect immediately |
Rule of thumb: the moment two people can edit scripts, or one script runs unattended overnight, you have already outgrown hardcoding. For operations teams running many tasks, the control-tower view matters as much as any single store — the same argument we make in AI Agent Control Tower for Mobile App Workflows: What Operations Teams Actually Need.
Key Takeaways
- Inventory first: script source, task logs, evidence screenshots, and device app data — every one is a credential surface.
- Store centrally, inject at run time; a script file that contains a literal password or token is a leak waiting to be shared.
- Rotate on expiry signals: session-expired failures, app updates, and any sighting of a credential in an artifact.
- Scrub evidence before human review, but design tasks so secrets are never captured in the first place.
- Central storage is only as good as its access control and audit trail — and no store can revoke a secret that already left the building.
- If your automation runs on a cloud-phone operations platform like QCCBot — managed Android devices, script execution, monitoring, and human review of task evidence — treat credential hygiene as part of the operating procedure, not as a setting.
FAQ
Q: What counts as a mobile automation credential? A: Any secret a script needs to act as a logged-in account on a managed Android device: usernames and passwords, API tokens, session cookies, one-time passwords (OTPs), and sometimes device PINs or app-specific passcodes. The ones teams forget to inventory are the short-lived ones — session cookies and OTPs — because they expire quickly and seem harmless by the time anyone looks at them.
Q: Why do session cookies and OTPs leak more often than passwords? A: Because they are captured passively, not typed in. A login response prints a token into the task log; a two-factor notification appears in an evidence screenshot; the script never “hardcoded” anything, so nobody flags it. Passwords at least require deliberate embedding. Cookies and OTPs just show up in artifacts that get shared, stored, and reviewed.
Q: Do I need a full secrets manager, or is there a minimum viable setup? A: You can start small: no credentials inside script files, a single central store per environment, runtime injection into each task, and a review pass that redacts logs and screenshots before human review. That covers most of the risk. A dedicated secrets manager with automated rotation, access control, and audit logging is worth adding when multiple people can edit scripts, or when you cannot guarantee that a leaked credential will be detected and revoked quickly.
Q: A credential showed up in a log or screenshot. What do I do? A: Treat it as compromised. Rotate or revoke it immediately, confirm the artifact is scrubbed or deleted wherever it was stored or shared, and check whether the script that produced it can avoid capturing the secret next time — mask the token, skip the screenshot step, or redact before it leaves the device. Rotation is the remediation; the fix is preventing the capture.
Sources
- OWASP Mobile Application Security Verification Standard (MASVS) — hardcoded secrets, secrets in logs, and screenshot exposure as distinct weaknesses: https://mas.owasp.org/MASVS/
- OWASP Mobile Application Security Testing Guide (MASTG) — Android data storage testing and best practices for logging, screenshots, and notification exposure: https://mas.owasp.org/MASTG/
- OWASP Secrets Management Cheat Sheet — centralization, lifecycle (creation, rotation, revocation, expiration), and the rule that secrets must never be logged: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html