iOS 27 turns mobile apps into callable AI capabilities

At a glance

What this is: NHI Mgmt Group's analysis, drawing on NowSecure's blog post: iOS 27 expands Siri AI into app discovery and orchestration, turning app intents and schemas into callable capabilities that can be chained across applications.

Why it matters: Mobile security teams need to treat AI-driven app invocation as an authorization and workflow-testing problem because the security boundary now extends beyond the app UI.

Context

App intents are structured actions an app exposes to the operating system so Siri, Spotlight and related system experiences can discover and invoke them. In iOS 27, that model becomes more powerful because AI can select and chain actions across apps without the user opening each application. The governance gap is that many mobile security programmes still assume the user must navigate the app before a sensitive action occurs.

That shift matters for identity and access decisions as much as for mobile code quality. Once AI can act on a user’s behalf, teams have to decide which capabilities are callable, which require confirmation, and which need stronger authentication or context checks. The typical starting position in enterprise mobile security is not ready for this model, because most testing still focuses on screens and APIs rather than end-to-end AI workflows.

Key questions

Q: What breaks when mobile apps expose actions to Siri AI without stronger governance?

A: The main failure is that sensitive actions become reachable through a delegated AI path instead of only through the app’s own user interface. That expands the trust boundary, because confirmation, authentication and context checks now have to operate at invocation time. Without that governance, teams can approve a feature and still create an unintended execution route.

Q: Why do MCP workflows increase authorisation risk for AI tools?

A: Because the model can initiate actions across tools and services without the stable human request pattern that many identity controls assume. That makes scope management and session trust more important than the login event itself. If the server over-trusts the client or reuses broad tokens, the model can overreach within an otherwise legitimate workflow.

Q: How can security teams tell whether app intents are being governed well?

A: Look for intent inventories, risk-labelled schemas, clear confirmation rules and testing that covers complete orchestration paths rather than isolated screens. If teams can only describe the app’s UI, they do not yet understand the callable surface. Good governance shows up when sensitive actions are intentionally constrained in the workflow layer.

Q: Should organisations prioritise workflow testing or traditional mobile AppSec first?

A: 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.

Technical breakdown

App intents turn mobile features into callable capabilities

App Intents are discoverable actions, not ordinary internal methods. They let system intelligence understand that an app can send a message, place an order, create a reminder or return a record, then invoke that action in response to a user request. In iOS 27, the important change is that Siri AI can reason over those exposed capabilities and choose among them as part of a larger workflow. That moves the security question from whether an action exists to whether the action should be reachable through an AI-mediated path at all. It also means developers are effectively publishing an executable interface to the OS, with all the governance implications that come with discoverable functionality.

Practical implication: Inventory every exposed intent and classify each one by sensitivity, user impact and required confirmation before enabling AI discovery.

App schemas and inherited risk metadata shape runtime decisions

App schemas standardise the entities and actions Siri can understand, which reduces ambiguity but also creates a new trust layer between the app and the assistant. When the schema describes what data exists and how an action behaves, the OS can apply inherited risk metadata and default authentication policies at runtime. The article’s key point is that the application no longer controls when an action is selected inside a chain of steps, only what it is willing to expose. That creates a policy boundary where schema design, risk labelling and confirmation behaviour become part of the control plane. A misdescribed action can therefore become an access problem, not just a UX issue.

Practical implication: Review schema definitions as security artefacts and verify that high-risk actions trigger the right authentication and confirmation logic.

AI-driven workflow testing must cover context, chaining and data movement

Traditional mobile AppSec testing assumes a user opens an app, navigates its interface and triggers a single action. AI-driven workflows break that assumption by introducing prompts, external context, multiple source applications and chained execution. The result is a new class of failure where the app behaves correctly in isolation but exposes unintended outcomes when Siri combines it with other data or actions. Testing therefore has to move beyond screen flows to full workflow behaviour, including what data leaves the app, which models or services see it, and how the app reacts to unexpected inputs. This is where mobile AppSec starts to overlap with identity governance and data handling discipline.

Practical implication: Test complete AI workflows end to end, including context sources, cross-app chaining and any data that can leave the application boundary.

Threat narrative

Attacker objective: The attacker objective is to get sensitive app actions executed through a trusted AI workflow path that bypasses the app’s normal user journey.

1. Entry occurs when Siri AI discovers an application’s exposed intent or schema and decides that capability can satisfy a user request.
2. Credential or authorisation abuse occurs when the workflow executes on the user’s behalf without the app being opened, so the trust decision shifts into the assistant layer.
3. Impact occurs when sensitive functionality, data retrieval or transactional actions are invoked through an unintended AI-mediated path.

Breaches seen in the wild

• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Callable capabilities create a governance problem before they create a coding problem. Once an app publishes discoverable intents, the control question becomes who or what is allowed to invoke them, under what context, and with which confirmation steps. That is a policy decision embedded in a mobile runtime, not a cosmetic AI feature. Practitioners should treat exposed intents as governed access paths, not convenience features.

App schemas are becoming the mobile equivalent of authorization descriptors. The article shows that schema design now influences what Siri can discover, how it reasons, and when it asks for confirmation. That means schema review belongs alongside threat modelling and release approval. Practitioners should validate schema semantics the same way they validate privileged APIs, because a poorly framed capability can widen the effective attack surface.

Mobile identity risk is shifting from static app sessions to delegated agent action. The user is still the principal, but the execution path is mediated by Siri AI and multiple application contexts. That is a delegation problem as much as an app security problem, and it weakens older assumptions about direct user interaction. Practitioners should update identity and authorisation controls for delegated AI execution, not just for login events.

AppSec programmes need a workflow boundary, not just a binary boundary. The article’s strongest insight is that security testing now has to cover what happens before invocation, during orchestration and after data moves across apps. That broadens the control surface into confirmation policy, context handling and cross-application chaining. Practitioners should align mobile testing with workflow governance, because the risk now lives in the path between apps as much as inside them.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Callable mobile features create governance debt: when an app publishes intents for AI discovery, the control boundary shifts from the interface to the invocation policy. Teams that keep testing only screens will miss the more important question of which actions an assistant is allowed to trigger.

Delegated mobile action needs identity-aware controls: the user remains the principal, but Siri AI becomes the execution path, so authentication, confirmation and data-sharing rules have to bind to the action itself. That is where mobile AppSec, IAM and workflow governance now intersect.

S3 of security leaders agree identity management must fundamentally shift to address agentic AI systems according to the 2026 Infrastructure Identity Survey. That finding is directly reflected here: static user-session assumptions are no longer enough when software can reason about and execute actions on a person’s behalf.

For practitioners

• Inventory callable app intents Build a complete register of every App Intent and schema currently exposed by your mobile applications, then classify them by sensitivity, data exposure and transaction risk.
• Review authentication and confirmation rules Check which intents require re-authentication, explicit user confirmation or step-up handling before Siri AI can invoke them, especially for payments, records and customer actions.
• Extend threat models to AI workflows Model prompts, context sources, cross-app chaining and external models as part of the mobile threat surface rather than treating them as separate AI features.
• Test end-to-end invocation paths Validate complete Siri-driven flows, including unexpected inputs, multi-step orchestration and any data that leaves the app boundary during execution.
• Track data movement through AI mediation Map which services, models and applications receive application data during AI-driven actions so you can detect unintended disclosure or retention.

Key takeaways

• iOS 27 turns mobile app functionality into callable capabilities, so the security boundary now includes AI-mediated invocation and cross-app orchestration.
• The main governance gap is not whether the app works, but whether each exposed intent is safe to discover, chain and execute in a delegated workflow.
• AppSec teams need to inventory intents, tighten confirmation rules and test full AI workflows because screen-level testing will miss the new failure modes.

Key terms

• App Intents: Apple’s framework for exposing app actions to system-level assistants such as Siri. These intents can read data, modify content or trigger external actions, so they must be treated as authorization-controlled execution points rather than simple UI shortcuts. Their risk depends on the side effects they can reach.
• App schema: A standardised description of app entities and actions that helps an assistant understand what the app can do. Schemas improve interoperability, but they also expand what the assistant can discover about the app’s data and workflows. Security teams should treat schema design as part of the trust boundary.
• Delegated AI Agent: A delegated AI agent is an AI system that acts on behalf of a person, team, or service under a defined scope of authority. It can request, use, or pass credentials and perform tasks within approved limits. In identity security, delegation must be bounded, auditable, revocable, and tied to the original human or machine sponsor.
• Workflow Boundary: The operational limit around which processes, tools, and data an actor may touch. For AI agents, workflow boundaries prevent permission creep by ensuring the system cannot move from one business context to another without explicit governance. This is a control concept, not a user interface concept.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for security and identity practitioners who need to govern delegated access, machine identities, and AI-driven execution paths.