Production Access 
Who Can Touch the Database at 2am 

Ask a growth-stage engineering team who can connect to the production database and the answer is usually a slightly uncomfortable version of 'everyone who needs to.' In practice that means every backend engineer holds credentials with read and write access to every customer's data, indefinitely, because at some point each of them needed it to debug something at an awkward hour. It is an entirely rational arrangement — it was the fastest path to a working on-call rotation — and it is also the control that enterprise security reviews probe hardest, that auditors write up, and that turns a stolen laptop or a compromised session into a company-ending incident rather than an inconvenience.

Why standing access is the specific problem

The risk is not that your engineers are untrustworthy. It is that permanent credentials are permanently available to whoever ends up holding them, and the set of people holding them grows monotonically. An engineer who left eight months ago may still be in a group that grants database access, because offboarding removed the SSO account but not the group membership on a bastion host nobody has audited. A laptop compromised through a malicious npm package inherits every credential in that engineer's shell history and config files. A phished session token gives an attacker exactly what the engineer had, which is everything. And in each of those scenarios the blast radius is defined entirely by what access was standing at the moment of compromise, which is why reducing standing access is worth more than almost any detection control you could buy instead. The second problem is evidentiary: with permanent shared access, you frequently cannot reconstruct who did a given thing. When a support ticket asks why a customer's records changed on Tuesday, 'one of eleven people using the same database role' is not an answer that survives contact with an enterprise customer.

What just-in-time access looks like

• Nobody holds standing write access to production data. The baseline for every engineer is no access, not read-only-by-default.
• Access is requested for a stated reason, tied to a ticket or incident, and granted for a bounded window — thirty minutes to a few hours — after which it expires automatically rather than requiring someone to remember to revoke it.
• Approval is proportionate: read access to non-sensitive tables during an active incident can be self-service with notification, while write access or access to sensitive data requires a second person.
• Every grant and every session is logged to a store the requester cannot modify, with the reason attached.
• Sessions are attributable to a human identity, never a shared role. If the underlying database role is shared, the proxy in front of it must record who was using it.
• The path is fast. If requesting access takes longer than the thing the engineer is trying to fix, they will build a shortcut around it and you will have a policy that exists only on paper.

Break-glass, and the failure you are actually designing for

Every access system needs an emergency path, and the mistake teams make is designing it for convenience rather than for the scenario that justifies it. Break-glass exists for the case where the normal path is unavailable — your SSO provider is down, the approval tool is part of the outage, or the incident is severe enough that waiting for an approver is the wrong trade. That means the emergency credential cannot depend on the systems it is meant to survive: an admin account that requires your identity provider to authenticate is not a break-glass account. The controls that make it safe are procedural rather than technical. The credential is stored somewhere retrievable under pressure but not casually — a sealed entry in a password manager with its own access list, or a physical safe for the genuinely paranoid. Its use triggers an immediate, loud, un-suppressable alert to security and engineering leadership, so that using it is impossible to do quietly. Every use is reviewed afterwards as a matter of routine and not as an accusation. And it is rotated after every use, which also gives you a natural test: if the credential has never been exercised, you do not know whether it works, so exercise it deliberately once a quarter.

Support impersonation and the consent question

The other door into customer data is the one your product provides on purpose. Support engineers viewing a customer's account as the customer sees it is genuinely valuable, and it is also the most sensitive capability in most SaaS products, because it is used routinely by the least-monitored part of the organisation. Three rules make it defensible. Impersonation must be attributed to the support engineer and not to the impersonated user, in both your audit log and the customer's — an audit trail that records a customer performing an action they did not perform is worse than no trail at all. It should be scoped and time-boxed rather than a persistent mode someone forgets they are in, with a visible banner that makes the state obvious. And increasingly, enterprise buyers expect consent: either a per-session customer approval, or at minimum a setting that lets the customer require it and a log they can read themselves. That last item shows up in security questionnaires more often each year, and having a real answer to it is a modest engineering cost that removes a recurring objection from your sales cycle.

What auditors and enterprise buyers actually ask

The questions are more specific than teams expect, and they are largely about evidence rather than intent. Who has production access today, and can you produce that list from the system rather than from memory. How is access granted and by whom. How quickly is it revoked when someone changes role or leaves, and can you show the revocation for the last three departures. Is access reviewed periodically, with a record of the review. Can you show every privileged session in the last quarter with the identity behind it. Is there separation between the people who write code and the people who can approve changes to production. Notice that a team with just-in-time access answers all of these almost for free, because the system produces the evidence as a by-product of doing the work, while a team with standing access has to manufacture answers by hand every audit cycle. That is the underrated argument for making this change: it is not only a security improvement, it converts a recurring compliance chore into an export. If you are heading toward SOC 2 or already answering enterprise questionnaires, access control is the area where the effort compounds most.

Rolling it out without slowing the team down

The failure mode of this project is a security team that ships a policy and an engineering team that routes around it, so sequence matters. Start by measuring: log every production access for a month before changing anything, and you will typically find that access is far less frequent than the debate assumes — often a handful of sessions per week concentrated in two or three people. That number is what makes the change politically possible. Then remove standing access in the order of exposure: write access to customer data first, then read access to sensitive tables, then everything else, leaving read-only access to non-sensitive operational data available for as long as you need to keep goodwill. Build the request path before you close the old one, and hold it to a hard latency target — a slash command or CLI that grants access in under a minute is the difference between adoption and mutiny. Improve the alternatives at the same time, because most production access requests are really requests for information: better observability, a read-only analytics replica, and a support tool that answers the ten most common questions will eliminate more access than any policy. Expect to keep a documented exception or two, and write them down rather than pretending they do not exist.

How Infiniti Tech Partners approaches this

This is a piece of work we are usually asked for under external pressure — an enterprise deal with a security review attached, a first SOC 2 audit, or a near-miss that made the current arrangement feel less comfortable than it did. The engagement is short and the sequence above is roughly what we run: instrument first so the conversation is about real usage rather than fears, then remove standing access in exposure order behind a request path fast enough that engineers prefer it. In most codebases the technical work is smaller than the organisational work, and much of it is plumbing an existing identity provider into a proxy that can attribute sessions to humans and expire them on a timer. We pay particular attention to the two things that are hard to retrofit later: attribution in the audit log and a support impersonation path with real consent semantics. And we deliberately leave behind the evidence exports, because the point is that your next security questionnaire is answered from the system rather than from a spreadsheet somebody maintains by hand. If you have a questionnaire open on your desk asking who can reach production, that is usually the right week to start.