The Governor Model is the architecture proposed in the Sentience white paper, in which governance is a continuous control loop that jointly manages an agent's scope, its memory, and the identities and policies that constrain both. It describes an architecture and a direction, not the current capabilities of Sentience Governor.
It is Sentience's proposed architecture for governing increasingly autonomous AI systems. Its thesis is that scope, memory, identity and policy have to be considered together while an agent executes, and not treated as independent or static concerns. It is a developing research and engineering framework. It is not an industry standard, a formal specification or an independently validated model, and it is not a claim that every part of the architecture is implemented in Sentience Governor. The open-source software implements selected runtime governance capabilities, and the two names are not interchangeable.
This entry explains the model at the level Sentience has published. The white paper's [public introduction](/paper) sets out the problem, the thesis and the topics the paper covers, and is the access point for the full research paper, which is available on request. The detailed architecture is in that paper and is not reproduced here.
Why Sentience proposes it
Conventional software follows logic written in code. Agentic AI systems select operations at run time, based on what they encounter. That changes the governance problem. An agent may hold entirely legitimate capabilities and still select an operation that does not serve what it was asked to do.
The white paper's abstract describes agents as becoming long-running digital employees embedded in enterprise workflows, operating across systems of record with tools, memory and varying degrees of autonomy. It observes that traditional role-based access control and periodic governance, risk and compliance reviews were not designed for systems whose scope, behavior and memory evolve continuously, and it puts the situation in one sentence: autonomy is increasing faster than governance primitives.
The public introduction names six governance problems the paper addresses.
- Unbounded scope. Agent scopes are loosely defined, so systems read and act across datasets and tools with unclear limits on what they may access, copy or propagate.
- Drift and shifting objectives. As policies and business goals change, agents keep acting on outdated context and implicit objectives, and the misalignment is hard to detect in real time.
- High-speed, multi-system impact. Agentic workflows read and write across many systems of record in seconds, too fast for human-centered approval workflows.
- Opaque memory. Systems accumulate and reuse context over long periods with limited visibility into what they remember, for how long, and under which policy classifications.
- Long-horizon traceability gaps. When something goes wrong, it is hard to reconstruct why a workflow behaved as it did over weeks or months of evolving scopes and changing policies.
- Static, human-centric controls. Existing frameworks assume relatively static roles and rely on humans as the primary enforcers, with no continuous runtime mechanism to adjust agent privileges.
The argument that follows is that governance of such systems cannot rest entirely on instructions given before execution or on reviews held afterward. It has to consider, during execution, what the agent was asked to accomplish, what it may access, how its context and memory change, and what it actually attempts.
What is established and what is Sentience's combination
The model does not claim to originate its parts, and several are mature fields in their own right.
- Identity, access management and authorization decide who or what may reach a system.
- Governance, risk and compliance practice defines retention, data-handling and oversight obligations.
- Runtime observability records what systems do.
- Frameworks for scoping agent security by level of agency and autonomy have been published, for example by AWS and extended by the Cloud Security Alliance.
- Agent memory is an active area of research and engineering.
What Sentience proposes is a particular combination of them. In the paper's words, the Governor Model is a continuous control plane that jointly manages an agent's scope, its memory, and the organizational identities and policies that constrain both. It treats governance as an ongoing control loop, taking in drift, access, provenance and policy signals to adjust agent privileges in real time. The public introduction lists the paper's topics: the architecture and its control loop; two axes of governance, memory tiers and a security and agency matrix; a meta-identity for agents that goes beyond traditional identity management; context certification and traceability at four levels; a phased adoption pathway from observational governance to a unified control plane; and integration with enterprise identity platforms, the AWS and Cloud Security Alliance frameworks, and MCP-based identity layers.
Four concerns, considered together
Each of the four has a clear role.
| Concern | The question it answers |
|---|---|
| Scope | Within what boundaries may this agent act: which systems, and how much autonomy? |
| Memory | What information persists, is available across the agent's work, and influences its later decisions? |
| Identity | Who or what is the agent, on whose behalf does it act, and who answers for it? |
| Policy | Under what organizational rules are the other three evaluated and governed? |
The reasoning below is this entry's interpretation of why the model treats them jointly. It is built on the published problem statements and not on the paper's internal design.
Each concern changes the meaning of the others. A permission that is reasonable for an agent with no accumulated knowledge of customers may be less so for one that has been collecting it for months: what an agent can do matters in proportion to what it knows. A policy change has force only if something connects it to agents that are already running and to context they have already absorbed. An action's accountability depends on whose authority it was taken under, which a credential alone may not say. And all of these move while the agent works, which is why a configuration fixed at deployment describes the agent as it was and not as it is.
Treated separately, each control can be working as designed while the combination goes unexamined. That is the gap the model is aimed at.
A continuous loop, not a one-time configuration
The second half of the thesis is about time. The public description is of a control loop: signals about drift, access, provenance and policy arrive continuously, and the agent's privileges are adjusted in response, in real time.
Operationally, a loop of that kind needs three things: a current picture of each agent's boundaries, context and authority; a stream of signals about how the agent is behaving and how the organization around it is changing; and a way of deciding, under policy, whether the current arrangement is still appropriate. These are architectural responsibilities and not a list of software components. How the paper proposes to meet them is the subject of the full paper.
An example: every check passes
The following scenario is illustrative. It was written for this entry, does not describe a real deployment, and does not demonstrate shipped capabilities of any product.
A customer-success team sets up an agent to prepare renewal briefings for one region's accounts. Over a quarter, several things happen, each sensible when it happened. Colleagues connect more tools because each was useful once: the billing system, the support desk, the contract repository. The agent keeps working notes across sessions, and nobody has looked at what is in them. In the second month the company changes its discount policy, and the agent's notes still contain the guidance it summarized in the first. It now works for several account managers, and nothing records on whose behalf a given action is taken.
Asked to get renewals moving, the agent drafts a renewal quote and sends it through the billing tool, using the old discount.
Consider that call in isolation. The credential is valid. The tool is one the agent is allowed to use. The customer is in its region. Each individual check may pass, and a rule that treats outbound quotes as sensitive might flag it on its own. What the individual checks do not supply is the rest of the picture. The agent's reach grew by accretion and was never restated. The guidance it relied on came from memory formed under a policy that has since changed. No one can say under whose authority the quote went out. Weeks later, reconstructing why it happened means assembling all of that from separate systems.
The point is not that any single control failed. It is that scope, context and memory, identity and policy each held information relevant to one governance decision, and nothing brought them together while the agent was acting. Governing an autonomous agent involves more than checking whether an individual tool call was permitted.
Evaluation, evidence, intervention and enforcement
These are separate architectural responsibilities, and the glossary keeps them apart throughout. Observing an action is not evaluating it. Evaluating it is not enforcing a restriction. Recording an attempted action is not confirming its effect on the system acted on.
As publicly described, the Governor Model goes beyond evaluation: its loop adjusts agent privileges. That is a proposal about architecture. It is not an observed result from released software, and the next section states what the software does. The entry on the agent harness explains why effective enforcement often has to sit beyond any single harness, at the boundaries where consequential actions occur, and that reasoning applies to any architecture of this kind.
Governance that enables autonomy
Governance is often pictured as a brake. The position taken across this glossary is that it should make useful autonomy accountable, not replace it with a rigid, predefined workflow.
Inside its boundaries an agent adapts freely: it chooses its path, reads unexpected information and changes course. A justified adaptation stays within the objective and the scope and authority in force. A change that needs more than that calls for renewed authorization, and in the model privileges are adjusted by the control plane in response to signals, not by the agent's own decision.
The practical consequence runs in the enabling direction. An organization that can state an agent's boundaries, see what it relies on and review what it attempted is in a position to extend more autonomy than one that cannot, because departures become visible. The entries on declared scope and agentic AI make the same argument at the level of a single task.
Where declared intent and declared scope fit
This section is interpretation, connecting the published thesis to later engineering work. The white paper's public description concerns an agent's scope as something managed and adjusted over time. Declared intent and declared scope, as implemented in Sentience Governor, work at a finer grain: one task, one session. They supply an explicit reference for that task. A declaration creates an accountable reference, and actual execution provides evidence that can be compared with it. That matters most when an agent meets information that could redirect it, as in the example above.
The distinctions established in the Declared Scope entry carry over unchanged. A declaration records what was asserted. It does not grant authorization in any downstream system. It does not prove the agent's genuine intent. And a structural scope match does not establish that an operation served the objective.
The Governor Model and Sentience Governor
The Governor Model is the architectural and research framework presented in the white paper. Sentience Governor is open-source software that implements particular runtime governance capabilities. The white paper's own page makes the same distinction, pointing readers to the repository and the release notes for what is shipped.
| Concern | Sentience Governor's current implementation |
|---|---|
| Scope | A task-level declared scope is recorded and compared with each attempted action at the execution boundary. Nothing adjusts an agent's privileges |
| Memory | An attempt to write to a persistence target is recorded as an event, and context entering a session is recorded by source and size. Memory itself is not managed |
| Identity | An agent identifier and an owner are recorded as claims. They are not verified against an identity provider |
| Policy | Default rules plus an operator-authored governance profile, resolved per agent and held fixed for a session |
| Loop, intervention and enforcement | None. Each action is evaluated as it is attempted, findings are advisory, and every action is passed through |
| Record | An append-only local record of declarations, attempted actions, findings and the policy applied: governance evidence |
The paper's public introduction describes an adoption pathway that begins with observational governance. The current implementation is observational in that sense: it observes, evaluates, flags and records, and it changes nothing about the agent or its actions.
One record makes the memory row concrete. It is genuine Sentience Governor output, generated by feeding a representative Claude Code hook payload for a file write into the released Claude Code integration. Nothing was executed and no file was written. Envelope metadata is omitted.
{
"event_type": "MEMORY_WRITE_ATTEMPT",
"payload": {
"write_type": "write_to_persistence_target",
"detection_mechanism": "tool_metadata",
"target_store": "filesystem",
"write_classification": "unclassified",
"write_size_tokens": 14,
"retention_requested": null
}
}The record says that a write to a persistence target was attempted, where, and roughly how large it was, and the evaluation noted that the write was unclassified. It does not say what was written or whether the write happened. That is the distance between recording a memory write attempt and governing memory.
The table describes the software as it was when this entry was last reviewed. It is a statement of present fact and not a list of commitments.
What building it has taught us
Implementing the first parts of the architecture has made several distinctions firmer, and they are recorded across this glossary.
- An attempted action, a returned result and a confirmed effect are different facts. A record of the first is not evidence of the third.
- A declaration is an assertion, not proof of genuine intent. It is recorded as untrusted, along with who made it.
- A structural scope match does not establish that an action served the objective.
- An advisory finding does not itself enforce a restriction. A restriction is effective only where a consequential boundary honors it.
These came from engineering and not from the original paper. They refine the model without changing its thesis, and they are one reason the architecture should be expected to evolve.
Where the concept stops
The Governor Model is a proposal. It sets out how Sentience currently understands the problem of governing increasingly autonomous systems, based on its research and engineering experience. It has not been standardized or independently validated, and its components and definitions are not a fixed taxonomy.
It is also broader than any one product. It sits above the neighboring concepts in this glossary as the framework that relates them: AI agent governance names the responsibility, runtime governance names evaluation during execution, the execution boundary names where actions are observed, the Model Context Protocol and the harness describe how agents reach systems, and the Governor Model proposes how scope, memory, identity and policy are held together while all of that happens. Readers who want the architecture itself should request [the full white paper](/paper).