Secrets management basics: API keys, rotation and keeping credentials out of code

Secrets management is not glamorous, and most small companies postpone it until something goes wrong. That is a mistake, because a leaked API key is among the most common and most avoidable security incidents there is. A key pasted into a chat, committed to a repository, or bundled into a website's JavaScript can be copied in seconds and misused for months.

At Oryvelon we run several independent companies on shared infrastructure. Shared infrastructure only works if credentials stay strictly separate, so secrets management is a group-wide standard rather than something each team improvises. This article covers the basics we apply everywhere: what counts as a secret, why keys stay server-side, why every company and environment gets its own, how rotation works, and the rules that keep secrets out of repositories and conversations.

What counts as a secret

A secret is any value that grants access to something. If someone who had the value could read data, spend money, send messages or impersonate a system, it is a secret.

Typical secrets in a small digital company include:

• API keys for model providers, payment processors, email platforms and other services
• Database connection strings and passwords
• Access tokens for platforms such as Shopify apps, advertising accounts and analytics APIs
• Webhook signing secrets
• Session and token signing keys
• Encryption keys
• Cloud storage credentials
• SSH keys and deploy keys
• Recovery codes for important accounts

Some values look harmless but are not. A "test" key for a payment provider may still expose account details. A read-only analytics token may still reveal revenue. When in doubt, treat it as a secret.

It helps to think of secrets as physical keys. You would not photocopy the office key and leave copies on desks, send a photo of it in a group chat, or tape it to the front door. Most secrets leaks are the digital version of one of those three things.

Rule one: secrets stay on the server

Anything shipped to a browser or a mobile app can be read by anyone who uses it. Minified JavaScript is not hiding anything; browser developer tools show every network request and every bundled value.

So the first rule is simple: keys that grant access to paid services or private data never leave the server. If the frontend needs something that requires a key, it calls our own server, and the server makes the call with the key.

This matters especially for AI features. A model provider key embedded in a web page can be extracted and used to run someone else's workloads at our expense. At Oryvelon, every AI call goes through our AI gateway on the server side. The gateway holds the provider keys, enforces per-company budgets, applies safety hooks and logs usage. The browser never sees a provider key, and a product cannot spend another product's budget. We explain why that budget control matters in Cost discipline for AI products.

Some keys are designed to be public — a publishable payment key, a site key for a bot check, a public analytics measurement ID. These are fine in frontend code because the provider expects them to be visible and restricts what they can do. Read the provider's documentation; if it does not say a key is safe to publish, assume it is not.

Rule two: separate secrets per company

Oryvelon's companies share tooling, patterns and some infrastructure. They do not share credentials.

MerchNivo has its own database credentials, its own model provider keys, its own email platform account and its own storage keys. So do CastLyra, KeşifAtlası, EduRelia and every other company. There is no group-wide key that opens several companies' data.

The reasons are practical:

• Blast radius. If one company's key leaks, one company is affected. The incident does not become a group-wide one.
• Independence. A company that can stand alone must be able to take its credentials with it if it is sold or spun out, without breaking anyone else.
• Clear costs. Per-company keys make it easy to see what each company spends on each provider, which feeds straight into unit economics per product.
• Data boundaries. Separate credentials are one of the mechanical guarantees behind shared infrastructure, separate data and tenant isolation.

The same applies to third parties we connect. A merchant who installs MerchNivo grants a Shopify access token for their store. That token is stored for that store only, used only for that store's features, and removed when the merchant uninstalls.

Rule three: separate secrets per environment

Every company runs several environments: local development, preview builds, staging and production. We describe the setup in Environments and test data. Each environment gets its own secrets.

The point is that a non-production key should be useless against production. If a developer's laptop is lost, or a preview build leaks its configuration, the attacker gets access to synthetic data and test-mode services. Nothing real.

This also prevents a quieter class of mistakes: a script run locally that was meant for test data but was pointing at production because someone copied the live connection string "just to check something".

Where secrets should live

Secrets need a home that is access-controlled, auditable and separate from code. For a small team, that usually means two places.

A secrets store or the hosting platform's encrypted environment configuration for application secrets. The application reads secrets at runtime from the environment. Access to view or change them is limited to the people who deploy that company's systems.

A team password manager for human credentials: dashboard logins, registrar accounts, recovery codes. Each company has its own vault or collection, shared only with the relevant roles.

Where secrets should never live:

• In the code repository, including private repositories and "temporary" config files
• In chat messages, direct messages or group channels
• In tickets, task descriptions or project documents
• In emails
• In screenshots and screen recordings
• In AI assistant conversations
• In spreadsheets
• In logs and error reports

Private repositories and private channels are not safe places. They are copied, forked, backed up, searched and connected to other tools. Former team members and connected apps may still have access. A secret in a chat history is a secret in every device and integration that has synced that history.

Keeping secrets out of repositories

Accidental commits are the classic leak. A few habits prevent most of them.

1. Use an example config file (for instance a .env.example) that lists the required variable names with placeholder values, and keep the real file out of version control with an ignore rule.
2. Turn on secret scanning in the code host and, ideally, a pre-commit hook that blocks commits containing strings that look like keys.
3. Never "fix it in the next commit". Once a secret is committed, it is in the history. Removing it later does not remove it from clones, forks or caches. The secret must be rotated.
4. Review diffs before pushing, especially configuration changes.
5. Keep build logs clean. CI output should mask secret values, and build steps should not print the environment.

Scoping: give each key the least it needs

Least privilege applies to keys as much as to people; see Least-privilege access for small teams.

• Use restricted keys where providers offer them. A key that only needs to read orders should not be able to create refunds. A key for sending transactional email should not manage the account.
• One key per integration. If the website, the support tool and a nightly job all need the same provider, give each its own key. When one leaks or is retired, the others keep working.
• Set limits. Where providers support spending caps, rate limits, IP restrictions or allowed domains, use them. A model provider key with a monthly cap turns a leak from a large bill into a small one.
• Give every key an owner and a description. "Created by whom, for what, in which company and environment" should be answerable for every secret.

Rotation

Rotation means replacing a secret with a new one and retiring the old one. Keys should be rotated:

• On a schedule, so that any silent leak has a limited lifetime.
• When someone with access leaves, especially if they could have seen the value.
• Immediately after any suspected exposure.
• When a vendor or integration is retired.

Rotation is painless only if it is designed in. That means applications read secrets from configuration rather than hard-coding them, deployments can pick up new values without code changes, and — where the provider allows — two keys can be valid at once during the switchover so there is no downtime.

We track rotation in the same inventory as ownership. The quarterly tool review and the quarterly access review are natural moments to check for keys that are overdue, unused or unowned.

When a key leaks: a short runbook

Leaks happen. What matters is how quickly the key stops working. Our runbook is short on purpose.

1. Revoke or rotate the key now. Do not wait to investigate first. A revoked key cannot be misused further.
2. Deploy the replacement to the systems that legitimately need it.
3. Check the provider's logs for unexpected use since the likely exposure time: unusual volume, unknown IP addresses, unexpected resources.
4. Remove the value from where it appeared — the message, the commit history, the ticket — understanding that this is cleanup, not protection.
5. Assess impact. Did the key expose personal data? If so, follow the company's incident process, which may include notification obligations under the applicable law.
6. Fix the cause. Why was the key there? Add the scanner, change the process, update the checklist.
7. Write it down. A brief note of what happened and what changed.

The single most important instruction is the first: revoke before you investigate.

Keep a secrets inventory

You cannot rotate, scope or revoke what you do not know exists. Every Oryvelon company keeps a simple inventory of its secrets. It does not contain the values themselves — those stay in the secrets store — only the facts about each one.

A spreadsheet is enough for a small company, provided it holds no secret values. The inventory turns a leak from a scramble ("where else do we use this?") into a checklist, and it makes the quarterly review fast.

Secrets in local development

Developers need credentials to run software locally, and this is where good intentions often slip. The safest pattern is that local development only ever uses local or test-mode secrets: a local database, sandbox keys for payment and email providers, a low-limit development key for model providers.

Developers should never need production secrets on their machines. If a bug only reproduces in production, the fix is better logging, a reproduction with synthetic data in staging, or a controlled break-glass session — not a copy of the live environment file on a laptop. Laptops are lost, synced to personal cloud storage and shared with other software far more often than servers are.

Secrets and AI assistants

AI coding assistants and chat tools have become a new route for secrets to leak. A developer pastes an error message that includes a connection string. Someone asks an assistant to "fix this config" and includes the whole environment file. An assistant with access to a repository reads a committed key and repeats it in an answer.

Our rules: do not paste secrets into AI tools, redact configuration before sharing it, and treat any secret that has been pasted into an external tool as exposed and due for rotation. Connected assistants get the narrowest access that works, as with any other integration.

Webhooks and inbound secrets

Secrets management is not only about keys we use to call others. It also covers secrets that let us trust incoming requests.

Webhooks — notifications that a platform sends to our server when something happens, such as an order being created or a payment succeeding — usually come with a signing secret. Our server should verify that signature before acting on the request. Without it, anyone who discovers the webhook URL can send fake events.

For MerchNivo, that means verifying that a webhook genuinely comes from Shopify for a specific store before it updates that store's signals. For Noveniq, it means payment notifications are verified before an order is marked as paid. Verified inputs are part of the same principle we apply to AI: decisions come from data we can trust, as described in AI explains, verified data decides.

A worked example: adding a model provider to a new company

Imagine KeşifAtlası is adding an AI explanation feature to its eligibility reports. Here is how secrets management shapes the work.

The company creates its own account with the model provider — not a shared group account — and generates separate keys for staging and production. Each key is restricted to the capabilities the feature needs and given a spending limit that matches the company's budget. The keys are stored in the company's environment configuration and registered with the AI gateway under KeşifAtlası's configuration, alongside the prompt versions and budgets for that company.

The frontend calls KeşifAtlası's own server, which calls the gateway, which calls the provider. The browser never sees a provider key. Staging uses the staging key against synthetic applicant profiles. Production uses the production key.

The inventory records both keys: owner, purpose, environment, creation date, rotation due date. At the next quarterly review, someone checks they are still in use and not overdue.

None of this takes long. It just has to be the default rather than an afterthought.

Common mistakes

• Putting a model provider key in frontend code "for the prototype" and forgetting it is there at launch.
• Using one production key across several products because it was quicker to set up.
• Sharing the production database password in a chat so a colleague can "quickly check something".
• Copying the production environment file to a laptop to reproduce a bug.
• Keys created under a personal account that nobody else can manage.
• No spending limits on usage-billed services.
• Deleting a leaked secret from a commit or message and considering the problem solved.

Summary

Secrets management basics come down to a handful of firm rules. Treat every credential that grants access as a secret. Keep keys that open paid services or private data on the server, never in browsers, apps, repositories, tickets, chat or AI conversations. Give each company and each environment its own secrets so a leak stays small, scope every key to the least it needs, give it an owner and limits, rotate it on a schedule and after any exposure, and revoke first when something leaks. At Oryvelon these rules are group-wide because they are what make shared infrastructure safe: the tools are shared, the credentials never are.

Questions and answers

What is secrets management?

Secrets management is the practice of storing, distributing, scoping, rotating and revoking credentials such as API keys, database passwords and tokens so that only the right systems can use them. It covers where secrets live, who can read them and what happens when one leaks.

Can API keys be stored in frontend code?

Keys that grant access to paid services or private data should never be placed in frontend code, mobile apps or anything a user can download, because anyone can extract them. Calls that need such keys should go through your own server.

What should you do if an API key is leaked?

Revoke or rotate the key immediately, deploy the replacement, then check the provider's logs for misuse and remove the leaked value from wherever it appeared. Deleting a message or commit alone is not enough, because copies may already exist.

Published by Oryvelon, a digital company builder · About the group · Our companies · More in Data, Privacy & Security

NextEnvironments and test data: local, preview, staging and production without real personal data →