Meet Trust Insights

Watch on Apple Developer

TL;DR

What Trust Insights is for

Trust Insights addresses social-engineering attacks where the authenticated user performs a legitimate action while being pressured or coached by an attacker. Traditional authentication can confirm who is acting, but not whether the person is acting freely.

The framework provides behavioral context for sensitive moments in an app, such as payments, account changes, costly resource use, communications, remote-access grants, personal data export, or other irreversible actions.

• Introduced as a new iOS 27 framework.
• Designed for scams involving coercion, authority impersonation, tech-support fraud, family emergency fraud, and real-time coaching.
• Uses privacy-preserving machine learning to produce a small risk signal rather than exposing raw behavioral inputs.
• Best used alongside existing fraud, risk, and decisioning systems.

Generating an insight

Trust Insights requires an entitlement, configured by declaring the capability on the app target in Xcode. The app then imports TrustInsights, creates requested insight parameters, builds an InsightEvaluator.InsightContext, checks authorization, and asynchronously requests an evaluation.

The operationCategory tells the system what type of action is being evaluated and determines which model logic applies. Available categories are payment, account, resourceUse, communication, and other; Apple asks developers to file feedback if an important use case falls into other.

Evaluation can take a couple of seconds and requires Internet reachability, so apps should place the request at an appropriate point in the flow, such as during an existing interstitial, animation, or confirmation step.

• A schema is required when requesting an insight; modelVersion is optional.
• Requesting current and prior model versions can support model governance and validation.
• Development requests use a sandbox environment; App Store-distributed apps use production models and servers.
• Xcode build-scheme launch arguments can override insight values and errors for testing decision logic and UX variants.

Request and evaluate an IsLikelyBeingCoachedInsight

Creates an insight request, evaluates it for a resource-use operation, handles the result, and reports consumption feedback.

import TrustInsights

let request = IsLikelyBeingCoachedInsight.request(
    schema: .version1,
    modelVersion: .current
)

let context = InsightEvaluator.InsightContext(
    operationCategory: .resourceUse,
    requestedEvaluations: request
)

let evaluator = InsightEvaluator()

guard try await evaluator.requestAuthorization(for: context) == .authorized else {
    return
}

let assessment = try await evaluator.requestEvaluation(context: context)

do {
    try handleAssessment(assessment)
} catch {
    // Handle error
}

assessment.reportConsumption(.usedIncreasedFriction)

Interpreting results and errors

The response includes one result per requested insight evaluation. For IsLikelyBeingCoachedInsight, the outcome can be unknown, medium, or high. The session emphasizes that unknown means the system has no evidence of scam risk; it must not be treated as low risk.

A medium result indicates some evidence of coaching risk and may justify added friction, extra verification, or risk-score adjustment. A high result indicates significant evidence of coaching risk, and the user should be informed of the determined risks before proceeding.

Evaluation-level errors and insight-level errors have different meanings and should be handled independently.

• Do not block a user solely because of a Trust Insights signal.
• Do not treat missing values, errors, or unknown as safe outcomes.
• Use results as inputs to the app's broader risk and product logic.
• Handle @unknown default for future enum cases.

Handle IsLikelyBeingCoachedInsight outcomes

Switches over the supported coaching-risk outcomes while leaving room for future cases.

func handleAssessment(_ assessment: InsightEvaluation<IsLikelyBeingCoachedInsight>) throws {
    switch try assessment.insight.outcome.get() {
    case .unknown:
        break
    case .medium:
        break
    case .high:
        break
    @unknown default:
        break
    }
}

Feedback requirements

Trust Insights requires real-time consumption feedback for each insight evaluation. Apps call reportConsumption on the evaluation result to describe whether and how the insight affected the experience. Omitting this feedback may cause the app to be rate-limited.

Offline feedback is separate. If an operation that used Trust Insights is later confirmed as fraudulent, the app or business can submit an offline label through Apple Business Register using a server-to-server API and the insight identifier from the original evaluation.

• Consumption values include usedReducedFriction, usedUnchangedFriction, usedIncreasedFriction, notUsedNotNeeded, notUsedError, and usedEvaluationOnly.
• Offline labels may arrive days, weeks, or months after the original evaluation.
• Offline label submissions should not include surplus information such as PII.
• Apply privacy-preserving techniques to any remaining values that could be used for fingerprinting.
• Offline labels are optional for using Trust Insights, but help improve the ecosystem.

Report real-time consumption feedback

Reports that the insight caused the app to add checks or friction; this feedback is mandatory for each evaluation request.

assessment.reportConsumption(.usedIncreasedFriction)

Privacy model and user control

Trust Insights is designed around data minimization. Device-sourced data is processed locally, inputs are discarded immediately after evaluation, and only a single output value leaves the user's device. The final output may also incorporate Apple Account signals and velocity checks.

The framework analyzes interaction patterns, timing, context, and basic sensor data. It does not inspect content from Photos, Messages, or Mail, and device-derived signals are not shared with Apple or third parties.

Users control whether Trust Insights is enabled and can disable it in Settings. A cooldown period may apply after disabling to protect users who may have been coached into turning it off.

• Apps should query authorization status before relying on Trust Insights.
• If not authorized, consider how to inform the user or fall back to other risk logic.
• Privacy constraints are part of the framework's threat model, not an optional implementation detail.

Best practices and adoption

The highest-value adoption points are moments where coercion would cause meaningful harm: high-value financial transactions, irreversible operations, permission grants, and sensitive data sharing. A sample response to a medium signal is to warn the user and delay a large transfer, but other apps might route the case to server-side risk logic or manual review.

Trust Insights should be integrated into existing risk and decision pipelines. Use model-version sampling to understand how newer models affect decisions before changing production behavior.

• Identify sensitive flows where behavioral context adds value.
• Use increased friction, warnings, delays, additional verification, server-side review, or risk-score adjustments based on app context.
• Avoid using Trust Insights as the only determinant in a decision.
• Submit required real-time feedback and, where possible, offline fraud labels through Apple Business Register.
• Use Feedback Assistant for framework feedback, capability requests, or high-volume use cases.

Resources

• TrustInsights

Related Sessions

• Secure your apps with App Attest

Unofficial, not associated with Apple. By