Security tells you who has access. Governance tells you what they're doing with it.

The actual difference

Security is adversarial by design. It asks: who might try to access this system without authorization? What can they do if they succeed? The entire discipline is structured around the assumption that there is an attacker somewhere in the model, and the goal is to prevent them from causing harm.

Governance is operational by design. It asks: what is this system actually doing? Is it doing what we intended? What decisions is it making autonomously, on whose behalf, with what data? When behavior drifts from what was intended, how do we know? The entire discipline is structured around the assumption that the system is working as designed, and the goal is to verify that “working as designed” still matches “what we want.”

The difference is the threat model. Security defends against unauthorized actors. Governance manages authorized operation. You can have perfect security — no unauthorized access, no breaches, no vulnerabilities — and still have an AI system that is making consequential decisions no one intended it to make.

Why security expertise doesn’t automatically produce governance

Security professionals are trained in a specific way of thinking about risk. The questions come naturally: where are the authentication points? What happens if this token leaks? These are valuable questions. They are not governance questions.

Governance questions sound different: What decisions is this AI authorized to make without human review? What data is it allowed to use as inputs? If its behavior changes — because the model was updated, because the prompt was changed — how do we detect that? These questions don’t come from the adversarial frame. They require a different kind of attention.

The software factory governance problem

A software factory introduces AI at two distinct layers, and each creates its own governance surface.

The first is the development process itself: agents that read code, write code, run commands, edit files, and make decisions about what to change. The governance question is not “can they access this?” but “what are they allowed to do with that access, and is that what they’re actually doing?” In a well-governed factory, these questions have written answers enforced at the process level — not by hoping the AI behaves correctly, but by designing the process so that out-of-scope actions can’t happen silently.

The second is the product being built: the software you are shipping that may itself include AI features. What data flows to which model? What decisions does the product AI make autonomously? How do you know if its behavior has changed between last month and this month?

In a software factory, you are governing both simultaneously. The governance load is real, and it scales with the number of AI-powered components you are running or building.

What a governance program actually looks like

Governance is not a tool. It’s a discipline with five components, each of which requires ongoing attention.

Policy is the written definition of what AI can do autonomously versus what requires human review. In development process governance, this is the CLAUDE.md and the handoff protocol: specific actions that require explicit sign-off, specific files that require claim-and-release. Policy without enforcement is wishful thinking.

Audit trail is the record of what AI did, when, with what inputs, and what it produced. Without this, you cannot answer a governance question after the fact. The trail has to be created at the time of the action, not reconstructed later from incomplete logs.

Scope bounds are the hard limits on what AI can touch. This is where governance and security overlap, but the reason for the scope bound in governance is different — it’s not “protect against attackers” but “prevent the system from reaching into data it wasn’t designed to use.”

Drift detection is the ongoing monitoring of whether AI behavior is changing over time. Model updates, prompt changes, input distribution shifts — any of these can change behavior without changing any code you wrote. Drift detection means having a baseline definition of what “working correctly” looks like and a mechanism for detecting deviation.

Review cadence is the scheduled human activity that asks: is our governance policy still aligned with what we’re actually doing? Policies written for last year’s AI deployment may not cover this year’s.

The practical case for dedicated governance

The argument for dedicated governance responsibility is simple: if no one is specifically responsible for these questions, they will not get asked consistently. Without dedicated ownership, governance reviews don’t happen until something goes wrong.

Both shapes of failure — development agents doing something they shouldn’t, and product AI behaving outside its intended scope — are governed the same way: written policy, audit trail, scope bounds, drift detection, and a person whose job it is to pay attention to all of it. The investment is proportional to how much AI is doing on your behalf. That’s the work Mercature helps establish.