A governance profile is an operator-defined configuration that establishes the expectations, boundaries, and oversight requirements against which an AI agent’s execution is evaluated. It helps determine what behavior deserves attention, which operations carry greater consequence, and how governance findings should be recorded or acted upon.
The same agent can be trusted with very different things in different places. A coding agent tidying a personal project and the same agent working on production infrastructure use identical tools. What differs is what the people responsible for it expect: whether it must say what it is doing before it starts, which changes of direction deserve attention, and which operations are too costly to go unnoticed. Those expectations belong to the operator, not the agent, and they change more often than the agent does. A governance profile is where they are written down.
Why autonomous agents need one
A person working through a task carries the organization’s expectations in their head and checks in when something feels off. An autonomous agent does neither reliably. As agents take more steps without a human checkpoint, the expectations that used to live in judgment have to live somewhere explicit, or they are not applied at all.
Today they are usually scattered: permission files in each tool, instructions buried in prompts, conventions in documentation, review habits in people’s heads. Writing them down as one configuration, separate from the agent and from whatever evaluates it, has three consequences.
- It can be reviewed. A profile is a short document that a person can read, discuss and change through the same review as other operational configuration.
- It can vary without changing anything else. The same agent can run under a strict profile in production and a light one in a sandbox, with no change to the agent or its tools.
- It can be identified. If the record says which profile was in force, every finding can be read against the rules that produced it.
None of this is new. Infrastructure policy systems have long separated a policy’s definition from where it applies: Azure Policy assigns one definition to a scope with its own parameters, and can evaluate compliance without enforcing anything. NIST’s AI Risk Management Framework leaves risk tolerance to each organization and asks that it be determined and documented. A governance profile applies the same discipline to autonomous agents.
What a profile can express
The expectations an operator might write down for an agent fall into a few families:
- Declarations. Whether the agent must state an objective and scope before it acts.
- Signals. Patterns worth noticing during execution: a change of working area, a shift from reading to writing, a long pause.
- Designations. Operations that deserve attention whatever the task, such as high-consequence operations: deleting infrastructure, force-pushing a shared branch, moving money.
- Data handling. What may enter the agent’s context, and what may be written to memory.
- Responses. What each finding should lead to: a record, a warning, a request for approval, a refusal.
No system needs to implement all of them for the concept to be useful. Even a profile that only declares expectations and designations gives a reviewer a fixed reference point.
Not a prompt, not a permission list
A governance profile sits near two familiar things and is easily mistaken for either.
| Addressed to | What it decides | |
|---|---|---|
| System prompt | The agent | What the agent tries to do |
| Permission list | The tool call | Whether the call may proceed |
| Governance profile | The evaluation | Which expectations apply, what constitutes a finding, and what response is warranted |
A prompt shapes behavior; a profile defines scrutiny. Instructions in a prompt work only if the agent follows them, and a capable agent can talk itself past them. A profile does not depend on the agent’s cooperation. The agent need not see it at all.
A permission list answers yes or no; a profile asks what it means. A permission rule can allow a database command. It cannot say that the same command, run in the middle of a task declared as documentation cleanup, deserves a second look. Profiles carry that kind of context.
Two other neighbors are worth separating. A declared intent belongs to one session and comes from whoever assigns the task; a profile is standing configuration that applies to every session it governs. And policy as code is the practice of writing policy in a versioned, machine-readable form; a governance profile is one artifact that can be managed that way. Choosing which profile governs a given run is a separate step, policy resolution.
Why policy identity matters
Suppose an agent deletes a staging load balancer on Monday and nothing is flagged. On Tuesday it does the same thing and the action is flagged as high-consequence. Did the agent behave differently, or did the rules change?
Without knowing which profile governed each run, the question cannot be answered, and the record is ambiguous exactly where accountability needs it to be clear. An execution record that names the profile in force lets a reviewer tell a change in behavior from a change in policy, compare runs fairly, and show after the fact that the posture applied was the one the organization intended.
That identity is most useful when it comes from the profile’s content rather than from a name someone typed. A file called “production-strict” can be edited and still be called “production-strict”. An identifier derived from the content changes whenever the rules do, so two runs carrying the same identifier were evaluated under the same rules.
How Sentience Governor implements it
In Sentience Governor, an operator writes a profile as a short configuration file. It can require agents to declare their intent, name signals that suggest a new task has begun, and designate high-consequence operations. Different agents can be bound to different profiles. When a profile’s conditions are met, Governor records an advisory flag in the execution record; it does not block, delay or change the agent’s actions. Every event in a governed session carries a fingerprint derived from the profile’s content, so any finding can be traced back to the exact posture that produced it.
Where this is heading
Emerging approaches. Agent policy is following the path infrastructure policy took. Profiles are becoming explicit, versioned artifacts whose identity appears in the evidence. Infrastructure systems already layer policy from an organization to a team to a single workload, and let a new rule run in an audit or warn mode before anyone relies on it to deny. Both patterns translate naturally to agents.
Open questions. Whether profiles should be keyed to agents, to tasks or to environments, since an agent’s risk depends on all three. How a profile should apply to subagents an agent creates for itself. And how one profile can express the same intent across tools that name the same action differently.
Where the concept stops
A governance profile defines what an evaluation should notice about an agent’s execution. It does not make the agent behave differently, and it does not grant or restrict permissions. It covers only what the operator thought to write down and what the evaluation can see. What it contributes is a stable, identifiable statement of the operator’s expectations, so that every finding in the record can be traced to the posture that produced it.