They should do both, but workflow testing needs to become a release gate as soon as AI can invoke app capabilities. Traditional AppSec still matters for code, APIs and data handling, yet it will miss failures that appear only when Siri chains actions across apps. The priority is to test the delegated path before users depend on it.
Why workflow testing has to come before mobile appsec once AI can act across apps
Traditional mobile AppSec is still necessary, but it only covers part of the failure surface. Once an AI can chain actions across apps, the security question shifts from “is each app safe in isolation?” to “does the delegated workflow do the right thing under real conditions?” That is why workflow testing becomes the first release gate when orchestration enters the path.
Mobile AppSec is strongest at code, API, session, storage, and input control weaknesses inside a single application boundary. Workflow testing is different: it validates the cross-app decision path, the sequence of permissions, the prompts or triggers that start it, and the side effects that emerge only when tools are combined. A release can pass conventional app testing and still fail in the delegated flow.
That change matters because cross-app automation creates a new trust boundary. If a user expects Siri, an assistant, or another orchestrator to complete a task, the risk is no longer just a vulnerable endpoint or a missing input check, it is that the system can take a legitimate action in the wrong order, in the wrong context, or with broader authority than intended. For a practitioner, the workflow is now part of the security control plane.
What traditional mobile AppSec still covers, and where it stops
Traditional mobile AppSec remains the right lens for secure coding, data handling, authentication flows, local storage, transport security, and API exposure. It is still the right place to find flaws like insecure token storage, broken authorization in APIs, weak session controls, and unsafe handling of sensitive data. Those controls matter even when AI is involved, because the underlying apps still process secrets, accounts, and user data.
Its limitation is scope. Mobile AppSec usually evaluates one app, one API, or one codebase at a time. That means it can miss failures that appear only after a trusted assistant or agent invokes multiple capabilities in sequence. A workflow can be “secure” at the component level and still be unsafe as a composed behaviour because the composition changes who can do what, when, and with which assumptions.
That is why the sequencing matters. If the system can invoke app capabilities autonomously, the delegated path must be tested for authorisation, side effects, rollback, and user intent alignment before users depend on it. For the implementation layer, OWASP ASVS and OWASP Top 10 remain useful baselines for the app itself, while the release decision has to extend beyond the app boundary.
How to set the priority without losing either control layer
The practical answer is not to choose one discipline permanently. Prioritise workflow testing first for any release where an AI or assistant can execute actions across apps, because that is where delegated misuse, sequencing errors, and cross-app privilege issues will surface. Keep traditional AppSec in parallel for the app, API, and data controls that make the workflow safe to begin with.
What to prioritise: Test the most powerful delegated path first, especially anything that can create, delete, send, transfer, or expose data. If a workflow can materially affect user accounts, records, or external systems, treat it as a release-critical control rather than a convenience feature.
What to verify: Confirm that every cross-app action is bounded by explicit permission, that the assistant cannot silently expand scope, and that the workflow fails safely when a step is ambiguous, missing, or partially completed. The right question is not whether the app works, but whether the composed action remains correct under realistic use.
Practitioner takeaway: Traditional AppSec protects the components, but workflow testing protects the delegated outcome, and the latter becomes the gating control as soon as AI can act across applications.
Risk and Threat Considerations
Once a workflow can span apps, the main risk is privilege amplification through composition. A sequence that looks harmless in isolation can become dangerous when an assistant can stitch it together, reuse trust from one app in another, or complete a task the user did not fully intend.
Failure mechanism: The workflow passes component-level testing, but the cross-app path allows a valid action to be triggered in the wrong context, with excessive scope, or without a strong enough confirmation step. That creates a gap between local application security and end-to-end behavioural safety.
Impact: Users may approve a release or trust an assistant that can still move money, share data, modify records, or trigger downstream actions in ways traditional mobile AppSec did not evaluate. The result is a release that is technically sound at the app level but operationally unsafe at the workflow level.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and OWASP SAMM set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service Security | Covers the app and API controls still needed in the mobile stack. |
| V8 — Authorization | Relevant because delegated actions must stay within intended permissions. | |
| V16 — Security Logging and Error Handling | Workflow failures need observable evidence and safe error handling. | |
| Recommendation — Verify API authorization, input handling, and service protections before release. Test that each cross-app action is bounded by explicit authorization. Log delegated actions and confirm failures do not expose unsafe states. | ||
| OWASP SAMM | SDR — Security Requirements | Workflow gates need security requirements defined before delivery. |
| REQ — Requirements Management | The question is about when a workflow becomes a release gate. | |
| Recommendation — Define end-to-end workflow security requirements before implementation. Make delegated-workflow security a release requirement, not an optional test. | ||
Practitioner Guidance
Decision rule: If AI can invoke app capabilities or chain actions across apps, make workflow testing a release gate and treat mobile AppSec as a parallel control, not a substitute.
What good looks like: The team tests the delegated path, the app still passes its normal security checks, and the release only moves forward when both the component controls and the composed behaviour are acceptable.
Common mistake: Assuming that a clean mobile AppSec result means the end-to-end assistant flow is safe. That shortcut misses the security boundary created by orchestration.
Practitioner takeaway: The security test now has two layers, can the app resist abuse, and can the workflow be trusted to act only within intended authority, sequence, and context.
Related resources from NHI Mgmt Group
- When should organisations prioritise Zero Standing Privilege for non-human identities?
- Should organisations prioritise static testing or runtime testing first?
- What should organisations prioritise first in an IGA programme, visibility or workflow automation?
- What should organisations prioritise first, coverage or workflow integration?