Analysis 11 min read

# Beyond Security by Design: The Rise of Governance by Design

For decades, software engineering learned the same lesson in three different domains: critical system properties have to be designed in, not bolted on. Security by Design, Privacy by Design, and Safety by Design all encode that principle. AI agents that can write code, open pull requests, and modify infrastructure are forcing a fourth: Governance by Design. The phrase is already appearing in agentic-AI research, and it names something Mneme has argued from the start — governance belongs in the architecture, not in a post-hoc review.

By Theo Valmis·June 2026

## Governance is moving upstream

Three of the most durable ideas in modern software engineering share a single shape. Security by Design says authentication, authorization, and threat modeling belong in the architecture, not in a penetration test after launch. Privacy by Design says data minimization and consent belong in the schema, not in a compliance review. Safety by Design says failure modes belong in the system model, not in a post-incident report.

The common principle is simple: properties that are expensive or impossible to retrofit must be present from the first design decision. You cannot inspect quality into a system that was not built for it.

AI agents create the same challenge for governance. When autonomous systems write code, open pull requests, modify infrastructure, and coordinate across repositories, governance can no longer be a review stage that happens after the work is done.

## What “Governance by Design” means for agents

The term is no longer hypothetical. A 2026 paper — Governance by Design: Architecting Agentic AI for Organizational Learning and Scalable Autonomy — argues exactly this: governance is implemented through concrete architectural and working arrangements that determine what an agentic system may do, which tools and data it can use, and how its memory is handled — not as a static compliance layer applied to a finished system. It is the same move that gave us the earlier “by design” disciplines, applied to a new failure surface.

For a coding agent, designing governance in means deciding, before the agent runs, which architectural decisions and invariants must hold as it operates — and making those decisions enforceable at the points where the agent acts. It is not a policy document the agent is asked to remember. It is a constraint the system applies.

## Why after-deployment governance fails for autonomous systems

Governance that runs after deployment assumes a human reviews each change before it takes effect. That assumption held when humans wrote the code and opened the pull requests. It breaks when an agent can generate a change, run it, and move on within seconds — faster than any review queue can keep pace.

The result is a widening gap between the speed of action and the speed of oversight. The more autonomous the system, the larger the gap, and the more governance-after-the-fact becomes governance-in-name-only. By the time a violation surfaces in review, it has already shaped the next ten changes built on top of it.

Property | Governance after deployment | Governance by design
--- | --- | ---
When it runs | After the change is made | Before the agent acts
Assumes | A human reviews each change | Autonomy is the default
Failure mode | Violations found late, after they compound | Violations blocked at the source
Scales with autonomy | No — the gap widens | Yes — enforcement is automatic
Artifact | A review comment | An enforceable constraint

## Where governance gets designed in

Designing governance into an agentic system is not one control; it is a set of insertion points across the architecture:

- Architectural intent — the decisions and invariants that must survive every agent run, recorded as structured records rather than prose.
- Tool access — which actions an agent may take, and under which conditions, enforced at the tool boundary.
- Memory — what an agent is allowed to treat as authoritative, and how decisions persist across a long session.
- Operational controls — checks before commit, before pull request, and in CI, where a violation can still be stopped.
- Verification — a deterministic check that proves the constraint held, with a trace back to the decision that defined it.

None of these is a model capability. They are system properties, and like security and privacy before them, they have to be designed in.

## Governance by design vs governance theater

There is a failure mode worth naming. A system can have a governance vocabulary — dashboards, policies, audit logs — without having governance enforcement. Observing that an agent violated an architectural rule is not the same as preventing it. Observability tells you what happened; governance constrains what is allowed. Governance by Design is specifically the enforcing kind: the constraint runs before the action, and the action does not proceed if it fails.

## What this looks like in the SDLC

In practice, Governance by Design is the same principle as governance before generation: the relevant architectural constraints are present and enforced at the moment an agent is about to act, not retrieved for a human to consider afterward. It turns architectural intent into something the system checks, the same way a type checker turns interface contracts into something the compiler checks.

Security, privacy, and safety all became “by design” disciplines once the cost of retrofitting them became unbearable. For autonomous agents, governance is reaching the same threshold — and for the same reason.

## Frequently asked questions

What is Governance by Design?+
Governance by Design is the principle that architectural governance — the decisions and invariants a system must preserve — should be built into an AI agent's architecture, tool access, memory, and operational controls, rather than added as a review step after the agent has already acted. It extends the established 'by design' pattern from Security, Privacy, and Safety to the governance of autonomous systems.
How is it different from Security by Design?+
Security by Design builds threat resistance into the architecture. Governance by Design builds architectural-decision enforcement into the architecture. They share the same shape — design the property in rather than bolt it on — but they protect different things: security protects against attackers, governance protects against the system drifting away from its own intended architecture as autonomous agents change it.
Why can't governance just happen in code review?+
Code review assumes a human inspects each change before it takes effect. Autonomous agents generate, run, and build on changes faster than any review queue can keep up, so review-stage governance becomes governance-in-name-only. Designing governance in means enforcing constraints before the agent acts, which scales with autonomy instead of falling behind it.
Is this just another dashboard or policy document?+
No. A policy document or dashboard gives a system a governance vocabulary without governance enforcement — it can describe a violation but not prevent one. Governance by Design specifically means the constraint runs before the action and blocks it if it fails, with a deterministic trace back to the decision that defined it.
Related governance concepts

- Governance Before Generation

  Enforce the relevant architectural constraints before the model produces output.

- Governance Infrastructure

  The platform layer that encodes, distributes, and enforces decisions across agents and CI.

- Deterministic Enforcement

  Same input, same verdict, every time — the property that makes designed-in governance trustworthy.

- Architectural Governance

  Encodes team decisions as structured, retrievable, enforceable constraints.

Related operational essays

- IBM 2026 Tech Leader Study: 77% Say AI Adoption Is Outpacing Governance

  IBM now names governance by design one of three pillars of the tech leader’s mandate.

- Why Observability Is Not Governance

  Observability tells you the agent violated architecture. Governance prevents it.

- Review Is Not Governance

  After-the-fact review cannot scale with autonomous output.

- Prompt Engineering Is Not Governance

  A well-phrased instruction is a request, not a constraint.

- AI Coding Governance Should Be Reviewable

  Designed-in governance is versioned engineering, not opaque hidden state.