What is just-in-time access for developers?

Just-in-time access means a developer requests access when a task needs it, it gets approved, and the credentials expire on their own afterward. Nobody holds standing keys to production, so there is far less to misuse or forget to revoke.

Is read-only production access safe for developers?

Read-only is much safer than write access because it cannot delete or change anything, but it is not automatically safe. Production data often contains customer information, so read access should still be logged and, where the data is sensitive, masked.

How do you give developers production access without slowing them down?

Grant it on request rather than through a single human approver, keep the grant short-lived, and watch what the session does instead of blocking commands up front. That keeps developers moving while still catching a destructive action before it finishes.

← All posts

July 14, 2026 · Nick Krykunov

Should developers have access to production? An honest answer for small teams

Most developers need to read production and almost none need standing write access to it. That is the short answer. The longer answer is that the question is usually framed as a yes or no when the real decision is about how access is granted, for how long, and who is watching when it is used.

Why this is such a common fight

Almost every team lands in one of two camps, and both are miserable in their own way.

In the first, everyone has admin. It’s fast, nobody waits, and it works right up until a tired engineer runs the wrong command against the wrong environment. The most upvoted programming story of all time is a new hire who wiped the production database on their first day, and the top reply was not “fire them,” it was that a system where one person can do that is the thing that failed.

In the second camp, access is locked down and one person approves everything. Safer, but that person becomes a bottleneck, and developers start pinging them mid-meeting to unblock a deploy. Neither camp is really an answer, just two ways of coping.

So should developers have production access at all?

For reading, usually yes. Engineers can’t debug an incident they can’t see, and cutting them off entirely just means they escalate to the one person who can, which recreates the bottleneck.

For writing and deleting, the honest answer is that very few people need it standing, and the ones who think they do usually need it for a specific task, not forever. Palo Alto Networks’ Unit 42 has reported that around 99% of cloud identities are over-permissioned, which is a polite way of saying most of the write access sitting in your account is never used and only adds risk.

What actually works on a small team

The advice you will find elsewhere is sound but often assumes you have a platform team to build it: individual accounts instead of shared logins, the four-eyes principle where a second person approves sensitive changes, and just-in-time access so grants expire. All sound, and all hard to run by hand without a platform team.

The version that survives a team with no security hire is simpler. Stop handing out standing access, and make access something a developer requests for a task, which then expires on its own. That removes the permission nobody remembers granting, which is the one that tends to get abused. We wrote about how temporary access works in practice if you want the mechanics.

The part the debate almost always skips is what happens once someone is in. Access controls decide who gets in. They do nothing about what a legitimate session does next, and the person who deletes production almost always had legitimate access.

That is why the second half matters: watch the session, and stop a destructive one before the command finishes, whether the person behind it made a mistake, lost their key, handed it to a contractor, or is an AI agent acting on its own.

The pragmatic setup

Give read access to the people who need to debug, and log it. Keep write and delete access off by default, and grant it on request with a short expiry. Do not build a human approval queue that turns one person into the blocker. And put something in front of the actions themselves so a bad session gets caught, rather than trusting that everyone with access will always be careful.

That is the setup Korvalis is built for: temporary access so fewer sessions can do damage, and a guard on the session that catches the ones that turn destructive. It installs inside your own cloud account, with no proxy for your engineers to work around.

Frequently asked questions

Should developers have access to the production database? Most need to read it to debug. Very few need standing write access. Grant write access on request, scoped and expiring, rather than as permanent admin for the whole team.

What is just-in-time access? A developer requests access when a task needs it, it is approved, and the credentials expire on their own. Nobody holds standing keys, so there is far less to misuse or forget to revoke.

Is read-only access safe? Safer than write access, since it cannot change anything, but production data often holds customer information, so read access should still be logged and masked where the data is sensitive.

If access on a small team is the thing you quietly worry about, see how Korvalis handles it or join the waitlist.