Four environments, one rule
Development, test, acceptance and production are four separate environments, and the first three run on anonymised data and databases. Our developers and engineers work there. Production is reached only by the people who need it for operations, on a need-to-know basis, and that is a short list. The rule is the same in Rotterdam as in Novi Sad and Belgrade: where a developer sits has nothing to do with what they can see.
We set this up years ago, when the team started working from two countries and we wanted a clear answer to the question a client would obviously ask. Then the GDPR arrived and the answer was already there. Then the agents arrived, and it was there again.
Why it matters more with agents
A coding agent reads whatever is in the environment it works in. If that environment held real customer records, every prompt would be a data transfer and every log a liability. Ours holds anonymised data, so an agent can read the database schema, run the tests, reproduce a bug and write the fix without a single real person’s record passing through it. The agents work in exactly the same environments as our developers, under exactly the same rule. When a security officer asks whether production data ends up in a model, the answer is structural, not contractual: it is not there to send.
What developers can do without production
Almost everything, and the exceptions are instructive. A bug that only shows on real data is reproduced by operations on an anonymised copy, or, when it really cannot be, by an engineer with temporary, logged access approved for that one case. Performance work runs against generated data of the right shape and volume. Migrations are rehearsed on anonymised snapshots. The friction this creates is small, and it is exactly the friction you want: every look at real data is a decision someone took.
Good practice for any team
We mention the two countries because that is how it started for us, but the rule is worth having whether your developers sit in Rotterdam, Belgrade or the office next door: access only what the work needs, and make the environments enforce it rather than the people. Most organisations we meet have a policy that says roughly this. Fewer have environments that make it true. The difference shows up the day something goes wrong.
If you want to see how the separation is set up for your own system before a first commit, ask. It is part of the paperwork on our security page, and part of the first conversation.