Do not let the model, key, or interface become the weak link

Yudun treats the on-device model, inference runtime, API credentials, inputs and outputs, and update chain as separate risks. Valuable client code and resources are protected while privileged keys and final authorization remain on the server.

Are these problems holding back your app?

  • A model or configuration can be copied or replaced after shipping
  • A long-lived model API key is embedded in APK, IPA, or SO
  • Impersonated clients consume cloud quota and drive uncontrolled cost
  • Model, runtime, and app versions drift and fail in production

How Yudun handles them

  • On-device model and runtime protection

    Define client protection for model resources, pre/post-processing logic, and inference invocation paths.

  • Interface and credential boundary

    Move long-lived privileged keys off the client and use short-lived, limited credentials with server authorization.

  • Model release validation

    Validate model, runtime, and app version pairing, with disable, staged rollout, and rollback paths.

Scenario: when a model API key is extracted, the loss appears in cloud spend and impersonated invocations

A public Yudun architecture scenario explains why hiding a string is not a complete control for mobile AI API theft and abuse.

View the risk-control architecture

What the assessment disclosed

  • The client requests a short-lived, limited credential instead of storing the model master key
  • Model invocations run through a server proxy or controlled gateway
  • Request binding, quotas, records, and cost monitoring expose abnormal use

Scope: This is a public risk scenario and architecture, not a customer incident or a claimed block rate or cost saving.

From assessment to delivery

See the delivery method
  1. 01

    Separate the risks

    Split model, runtime, credentials, interfaces, and user data instead of invoking everything model encryption.

  2. 02

    Set the client-server boundary

    Decide what stays on device and which keys and high-risk actions belong on the server.

  3. 03

    Validate delivery

    Test version pairing, interface permissions, emergency disable, and rollback.

Questions customers often ask

View all articles

Questions before purchase

Is a model safe after file encryption?

No. The model must be used at runtime, while inputs, outputs, memory material, interfaces, and credentials remain exposed to separate risks.

Can an API key be stored in a mobile app?

Do not treat a long-lived high-privilege key as a client secret. Prefer a server proxy with least privilege, rotation, and request records.

Must all AI inference run on a server?

No. On-device inference can reduce latency and improve privacy, but it adds model delivery, version, device resource, and runtime material concerns.

When is an AI protection claim verified?

Only when the candidate version, method, covered scenarios, and open items are explicit. Design work or static observation is not runtime verification.

Security standards and platform references

  1. Apple Core ML

    On-device model integration and runtime boundaries

  2. Google AI Edge LiteRT

    On-device inference runtime and model delivery context

  3. OWASP MASVS

    Mobile application security controls and verification scope

  4. Android security best practices

    Android application security design and release boundaries

  5. Apple Platform Security

    Apple platform code signing and runtime security context