Governance Is Not a Feature of Your Agent Framework

When governance is implemented inside an agent framework, it inherits the framework’s lifecycle. That is not an implementation detail. It is a structural dependency that cannot be avoided.

Frameworks change. APIs evolve. Configuration formats shift. Features are added and removed. If governance is embedded in the framework, governance behaviour changes when the framework changes — regardless of whether governance requirements have changed.

The separation test

There is a behavioural test for whether governance is independent: can you change the agent framework — upgrade it, reconfigure it, replace it entirely — without altering what governance allows or denies?

If the answer is yes — if the governance system evaluates actions, renders decisions, and produces evidence regardless of which framework produced the tool call — then governance is independent infrastructure.

If the answer is no — if upgrading the framework changes what is allowed or denied without a corresponding governance policy change — then governance is not separated. It is a framework feature.

If you cannot describe governance without referencing the framework, governance does not exist independently of it.

The distinction matters because framework features are governed by the framework vendor’s priorities, not by the organisation’s governance requirements. A vendor may deprecate an API, restructure configuration schemas, or change default behaviours between releases. These changes are driven by engineering priorities — performance, usability, market positioning — not by governance invariants.

What collapses when governance is embedded

Lifecycle coupling. Governance configuration changes when the framework changes. Policy formats, permission schemas, and audit log structures are tied to framework versions. A framework upgrade is a governance migration — whether or not governance requirements have changed.

Vendor dependency. The governance system’s behaviour depends on the framework vendor’s implementation. Bugs in the framework’s governance module are governance bugs. Deprecated features are governance regressions. The vendor’s roadmap determines governance capability.

Portability loss. If the organisation migrates to a different framework — or operates agents across multiple frameworks — governance must be reimplemented for each framework. Policies cannot be shared. Evidence formats diverge. The governance posture varies by framework, not by policy.

Testing opacity. The governance system’s behaviour is tested by the framework vendor, not by the organisation. The organisation trusts the vendor’s test suite to verify that governance operates correctly. When the vendor’s tests pass but governance behaviour has changed — because the vendor’s definition of correct differs from the organisation’s — the failure is invisible until an audit finds it.

Evidence absence. Framework-native governance may log decisions, but the logs are not cryptographically chained, not independently verifiable, and not bound to a specific policy version and delegation state. A checkpoint records state, not authorisation. Without tamper-evident evidence, the governance claim is unfalsifiable.

Independent infrastructure

Governance as independent infrastructure means the governance system exists outside the framework. It does not import the framework’s libraries. It does not use the framework’s configuration format. It does not version with the framework’s releases.

The framework produces tool calls. The governance system evaluates those calls before execution. The boundary between the two is an adapter — a translation layer that converts the framework’s tool-call representation into canonical facts that the governance system evaluates. The adapter is framework-specific. The evaluation is framework-agnostic.

When the framework changes, the adapter changes. The governance system does not. When the organisation migrates to a different framework, a new adapter is written. The policies, the evaluation function, the evidence chain, and the decision logic remain the same.

The invariant

Governance that depends on the framework is not independent governance. It is a framework feature.

This is not a quality judgement about frameworks. Frameworks optimise for capability. Governance optimises for constraint. Frameworks evolve on vendor timelines. Governance evolves on policy timelines. These are structurally different concerns with structurally different lifecycles.

Upgrade the framework. If governance behaviour changes without a governance policy change, governance is coupled.

Remove the framework. If governance disappears, governance was never a separate control.

Replace the framework. If policies must be rewritten, governance was never independent.

Independent governance survives all three.