Policy resolution is the process of determining which governance policies apply to an AI agent or execution context. It establishes how policies are selected, combined, or prioritized, and provides the basis for evaluating agent behavior against the appropriate expectations and boundaries.
As soon as there is more than one policy, something has to decide which one applies. A single machine may run a release agent, a documentation agent and an experiment, each of which should be held to different expectations. An organization may have defaults that teams refine. Resolution is the step that answers “which policy governs this?” before anything is evaluated against it. It is easy to overlook, because when it works it is invisible, and when it goes wrong every finding that follows is still produced, just against the wrong rules.
Why agents make the question harder
A person joining a team inherits its expectations through their role. Agents have no such context. They are started by scripts, schedulers, people and other agents, on laptops, in CI pipelines and on hosted executors, and the same agent may run in all of those places in one day.
For most agent deployments today, the answer to “which policy applies?” is whatever configuration file a harness happens to read on whatever machine it runs. That answer is rarely written down. Two sessions of the same agent can be governed differently, and nobody can tell afterward which rules any given action was judged against.
The principle that follows is simple to state: policy should be defined independently of the agent and associated with each execution explicitly. Resolution is where that association is made.
Resolution is not evaluation or authorization
Three questions are often merged into one.
| Step | The question | Example |
|---|---|---|
| Resolution | Which policy applies to this run? | The infrastructure profile, because the agent’s identity matches its binding |
| Evaluation | What does that policy say about this action? | A destructive cloud deletion matches a high-consequence designation |
| Authorization | May this action proceed? | The agent’s credentials permit the deletion |
Resolution happens once per subject, evaluation once per action, and authorization is a separate system’s decision. A record that shows only evaluation results cannot be fully understood without knowing what resolution produced, and a review that questions a finding often turns out to be questioning the resolution behind it.
Two traditions from infrastructure
Infrastructure platforms have solved versions of this problem for years, in two broad ways.
Composition: every applicable policy applies. In AWS Organizations, service control policies attach at the organization root, at organizational units and at accounts, and an action is permitted only if every level on the path allows it. Google Cloud’s organization policies are inherited down the resource hierarchy, with deny values taking precedence when lists are merged. Composition promises that nothing applicable is ignored, and becomes hard to reason about when many policies interact.
Precedence: one source wins. Configuration systems more often pick a winner. Claude Code’s settings are layered from managed settings down through project and user settings, and a value set at a higher level overrides the same value below it. Precedence is simple to explain and depends on getting the order right, though even there, permission deny rules from any level are checked before allow rules.
Most real systems combine the two. Agent execution makes recording the resolution outcome particularly important.
Principles for resolving policy for agents
Agent sessions differ from infrastructure requests in two ways that matter here: a session can run for a long time, and its record is meant to be read later by someone who was not there. That suggests a few principles.
Key on an identity the operator controls. The subject should be identified by something set by the operator or integrator, known before the session starts, not by anything the agent says about itself mid-run.
Make policy continuity explicit. The policy context should be identifiable at every point in an execution, so that each finding can be read against the rules in force when it was produced. Policy may legitimately need to change during a session, particularly for long-running agents that work for hours or days, where a corrected rule should not have to wait for the next run. But a change should be deliberate and traceable, and it should be reflected in the execution evidence. It should never happen silently underneath a running agent, and an agent should not be able to change its own governance by triggering a configuration change.
Make failure visible, not silent. If the policy intended for an agent cannot be applied, quietly substituting the next-best one would govern the agent under rules written for someone else. Falling back is acceptable. Hiding the fallback is not.
Record the answer and the route to it. A finding can only be read correctly against the rules that produced it. Writing which policy governed a session, and how that was decided, into the execution record turns resolution from configuration into evidence.
An example
Consider three agents on one machine. An infrastructure agent is bound to a strict infrastructure profile. A general coding agent has no binding and runs under the machine’s default. An experimental agent was meant to run under its own profile, but that profile is broken.
Each attempts the same command: deleting a staging load balancer. It is flagged as high-consequence in the first session and not in the other two, because the default profile designates nothing. Without resolution in the record, a reviewer sees an inconsistency and has to guess at the cause. With it, the record explains itself, and the third session is the important one: without a record of how resolution went, an agent whose intended policy failed would look exactly like an ordinary agent on the default.
How Sentience Governor applies it
In Sentience Governor, an operator binds agent identity patterns to governance profiles. Each session resolves to exactly one profile, through a matching binding, otherwise the machine default, otherwise none, and keeps that answer for the life of the session. The outcome is recorded, including when an intended binding could not be applied, and a problem with policy never stops the agent. Every finding in the record can therefore be traced to the profile that produced it.
Where this is heading
Emerging approaches. The direction mirrors infrastructure policy: richer keys, as agent identity matures toward a verifiable identity that can carry the team, the task and the delegating user; hierarchical defaults, set by an organization and refined per team and per agent; and central definition with local evaluation, so policy is consistent across machines without every decision depending on a network call.
Open questions. How resolution should work for subagents an agent creates for itself, which may need a narrower policy than their parent. What an explicit, recorded re-resolution should look like for agents that run for days. And how a harness’s own permission settings and an independent governance profile should be reconciled when both apply.
Where the concept stops
Policy resolution establishes which policy applied to a session and how that was decided. It does not establish that the policy was the right one for the work: a binding can match an agent it was not meant for, and the record will faithfully show that it did. An identity is only as trustworthy as whoever set it. And resolution says nothing about individual actions. What it contributes is the link between every finding and the rules that produced it, which is what lets a record be read, compared and questioned after the fact.