Your Mobile Actions Need an Authorization Test Plan

Mobile teams usually test an action through the interface that exposes it. A user opens the app, selects a record, reviews the context, confirms the choice, and submits the change.

App Intents and AppFunctions alter that path. An OS-level assistant can discover an action, resolve an entity, supply parameters, and invoke the capability without following the screens your team designed. UI automation adds a second path: the agent may operate visible controls even when the app has no structured function integration.

That does not make either platform unsafe. It does mean the security claim has changed.

The question is no longer only, “Can an authorized user complete this workflow in the app?” It is also, “Does every agent-mediated route preserve identity, authorization, business rules, meaningful confirmation, recoverability, and evidence?”

Start with the action catalog

Build a platform-specific inventory of actions and entities before writing test cases. For each entry, record:

• where the action is advertised, indexed, donated, suggested, enabled, or disabled;
• whether it is read-only, a reversible write, a consequential write, an administrative action, or irreversible;
• which roles, tenants, subscriptions, regions, and account states may use it;
• the parameters and entities it accepts;
• the API or remote service that performs the final operation;
• whether it requires preview, confirmation, local authentication, or server-side step-up; and
• whether the result is idempotent, reversible, compensating, or manually recoverable.

This inventory lets engineering compare the approved surface with what the OS and authorized callers can actually discover. It also exposes deprecated or support-only handlers that should not ship in the production catalog.

Model identity as a chain

An agent-mediated request can involve several principals: the device user, signed-in app user, assistant, calling app, system process, and backend service identity. Do not collapse them into a single “authenticated” state.

Test the chain across logout, account switching, token refresh, role change, device lock, biometric change, app reinstall, profile change, and remote revocation. If an entity identifier syncs across devices, verify that a stable ID cannot substitute for current authorization.

On Android, the EXECUTE_APP_FUNCTIONS permission controls which callers can discover or execute AppFunctions at the platform layer. It is not the business-authorization decision. The app and backend still need to verify the current user, tenant, resource, action, amount, destination, and workflow state.

The practical pass condition is simple: prohibited actions fail even when the assistant selects the correct function and supplies a syntactically valid request.

Treat resolved entities and parameters as untrusted input

The OS may provide a function invocation, but values such as names, record IDs, dates, amounts, destinations, files, and contacts still cross a trust boundary.

Build negative tests for:

• ambiguous names and duplicate entities;
• stale or deleted records;
• entities from another account or tenant;
• read-visible records that are not writable;
• out-of-range amounts, dates, or quantities;
• prohibited destinations and workflow states; and
• action metadata that remains available after a role or policy change.

Do not test only whether the app rejects malformed values. The harder case is a well-formed value that is valid in the system but invalid for the current user or action.

Bind confirmation to the final action

Confirmation is useful only when it communicates the consequence. For a consequential write, the preview should identify the action, target, account or tenant, amount or data scope, destination, and reversibility.

Verify that those values cannot change between confirmation and execution. If the app re-resolves an entity, refreshes a record, or accepts a different backend identifier after approval, the person may have confirmed one action while the system performed another.

Avoid making every harmless read require approval. Excessive prompts train users to accept without checking. Apply confirmation and reauthentication where they reduce actual risk: purchases, external messages, sensitive disclosures, destructive changes, privilege changes, and irreversible operations.

Test interruption and duplicate execution

Long-running and background actions need explicit failure semantics. Exercise timeout, app termination, device lock, network loss, duplicate invocation, retry, cancellation, and partial completion.

The business impact is often concrete: a duplicate charge, repeated booking, orphaned file, inconsistent record, or support case with no reliable way to determine the final state. The control may be idempotency, a compensating transaction, a rollback operation, or manual recovery. Whatever the design, the test should prove it.

Make the audit trail reconstruct the event

Logging only the assistant’s final response is not enough. A useful audit chain connects:

1. the originating user and device or session;
2. the calling surface;
3. the selected action or function;
4. material resolved parameters;
5. the authorization result;
6. the confirmation event;
7. the backend request and outcome; and
8. the app, OS, and framework versions involved.

Support and incident-response teams should be able to answer what was requested, what the system resolved, what the person approved, what executed, which records changed, and how the path can be disabled or reversed.

Connect technical scope to the release decision

For leadership, the test output should not be a collection of platform observations. It should provide an action inventory, identity and authorization trace, negative-test evidence, affected builds and versions, business impact, remediation guidance, and retest status.

Effort grows with action-role-state combinations, not just the number of screens. A small app with ten write functions, four roles, two tenant types, and several account states may require more authorization testing than a large app with one low-risk read action.

Retest after remediation and after material changes to the OS, App Intents or AppFunctions definitions, action metadata, entity model, permissions, identity flow, approval logic, model or assistant behavior, APIs, remote tools, or high-impact workflows.

The complete buyer-focused release and scoping guide is available in the canonical article: Agent-Actionable Mobile App Security Testing.