The product holds vendor keys, channel passwords and a log of calls inside itself, so security deserves attention. Collected here: what is already done in the product itself, and what has to be done on the server side and in the team’s habits.
The administrator account
There is one administrator, set with environment variables — so an “extra” user cannot be created, even by accident. The password is stored not as text but as its irreversible hash (SHA-256, written lowercase). A sign-in lasts 90 days — until then, the password does not need to be entered again.
Signing out closes the session only in the browser you signed out of. To end sessions everywhere, change the session signing key (an environment variable) or recreate the container without a persistent key: after that, every issued sign-in stops working.
Where secrets are stored
- Vendor keys and channel passwords live not in the database but in the configuration folder’s files (by default
/project/apps/proxy) —models.ymlandhttp-providers.yml; the Happ subscription link sits there too. In the interface and over the management API these secrets show as a mask: saving is possible, reading back is not. - Instead of the secret itself, the file can hold an environment-variable reference like
$VARIABLE_NAME. The secret is then substituted at the moment of use and never lies in the file at all. - Secrets can be kept in one
.envfile next to the project (by default/project/.env; the path is changed withPROXYAGENT_ENV_FILE). Real environment variables always take priority over the file; the file itself belongs in.gitignore. - The configuration folder’s permissions matter no less than the database’s: the whole configuration, secrets included, lives there now. Protect the folder and include it in backups.
- Access keys are stored only as a fingerprint and the last 8 characters. The ready key is shown once, and restoring it from the database is impossible.
- Secrets in secret-hiding are masked in the leak reports and kept for a limited time.
What is not in the log
Request and response texts are never stored — that is a matter of principle. So even full access to the database will not show what you talked about with the models: only the time, the model, the key, the volume, the cost and the errors are there.
Who can call from a browser
External calls into the interface are allowed only from the same address the product is opened on. That means a third-party site cannot quietly reach your proxy from your employee’s browser: the browser itself blocks such a request. Separately from that, the /api/* addresses are open for programs — they are protected by access keys and pass requests only with a valid license.
Management over the API
Everything the administrator does in the browser can also be done by a program — at the /api/agent/* addresses. That is convenient when another agent or your script manages the product: create models and channels, maintain access keys, read the logs and analytics, change settings and secret-hiding rules.
Access is closed by the management key. The key is set with the PROXYAGENT_API_KEY environment variable and passed in the X-API-Key header. The variable stores not the key itself but its irreversible hash (SHA-256, written lowercase) — so the key cannot be recovered from the variables file. When the variable is not set, the surface answers “disabled” (503). The list of everything available is returned by the product itself at GET /api/agent: that is its only documentation.
The management key deserves secrecy — it opens everything the administrator sign-in opens. It does not replace the administrator’s password though: an ordinary browser login cannot be opened with it, only a one-time sign-in code. The license does not gate this surface — management works without a license key as well, while the secrets stay closed: models, channels and access keys show the same masks as in the interface.
Details are in the Management API section.
What is worth doing before going online
- Set up HTTPS — so the password and the keys do not travel as plain text.
- Run a dedicated database with its own password — do not share one with other programs.
- Protect and back up the configuration folder — the whole configuration and the secrets live in it. Its permissions matter no less than the database’s. If the secrets sit in a
.envfile, protect and never commit that too: it holds the vendor keys, the license and the management key. - Sort out the proxy service ports. Every channel now has its own port — there are as many as channels you exposed. Publish only the needed ones, keep the rest behind the firewall, and turn on sign-in checks for the published ones. With the check off, anyone who reaches the port can relay traffic through your server — the product warns about this in the channel editor.
- Set the license key. Without a valid key no traffic passes through the proxy: the interface, the chat and the health check work, but requests to the models and ordinary traffic do not. That is expected behavior, not a breakage.
- Issue a separate access key to every person and contractor — with a spending limit and a model list. Then revoking access never touches the others.
- Dump the database regularly — both protection from losing history and a way to understand what is happening.
What is honestly not protected
- A stolen access key works until revoked. The product does not know who holds a key — it only checks the key itself. So revoke keys as soon as a person or contractor leaves.
- The administrator sees everything. Settings, keys as masks, logs and spending are fully available. There is one account — rights cannot be split between people.
- The server is outside the product. Protecting the server itself, the database, the configuration folder and the firewall remains yours: the product does not replace that and does not configure it.
This is the last page of the documentation. The list of sections is in the documentation index, and the overall picture of the product is on the Proxy Agent page.