Introduction

If you’re building an HR screening workflow with an AI interviewer, you’ll usually end up with two separate trust boundaries:

• your application servers, which can safely hold long-lived secrets

• the browser or client app, which should never see those secrets

The core problem is simple: an avatar API needs authentication, but an HR workflow often spans server-side orchestration, short-lived sessions, and a web UI where candidates join a live interview. If you expose a provider key to the browser, you’ve created an easy way to leak it, overuse it, or abuse it outside the intended workflow.

In this post, you’ll learn how to store AI avatar API keys safely in Python, proxy avatar/session calls through your backend, and structure an HR screening flow so the browser only receives ephemeral session data, not credentials. I’ll also show where a realtime avatar platform like Protoface fits into that architecture.

Start with the right secret model

For HR screening, treat the avatar provider key like any other production secret: it belongs in server-side secret storage, never in frontend code, and never in logs. The backend should be the only component allowed to call the provider’s authenticated REST API.

A practical storage pattern in Python looks like this:

import os

PROTOFACE_API_KEY = os.environ["PROTOFACE_API_KEY"]

import os

PROTOFACE_API_KEY = os.environ["PROTOFACE_API_KEY"]

import os

PROTOFACE_API_KEY = os.environ["PROTOFACE_API_KEY"]

In production, that environment variable should come from your secret manager, container runtime, or deployment platform—not a checked-in .env file. The important part is that your app process can read the key, but the browser cannot.

For a screening workflow, you usually need three kinds of data:

1. Server-side credentials for creating avatars, sessions, or issuing other privileged API requests.

2. Ephemeral session identifiers that a candidate’s browser can use to join a live interaction.

3. Workflow state such as candidate ID, interview stage, scoring state, and transcript references.

Only the first category is secret. The other two are application data and should be scoped, time-limited, and validated on your backend.

Proxy all privileged API calls through Python

The safest pattern is to build a small backend proxy that exposes only the operations your app needs. The browser asks your server to start an interview; your server authenticates the user, creates the avatar session with the provider, and returns only the session details required to connect.

That proxy can be as small as a FastAPI endpoint or a Flask route. The key design rule is: do not forward the provider key to the frontend, and do not let the frontend pass arbitrary provider parameters without validation.

import os

}

import os

}

import os

}

The exact request shape depends on the API surface you use; the point here is the boundary. Your app should translate your own domain model into provider calls, not expose provider auth directly to the browser.

Make the browser session short-lived and narrowly scoped

In HR screening, a candidate session should expire quickly and be usable only for the intended interview. That reduces risk if the URL leaks and makes replay attacks less useful.

A good pattern is:

• authenticate the candidate against your own system first

• create the avatar session on your backend

• store the provider session ID against your interview record

• return only the minimal connection artifact to the browser

That connection artifact might be a session token, a signed join URL, or another short-lived value depending on the provider and transport. The browser should not be able to mint new sessions or change avatar behavior beyond what you explicitly allow.

Also keep the server authoritative for interview policy. For example:

• only permit one active session per candidate at a time

• bind a session to a specific interview template or role

• record start/end timestamps and usage for auditability

• reject attempts to reuse stale session identifiers

This matters even more for HR workflows, where you often need logs, transcript retention, and reviewability. The proxy layer is where those controls belong.

Use Python SDKs for control-plane logic, not client-side auth

If your backend needs to manage avatars or sessions programmatically, a Python SDK can keep that code cleaner than raw HTTP calls. The architectural rule is unchanged: use the SDK only on the server.

import os

)

import os

)

import os

)

That’s useful when your screening workflow needs to create different avatar configurations per job family or region. For example, you might create one avatar profile for engineering interviews and another for customer support screening, each with different prompts, voices, and evaluation criteria.

Keep the SDK on the server side even if your application is otherwise “Python all the way down.” The moment you place a privileged client in the browser, you’ve lost the security boundary.

What to proxy versus what to pass through

The most common mistake is overexposing API surface area. A backend proxy should be selective.

Proxy these:

• session creation and teardown

• avatar creation and updates

• template selection and prompt assembly

• usage accounting and audit logging

Do not proxy raw credentials, and do not let clients supply unrestricted provider fields. In practice, that means the frontend might request “start interview for candidate 123,” while the backend decides:

• which avatar template to use

• which voice and instructions are allowed

• how long the session remains valid

• what rate limits apply

For HR, this also helps with compliance. If you need consistent screening questions, a controlled prompt assembly step in the backend is far safer than letting the browser construct arbitrary instructions.

Where Protoface fits in a realtime screening flow

Protoface is a good fit when the interview needs a synchronized talking face attached to a voice agent or conversational video workflow. The key implementation detail is that you still keep the API key server-side and use the authenticated REST API or Python SDK from your backend.

In other words, your Python service can create the session, store the secret key securely, and then hand the browser only the short-lived connection data needed to join the realtime experience. That keeps the avatar interaction WebRTC-friendly and interactive without turning the frontend into a credential store.

If you’re integrating a voice agent rather than a browser-only flow, the LiveKit plugin path is also relevant: the avatar becomes part of the agent pipeline, which is still controlled from your server process. The plugin repo has examples worth skimming if you’re already using LiveKit agents: quickstart examples and the main documentation are the right places to check for exact setup details.

Practical hardening tips for HR workloads

A few additional controls are worth implementing because HR workflows tend to be long-lived and audit-sensitive:

• Rotate keys regularly and support key rollover without downtime.

• Separate environments so staging interviews never use production credentials.

• Log by session ID, not by secret; never print bearer tokens or API keys.

• Apply rate limits to your own session-start endpoint to prevent abuse.

• Validate callback/webhook sources if you ingest events from the avatar platform.

Also make sure your failure mode is explicit. If session creation fails, return a normal application error and let the candidate retry or reschedule. Do not surface raw provider errors to the browser unless they’re sanitized and safe to expose.

Conclusion

The secure pattern is straightforward: store the avatar API key in server-side secret storage, call the provider from Python, and proxy only short-lived session artifacts to the browser. For HR screening, that gives you a clean boundary between private control-plane credentials and candidate-facing realtime interaction.

If you need to build this out, start with your own backend session endpoint, then wire it to your avatar provider, and finally connect the browser to the ephemeral session data. The docs at docs.protoface.com cover the available surfaces and exact request shapes. From there, you can adapt the same pattern to voice agents, support bots, or any other realtime avatar workflow without exposing secrets to the client.