AIProxy is an AI access security service for iOS app developers, with the core goal of protecting the AI API keys and endpoints that apps depend on. The material states that if an app communicates directly with AI providers such as OpenAI and Anthropic, the provider API key is very likely to be stolen; anything distributed with the app or loaded at runtime can be observed and stolen. Once a key is leaked, attackers can incur charges continuously before the user notices and rotates the key. AIProxy solves this problem through a hosted proxy.
The main capabilities include security, observability, and control. It combines split-key encryption, DeviceCheck, and certificate pinning to prevent key and endpoint theft or abuse. Rate limiting prevents endpoint abuse; requests are rejected when the threshold set in the rate limit builder is exceeded. The dashboard helps users monitor usage and gain insight into how users interact with AI in the app. The model override feature allows different models to be changed or tested directly from the dashboard without updating the app. The real-time console can be used to test API calls from the app, discover errors, and understand performance. Suspicious activity alerts allow users to take action quickly. The material also mentions support for bring-your-own-key, configuring AIProxy to send requests directly to the providers it supports, allowing users to choose to use their own keys.
In terms of usage, AIProxy provides the Swift client library AIProxySwift, which supports more than 15 different AI providers, making it easy to integrate into apps. The material provides integration steps: add the AIProxySwift package (https://github.com/lzell/AIProxySwift）。在开发者仪表盘中配置项目后，会获得初始化代码，用于放入 the AIProxySwift client. The material says the Swift client can be integrated in minutes.
Regarding the key protection mechanism, the material explains that AIProxy actually does not store any customer API keys. It encrypts the key and stores one part of the encrypted result in the database; that part alone cannot reconstruct the key; the other part of the encrypted result is sent with app requests. Only when the two parts are combined can the key be derived and the request completed. The key provided to the user is itself useless and can be hardcoded in the client. When adding an OpenAI key in the dashboard, it is not stored in the backend; after encryption, only half is stored, and the other half is given to the user for the client, and at request time the two parts are merged and decrypted.
Endpoint anti-abuse mechanisms include: 1. Users can configure proxy rules to enable only the endpoints the app depends on, for example allowing only /v1/chat/completions and blocking other endpoints, reducing their attractiveness to attackers. 2. Use Apple's DeviceCheck service to ensure requests come from apps running on legitimate Apple hardware. 3. Ensure DeviceCheck tokens are used only once, preventing attackers from replaying tokens sniffed from the network.
In terms of infrastructure, the proxy is deployed on AWS Lambda and can easily scale horizontally behind a load balancer, so users can be confident that the proxy will keep running. The applicable scenario is mainly iOS app developers who want secure access to multiple AI providers, protect API keys, control endpoint abuse, and monitor usage. In terms of limitations, the material does not provide information such as pricing, charging model, the complete list of all supported providers, support for non-iOS platforms, or detailed terms of service.
