The Front Door Is a Policy: Governing Where Your Automation Comes From

Everything we have written about enforced approvals shares one assumption: the thing being approved is the thing that runs. Quorum on the production path, self-approval excluded, change windows held. All of it governs execution. But automation definitions come from somewhere, and in a git-native platform that somewhere is a repository, a remote, a branch and a commit.

That raises a question most automation platforms never ask: who decided that this source was allowed to supply production automation at all?

Deny-all, then admit by name

OpsChain's answer is a git identity policy, and its default posture is the one your security team would choose: deny all. A remote is not a valid source of automation because someone once typed its URL. It is a valid source because the policy's allow-list admits it. The same applies one level down, to revisions. The policy can pin which refs are admissible, so "whatever happens to be on a branch" stops being an execution path and "the reviewed revision we admitted" becomes one.

This inverts the usual failure mode. In most platforms, the set of places automation can come from grows silently. A contractor's fork is added here, a personal mirror there, and nobody can enumerate the set because it was never a set anyone controlled. Under a deny-all policy, the question "where can production automation come from?" has a short, inspectable, audited answer.

Two design details matter in practice:

• Upgrades are seeded. When the policy mechanism arrives on an existing estate, the remotes you already use are seeded into the allow-list. The policy starts by describing your current state, and tightening it is a deliberate, recorded act. A control that begins by breaking Monday morning gets switched off by Tuesday. This one begins with an accurate record.
• What is excluded stays visible. A remote outside the allow-list is not hidden from view. It is greyed out, present but inert. Operators can see that it exists and that policy excludes it, so nobody spends an afternoon looking for a "missing" remote that was in fact a refused one. A control you can see is a control people trust.

Who administers the policy, and who reads it

A policy this consequential needs its own answer to "who can change it?", and "anyone with admin" is not an answer a regulator accepts. OpsChain separates the duties:

• The security administrator role administers the git identity policy and the platform's security posture. Changing the allow-list is its job, and, like every governance act, each change lands in the tamper-evident audit lane with a name attached.
• The auditor role can see everything about the posture (the policy, the allow-lists and the history of every change to them) and can modify none of it. Your internal audit function, or your external assessor, gets first-class read access without anyone having to grant write access they should never hold.

That separation is ordinary segregation-of-duties thinking, applied to a place most platforms treat as plumbing.

The branch that did not reach production

Here is the scenario that makes this concrete.

A bank runs its quarterly core-platform patching through OpsChain. The change window opens Saturday at 02:00. On Thursday, an engineer under deadline pressure fixes a step definition, but does it on a personal fork, because the review queue on the main repository is slow and the window is close. The fix is probably fine. "Probably fine, unreviewed, from a personal fork, into the core banking estate, inside a change window" is also a sentence no change manager wants to read aloud at the post-incident review.

On Saturday, the run is prepared against the fork's branch. Nothing dramatic happens, and that is the point. The fork is not in the git identity policy's allow-list, so it is not a valid source of automation for this estate. The attempt is refused by policy, visibly and on the record, before the first step. The engineer merges the fix through the normal review into the admitted repository. The window still has three hours to run, and the patch ships: reviewed, from an admitted source, through the path's approval policy.

Note what the control did not require. Nobody had to spot the fork in a 2 a.m. code review. No pipeline linter had to guess at intent. No incident had to teach the lesson. The policy held because policies, unlike vigilance, do not get tired on Saturday nights. When the bank's assessor later asks "how do you know unreviewed code cannot reach production?", the answer is structural: here is the deny-all policy, here is the allow-list, and here is the audited history of everyone who ever changed it, read directly through the auditor role.

The limits of the control

This control governs where automation comes from. It is provenance enforcement at the platform boundary. It does not review your code for you, and it does not replace your review culture. An admitted repository with a rubber-stamp review process is still your problem to fix. What the policy guarantees is narrower and, for that reason, provable: nothing executes from a source your security administrators did not admit, and every decision about that set is on the record.

---

Key takeaway

Approvals govern what runs. The git identity policy governs where it may come from. Deny-all by default, admitted by name, seeded on upgrade, visible when refused. Administered by a security-admin role and fully readable by your auditors.

The policy sits inside the same fabric as approval-as-policy and the tamper-evident ledger. Book a demo and bring your own worst-case branch.