5. Safe Execution Principles
5.1 Automate action, not judgment
| Action | Default handling |
|---|---|
| Search and summarize | May run automatically |
| Compare schedule candidates | Run, then explain |
| Build a cart | Run, confirm before payment |
| Free booking | Prior consent or final confirmation by policy |
| Paid booking, order, or payment | Present amount and terms, then confirm |
| Transfer health information | Explicit consent to recipient, purpose, and fields |
| Contract, loan, or investment | Never auto-finalize |
| Password or OTP | Only on user device or official authentication surface |
5.2 Prefer official connections
IROA prefers published APIs, institutional standards, MCP tools, Apple App Intents, Android AppFunctions, and other official capabilities. When screen execution is unavoidable, it uses an isolated per-request environment, allowlisted domains and actions, separate user confirmation for consequential steps, no central password or payment-key storage, independent outcome checks, and immediate stop or human handoff on failure.
5.3 Respect mobile-platform limits
Mobile operating systems restrict arbitrary cross-app control. IROA uses official deep links, APIs, intents, shortcuts, allowed system features, and safe web flows first, then moves the request to a secure execution space with approval. Experimental platform capabilities are not treated as launch dependencies.
5.4 Explain and cancel
Users can ask what is happening, why an option was selected, which data goes to whom, whether cost occurs, whether the action can stop or reverse, and whether a person can check it. Explanations use plain language appropriate to the user.