How an AI chat assistant secured its models and data across two attack surfaces

Summary

The company behind a global AI chat assistant, built with Flutter for iOS and Android, turned to Promon and TrustPin to protect the assets exposed by its device and cloud architecture: embedded, on-device AI models, API credentials, and user conversations. Promon Shield for Mobile™ protects the app and embedded components at rest and at runtime even if the device is compromised, while TrustPin secures the connection to its hosted inference API. In production since November 2025, the combination has handled weekly certificate rotations without a single app release or connectivity incident and has held up against the customer's own penetration testing.

Company profile

The customer operates a consumer AI chat assistant with a global user base, distributed through iOS and Android app stores. Built with Flutter, it runs compressed models locally for offline use and connects to a hosted inference API for tasks that exceed the device's capabilities. That split architecture means valuable assets, from model files to user data, live in two places the operator doesn't fully control: the user's device and the network between it and the service.

The challenge

The app's on-device models represent significant intellectual property and could be copied and redistributed if extracted from a device. API credentials appear both in app memory and in outgoing request headers, putting them at risk on-device and in transit. Network traffic can also reveal the client-service protocol itself, and user prompts and responses also need protection to safeguard user privacy, not just a security one. A single control couldn't address all of it: some assets were at risk on the device, others on the wire, and credentials on both.

Promon's solution

Application shielding & RASP (Promon Shield): Promon Shield uses post-build tooling to harden the compiled app against reverse engineering and tampering, and protects it at runtime. The TrustPin SDK operates at the native-code level. The hardened app detects and responds to four conditions: repackaging, by binding the app to its legitimate signing certificate so a modified, re-signed version won't run; root and jailbreak status, blocking sessions on devices where the OS's normal security boundaries have been removed; emulators and virtual environments, which attackers can use to analyze or manipulate apps; and instrumentation, identifying attached debuggers, injected libraries, and hooking frameworks and either reporting or terminating the session depending on severity.
Managed certificate pinning (TrustPin): Dynamic pinning protects the channel shielded apps communicate over. Rather than embedding a fixed list of trusted certificates in the binary, pin sets are managed centrally and delivered to the client at startup through the TrustPin Flutter SDK, turning certificate rotation into a configuration change instead of an app release. Each TrustPin project has its own ECDSA P-256 keypair: the public key ships in the app, the private key never leaves TrustPin, and every configuration file is signed and verified by the SDK before use, so a compromised delivery path can deliver a file but can't forge a valid signature. The app fails closed rather than falling back to an unpinned connection if validation doesn't pass.
Real time security monitoring: These security events feed the team's monitoring platform, providing greater visibility into attacks in production: how often the app encounters rooted devices, whether a particular release is attracting attention, and whether suspicious activity looks isolated or coordinated.

Results

Since going into production in November 2025, the app has absorbed weekly certificate renewals, including multiple rotations in some weeks, without requiring an app-store release or reported loss of connectivity. The customer's own security team then tested the design by attempting to reach the protected intellectual property: the on-device models, the service credentials, and the traffic between the app and API. They could not get past Promon Shield at runtime, and TrustPin's pin validation held both in the running app and against the configuration files stored on the device.