How AI-Built Apps Can Use AI APIs Without Exposing Provider Keys

The fastest AI integration is often the unsafe one

A developer asks a coding agent to add an AI feature. The agent creates an input, calls a model API, and displays the response. Within minutes, the feature appears to work.

Then someone asks where the provider key is stored.

If the answer is “inside the app,” the integration is not ready for release. Browser JavaScript is delivered to the user. Mobile applications are distributed to devices outside the developer’s control. Build-time variables can still become literal values inside compiled client bundles. Obscuring a key changes how it looks, not who can recover it.

OpenAI’s own API key guidance is direct: keys should not be deployed in client-side environments such as browsers or mobile applications, and requests should be routed through a backend where the key can remain secure (OpenAI API key safety guidance). The same architectural principle applies to other provider credentials.

The correct lesson for AI-assisted development is not “do not let an agent add AI.” It is “give the agent a safe server-side path for adding AI.”

Why a client application cannot keep a provider key secret

A secret is only secret while it remains inside a boundary the end user cannot inspect.

Client applications do not provide that boundary. A user may be able to inspect network requests, downloaded JavaScript, application resources, runtime memory, or compiled binaries. Even when extraction requires effort, a provider key with financial or data access is too valuable to rely on inconvenience as protection.

An exposed key may allow someone to:

• make requests billed to the developer’s account;
• exhaust usage limits and interrupt the application;
• use models or endpoints the product did not intend to expose;
• obscure abusive requests behind the developer’s credentials;
• force emergency key rotation and application updates.

The problem becomes more likely in generated code because an AI coding agent is often optimizing for a working demonstration. If the available context contains a provider key and a client-side API example, the shortest implementation path may place the key exactly where it should not go.

The developer needs to make the security boundary explicit.

The secure request pattern

Zeple uses a server-side proxy pattern:

Developer provides the AI provider key
                    ↓
         Zeple stores it server-side
                    ↓
Coding agent connects the app to Zeple
                    ↓
      User signs in to the application
                    ↓
Authenticated app request → Zeple → AI provider
                    ↓
          Response returns to the app

The provider key never needs to be included in the request sent by the client. It is not returned with the model response. The application identifies the user and the intended project request; Zeple supplies the provider credential within the server-side boundary.

This design separates two different credentials:

1. Application identity tells Zeple which signed-in user is making the request.
2. Provider identity tells the external AI platform which developer account is making the upstream request.

The client may carry an application session token. It must not carry the AI provider key.

What the developer controls

The human developer remains responsible for product and security decisions.

The developer chooses which AI capability belongs in the product, which provider account to use, and which user actions should be allowed to trigger requests. The developer also reviews the experience, controls the production release, and responds to unexpected usage.

This matters because a secure proxy is not permission to proxy every possible request. The product should expose a constrained operation that reflects its intended behavior. A summarization feature should accept the information needed for summarization; it should not automatically become a general-purpose tunnel to every provider endpoint.

Useful developer decisions include:

• which authenticated users may use the feature;
• which project or organization owns the request;
• which models or operations the product permits;
• what input size or frequency is reasonable;
• how failures and provider limits appear to users;
• when Development is ready to become Production.

What the coding agent implements

The coding agent translates those decisions into application code.

Agents such as Codex, Claude Code, or another development agent can add the client flow, collect the intended input, require the current application session, call the Zeple API, handle errors, and render the result. The agent can also write tests for signed-out requests, malformed inputs, and provider failures.

The agent should not receive the provider key as source-code context. It needs the Zeple project configuration and API contract, not the secret itself.

A good implementation instruction is specific:

Add an authenticated summary action using the Zeple AI proxy. Do not place a provider key in source code, build configuration, browser storage, or the client request. Test the integration in the Development environment.

That prompt communicates both the feature and its security constraint.

What Zeple operates

Zeple provides the server-side portion that the client should not own:

• storage for the developer’s provider credentials;
• authenticated receipt of application requests;
• project-scoped processing;
• upstream requests made from the server-side boundary;
• responses that do not reveal the stored key.

The coding agent builds the integration. Zeple protects the credential and performs the provider request at runtime.

This is the difference between using an AI coding agent to implement a backend integration and expecting the agent-generated client to be the backend.

Development and Production reduce release risk

Every Zeple project includes Development and Production environments.

The coding agent should initially connect the AI feature to Development. That is where the developer can validate:

• signed-in and signed-out behavior;
• allowed request shapes;
• error messages and retry behavior;
• user and project permission boundaries;
• the absence of credentials in client code and network payloads;
• the complete experience using non-production configuration.

Only after review should the released application use Production.

The two-environment workflow also makes instructions clearer. “Test this in Development” and “prepare this for Production” represent different decisions. The agent can help with both, but the developer decides when the boundary is crossed.

Environment separation does not remove the need for review. It gives the developer a safer place to perform it.

Common approaches that do not solve the problem

Putting the key in a client environment variable

Environment variable syntax does not guarantee server-side secrecy. If a variable is substituted into a client bundle, its value becomes part of the distributed application. The important question is not where the value started; it is whether the final browser or mobile build can access it.

Hiding the key behind a different variable name

Renaming OPENAI_API_KEY to an obscure identifier does not change the credential’s capabilities. An attacker does not need the original variable name if the value appears in code or a request.

Sending the key only over HTTPS

HTTPS protects data while it travels between endpoints. It does not protect a secret from the user who controls one endpoint. If the client must possess the key before sending it, HTTPS does not make that client a trusted secret store.

Relying on a private source repository

A private repository is useful, but it does not prevent a credential from being shipped inside the compiled application. OpenAI also advises against committing keys to source repositories and recommends rotation when compromise is suspected (OpenAI account security guidance).

Asking the coding agent to invent a proxy

Generated server code may be a starting point, but it creates a new security and operations responsibility. The developer must still deploy it, authenticate requests, scope access, store secrets, handle errors, and maintain it. Zeple provides a managed proxy path designed to avoid rebuilding those common responsibilities for each application.

Security review checklist

Before releasing an AI-powered application, verify:

• No provider key appears in client source code.
• No provider key appears in browser or mobile build output.
• No provider key is stored in browser storage.
• No provider key is sent from the client in a request.
• AI actions require the expected application identity.
• Requests are associated with the correct Zeple project.
• The client exposes only the product operations it needs.
• Error handling does not reveal credentials or sensitive upstream details.
• The integration has been tested in Development.
• The released build uses Production configuration.
• Usage and provider activity can be reviewed by the developer.
• A key can be rotated if compromise is suspected.

Security is strongest when these checks are part of the feature definition rather than a cleanup task before launch.

Add AI features, not AI secrets

AI coding agents can help developers add valuable model-powered experiences rapidly. They can create the interface, connect the authenticated request, handle the response, and test expected failures. What they should not do is turn a provider key into a client-side application constant.

Zeple gives the agent a safer integration target and gives the developer a server-side place for provider credentials and proxy requests. Development supports iteration; Production supports the released app.

The lasting rule is simple:

The developer controls the provider relationship. The coding agent builds the feature. Zeple keeps the provider credential on the server.