Secrets, keys and access: least privilege in practice for a startup

Least privilege means every person, service, and key gets only the access it needs, and nothing more. In a startup it is less about policy documents and more about a handful of habits you set up early, while the team is small and the list is short.

Why it matters early

Access grows quietly. A contractor gets admin rights for one task and keeps them. A database password is pasted into a chat to unblock a deploy. A single API key with full permissions ends up in three services and a laptop.

None of these feel dangerous on the day they happen. Together they mean that one leaked credential or one compromised account can reach everything. Least privilege limits how far a single mistake can travel.

It is also much easier to start tidy than to clean up later, when nobody remembers why a key exists or what breaks if it is removed.

Start with an inventory

You cannot limit access you cannot see. Make a simple list, a spreadsheet is fine:

1. People: everyone with access to your code host, cloud account, database, domain registrar, email, payment dashboard, and analytics.
2. Services: each app, job, or integration, and what it connects to.
3. Secrets: every API key, token, password, and signing key, with where it is stored and who can read it.

For each line, write down what access it has and what access it actually needs. The gap between those two columns is your to-do list.

Secrets: where they live

The rule is simple: secrets never live in code.

• Keep them in your hosting platform's encrypted environment settings or a dedicated secrets manager.
• For local development, use a local file such as .env that is listed in .gitignore, and commit only an example file with placeholder values.
• Never paste secrets into chat, tickets, or documents. Share them through the secrets tool, or not at all.
• Use separate keys for development, staging, and production, so a leaked development key cannot touch real data.
• Know how to rotate each one. If a key leaks, you should be able to replace it without a scramble.

Run a secret scanner on your repository and in your pipeline. It catches the honest mistakes before they are pushed.

Tip: if a secret has ever been committed, treat it as exposed. Rotate it first, then clean up the history.

People and services

People: accounts and roles

• One account per person. No shared logins, so you know who did what and can remove one person without resetting everything.
• Multi-factor authentication everywhere it is offered, starting with email, code hosting, cloud, and the domain registrar.
• Admin is a separate role. Day-to-day work uses a normal account; admin rights are used deliberately.
• Time-limited access for contractors and one-off tasks, with an end date written down.
• An offboarding checklist that walks the inventory and removes access the same day someone leaves.

Services: scoped keys

Services deserve the same care as people.

• Give each service its own credentials, so you can see and revoke them individually.
• Scope tokens to the actions they need: a reporting job gets a read-only database user, a webhook handler can write to one table, not all of them.
• Prefer short-lived credentials where your platform supports them, over long-lived keys.
• Restrict network access so the database accepts connections only from the services that use it.

A short, regular review

Put a recurring review in the calendar. Walk the inventory and ask three questions for each line: is this still needed, is the access still the minimum, and when was this secret last rotated? Remove anything nobody can explain.

This pairs naturally with a threat model: the threat model tells you what matters most, and the review keeps access to it tight.

Where to start

Build the inventory this week, turn on multi-factor authentication for every shared tool, and move any secret that lives in code into proper storage. If you want help auditing access or setting up secrets handling in your pipeline, that is part of our secure backend engineering work, and you can reach us here.