I have widened a permission to get a pipeline moving. Most engineers have.
A job fails, a dashboard is late, a downstream team is blocked, and the fastest fix is almost never to redesign the access model. You give the process what it needs, and the system moves again. Sometimes that is the right call.
The part that matters comes later, after the incident is over. A permission that made sense under pressure does not always make sense once the pressure is gone, and most of the time no one goes back to check.
Before I leave a permission in place, I try to ask three things.
Who needs this.
For how long.
Who takes it away.
The first question is who.
This is where access models start to drift. A pipeline may need read access to a source table, but that does not mean every engineer debugging it needs the same reach. A service account may need to write to one target schema, but that does not mean it should be able to write across the warehouse. The work is keeping those two apart.
There is a difference between a permission that supports the system and a permission that just makes the system easier to work around. In the middle of an incident they look almost identical. Both make the error disappear and get the job running before anyone asks why it was late. Only one of them leaves the system easier to explain afterward.
The second question is how long.
Temporary access is easy to underestimate, because the expiration usually lives in someone's memory instead of the system. Someone says give it access for now, and for now quietly becomes the rest of the week, then the next release, then part of the environment nobody questions anymore. No one meant to create a permanent exception. They were solving a real problem under real pressure. But if the expiration is not written into the permission itself, the permission is not temporary. It is undocumented permanent access with a better name.
The fix is small and worth the friction. Put the expiration in the grant, so the access ends on its own instead of waiting on someone to remember it. That one change turns a quiet liability into something the system handles by default.
The third question is who removes it.
This is the part teams skip. Granting access has an owner. Removing it usually does not, and that imbalance has a direction. If several people can grant a permission and no one is responsible for taking it away, the access model only expands, slowly and quietly and almost always for understandable reasons.
You can see the residue in any mature system. A shared credential from an old migration that still works. A service account carrying permissions from a workflow that was retired a year ago. An engineer who kept access to a dataset they no longer touch. A vendor role left active after the integration changed. Each one looks small on its own. Together they become the real architecture of the system, the set of things that can actually reach production data, which is rarely the set drawn in the diagram.
This is why access is not only a security concern. It is an engineering concern. Permissions decide what a system can do under pressure: what can fail, what can be changed, what can be bypassed, and what can be explained later.
A pipeline is not secure because every permission was reasonable the day it was created. It is secure when those permissions still make sense after the urgency is gone. That is the part I pay attention to now. Not whether access was approved, but whether it had a lifecycle.
The permission that saved you during an incident can become the permission that weakens the system months later.
Unless someone owns the ending.