AI Governance & Policy

A platform engineering team runs its first cross-team agent audit eighteen months into an AI-assisted engineering rollout, and the spreadsheet it produces is the most uncomfortable document anyone has seen all quarter. The payments team’s sessions are locked down hard: a five-dollar budget ceiling per session, a blocklist covering every path under `infra/` and `secrets/`, and a hard rule against anything that touches the deploy pipeline without a human checkpoint. Three rows down, an internal-tools team — smaller, newer, building a scrappy admin dashboard — is running the same harness with no budget cap, no protected paths, and standing permission to push straight to its own main branch. Both teams report to the same VP. Neither team’s policy was ever compared to the other’s, because until the audit, nobody owned the comparison.

The obvious fix — copy the payments team’s policy onto every team — is also the wrong one, and most platform leads who try it find out within a sprint. A five-dollar session cap makes sense on code that touches a ledger; it is an active handicap on a data-migration session that legitimately needs an hour of exploration before it writes anything. What the audit actually exposed was not that one team was strict and another lax. It was that the organization had no structural relationship between the two policies at all: no floor beneath which no team could fall, and no way for a stricter team to add its own extra caution without inventing its policy from a blank page. Divergence was not a symptom of anyone making a bad individual decision. It was the default outcome of having no hierarchy in the first place.

What the guardrail vendors are actually shipping

The industry response to “AI agents need governance” arrived quickly, and mostly answered a different question than the one the audit above raises. A representative 2026 guide from OpenAI on governing agentic systems is thorough on the risks closest to AI-safety research: block prompt injection everywhere, redact PII and payment data from inputs and outputs, trace what an agent did and why after the fact so an incident is reviewable. What it does not address, in its own scope, is budget ceilings, token limits, or any mechanism for how a policy set at one level of an organization should relate to a policy set at another. That gap is not a knock on one guide — it is representative of where the field’s attention has gone. Agent-guardrail tooling, as a category, has converged hard on content safety and left organizational policy composition mostly unbuilt.

DORA’s 2025 research on AI-assisted software development frames why that gap matters more than it looks. AI functions primarily as an amplifier of an organization’s existing strengths and dysfunctions, not a fix for either. An organization with no consistent story for who can touch what, spend how much, and answer to whom does not stay at that baseline once agents start running inside it — the inconsistency runs at agent speed and agent volume instead of human speed and human volume. Two teams a VP never got around to reconciling stop being a minor org-chart footnote and start being two genuinely different risk profiles, live, every day, whether anyone is looking or not.

The sprawl nobody named

An earlier volume in this Library described, in careful detail, how a single harness should gate an individual session’s operations — reads auto-approved, writes gated, force-pushes default-denied by design. That machinery works, and it works at the grain it was built for. What it does not answer, because it was never meant to, is the question one level up: whether the engineer who configured this particular session’s permission mode was even aware an organizational floor existed, let alone whether the mode they chose respects it. That setting lives in one project’s configuration file, chosen by whoever set the project up, on whatever day they set it up. Nothing connects that file to what the rest of the organization has already decided is acceptable. Multiply that across forty repositories and a platform team gets exactly the spreadsheet described above: forty independent, individually reasonable decisions that add up to nothing coherent together.

Security teams have a decades-old name for the slow accumulation of small, individually reasonable access decisions that nobody is tracking in aggregate: privilege creep. The AI-agent version of the same failure does not yet have an equally crisp name, and that absence is itself informative — tooling to gate a single session arrived years before tooling to ask whether a thousand sessions, spread across an organization, still add up to something the organization would sign off on if it actually looked.

Policy as a tightening-only hierarchy

The shape that keeps recurring, independently, everywhere this problem gets solved well is the one the payments team was already approximating by instinct: an organization sets a baseline — the loosest any team is allowed to be — and every project underneath it may add restriction on top of that baseline, but can never remove or loosen a restriction the baseline already set. This chapter uses the plain, descriptive name for that shape rather than coining a new one: a tightening-only hierarchy, because that is exactly what it is — policy composition where the arrows only point one direction, toward stricter, with no path in the model for a child policy to widen what its parent already narrowed.

This is not a new invention arriving alongside AI agents. It is the same shape as three access-control systems that predate agentic coding by years to decades, each arriving at it independently because it is close to the only shape that is safe by construction. AWS Organizations’ service control policies never grant a permission — an SCP only sets the maximum available permission for every account beneath it, and an account’s effective permissions are the intersection of every policy attached above it in the hierarchy, all the way to the root; a permission blocked anywhere above an account stays blocked no matter what an administrator attaches directly to that account. GitHub’s content-exclusion policies for Copilot cascade the same way: an enterprise or organization can exclude a path from what Copilot is allowed to read, and a repository underneath it inherits that exclusion as a setting its own administrators are explicitly not permitted to edit, only add to. And Claude Code’s own settings model puts managed, IT-deployed policy at the top of a five-layer stack — above command-line flags, above project settings, above anything a user sets locally — specifically so nothing beneath it can override what it decided.

Three companies, three products, no coordination between them, and all three converged on the identical structural answer.

What an org baseline should actually restrict

Applied to a coding agent specifically, five levers recur across every serious implementation of this pattern — and the same tightening-only logic applies inside each of them, not only across the levels of the hierarchy as a whole.

The merge logic across that table is mechanical, and “mechanical” is what makes it trustworthy: paths and forbidden commands from every level union together rather than replace each other; a budget ceiling resolves to whichever number is lower; and if the org sets an enforcement mode to pause-and-review while a project only asked for a warning, the stricter of the two wins. None of that requires a person to adjudicate a conflict at merge time — which is the point. A policy that needs human judgment to compose safely is a policy that will eventually compose unsafely, on the one day nobody is watching it merge.

The floor, encoded

Operon’s own harness ships a version of exactly this model, and it is worth describing precisely rather than abstractly, because a design that only exists on a whiteboard is easy to admire and easy to get wrong the first time it meets a real organization.

The cost of a floor that cannot bend

A tightening-only hierarchy is safer by construction, and that is close to the entire argument for building one. It is also, deliberately, less flexible than a system that lets any team negotiate its own terms case by case — and that cost is worth naming plainly rather than treating the design as a free win. A payments team that legitimately needs a narrow, temporary exception to an org-wide rule — a closely supervised, one-time session that has to touch a path the baseline blocks, for a migration nothing else can accomplish — has no clean mechanism for that exception inside the model itself. The only sanctioned path is to escalate and change the org baseline, for everyone, which is slow, heavyweight, and the wrong-sized tool for a need that is genuinely local and temporary.

In practice that produces one of two outcomes, and both are worth watching for on a real team. Either the organization builds a genuine, audited process for a narrow, time-boxed baseline change — which preserves the safety property but adds latency the team doing the migration will feel every time — or, more quietly, someone works around the policy entirely: a manual edit outside the harness, a credential nobody logged, the same shadow-IT behavior that rigid access-control systems have produced for decades whenever the sanctioned path was slower than the workaround. A tightening-only hierarchy does not eliminate that risk. It relocates it, from “a policy that quietly gets weaker over time” to “a policy that occasionally gets bypassed under pressure” — a different failure mode, arguably a more visible one, but not a solved problem by itself.

The honest design goal is not a hierarchy with zero friction. It is a hierarchy where the escalation path for a legitimate exception is fast enough that going around it is never the rational choice — audited, logged, and resolved in hours rather than weeks. The alternative to a fast escalation path is not “no exceptions ever get made.” It is exceptions nobody approved.

Putting the hierarchy into practice

1. Write the org baseline down as data, not prose — a policy nobody can merge programmatically is a policy nobody can audit.
2. Make paths and forbidden commands union, budgets take the minimum, and enforcement mode take the stricter setting — mechanically, with no human adjudication required at merge time.
3. Build the escalation path for a legitimate local exception before a team needs one, and make it faster than the workaround it is competing with.
4. Log every policy-relevant event with an actor, a rule, and a reason, visible to more than the team that triggered it — an audit trail only one team can read is not an audit trail an organization can trust.
5. Re-run the cross-team audit that opened this chapter on a schedule, not only after something goes wrong. Divergence is the default state, not an anomaly worth waiting for.

None of this requires a from-scratch governance platform. Most of the mechanism described here is composition logic and an audit table — the kind of thing a platform team can build in a sprint once it decides the comparison the payments team’s audit was missing is worth owning permanently, rather than rediscovering at the next incident. The next chapter in this volume moves from how an organization constrains what agents can do to how it decides where agents get deployed across functions in the first place — a decision that, done well, sits directly on top of the baseline this chapter describes.