Declared scope is the set of operation targets, such as the filesystem, a shell or the web, that are stated as within an agent's task boundaries. Each attempted action's target is compared against that set, and a mismatch is recorded.
An objective says what an agent is trying to accomplish. A scope says where, and with what kinds of activity, it is expected to work while doing so. The two are declared together as a declared intent, and they do different jobs. Without a stated scope, an agent may have dozens of tools and systems within reach and nothing that says which of them this task should need. Declared scope makes that reference explicit, so that each attempted action can be compared with it.
The words "stated as within" are deliberate. A declared scope is an assertion about the task's boundaries. It does not grant a permission, prove that an operation is appropriate, or stop an operation from proceeding.
Objective, scope, authority and policy
Four concepts sit close together and do not stand in for one another.
| Concept | The question it answers | Who settles it |
|---|---|---|
| Objective | What outcome is the agent meant to pursue? | Whoever assigns the task |
| Scope | Within what boundaries may it pursue that outcome? | Whoever assigns the task, stated with the objective |
| Authority | What has the agent actually been permitted to access or change? | The people and systems that own the resources: credentials, roles, authorization |
| Policy | What rules govern its conduct, and what response does a given operation call for? | The organization operating the agent |
The gaps between them are where the interesting cases lie. An agent can hold valid credentials for a system that is outside its assigned scope: authority without scope. It can attempt an operation inside its declared scope that does nothing for its objective: scope without relevance. An action can be in scope, permitted and relevant, and still be one the organization's policy treats as needing a second look. No one of the four answers the others' questions.
What a scope can describe
As a general matter, a task's boundaries can be drawn along several dimensions:
- the target systems and resources the task should touch;
- the classes of operation it should need, such as reading but not writing;
- the domains or environments involved, such as staging but not production;
- the limits of one task or one execution session, as opposed to the agent's standing role;
- constraints on what the agent may change, disclose or invoke.
A given governance system represents some of these and not others. Sentience Governor's current representation is deliberately narrow: a scope is a list of target-system names, as the definition above says. The section on the implementation describes exactly what that does and does not capture. The broader list is the concept. The narrower one is what is implemented today.
Scope is not a capability inventory
Three things can make a capability available to an agent. An agent harness offers it tools. A Model Context Protocol server lists tools it can discover. An authorization layer issues a credential that permits the operation.
None of those establishes that the capability belongs to the task in hand. Availability says the agent can. Permission says the agent may, in general. Declared scope says something different in kind: what this task, now, should need. A capability inventory and an access-control list are both standing facts about the agent. A declared scope is a task-specific reference that exists for one piece of work.
The MCP entry separates six facts about a tool call: that a capability was discovered, that its use is authorized, that it is appropriate to the current task, that an invocation was attempted, that a result was returned, and that an effect was confirmed. It observes that the protocol defines no authoritative statement of the task against which appropriateness could be judged. Declared scope is one such statement. It supplies the reference for the third fact, as far as a structural boundary can, and it is supplied from outside the protocol.
This also differs from scope in the OAuth sense. An OAuth scope limits what a token permits and is part of authority. MCP's security guidance recommends keeping those scopes minimal, which is good practice and answers a different question. A token scoped to customer records says the agent may read them. A declared scope that omits the customer system says this task should not need to.
What a declaration establishes
A declared scope is intended as an explicit, good-faith statement of the boundaries within which an agent will pursue its objective. It creates a reference against which later execution can be evaluated, and it records what was asserted, by whom, and when.
It is not proof that the declaration is truthful. An agent could misstate its scope, or stay inside a broadly declared scope while pursuing something it should not. Three things are distinct and are not automatically equal: declared intent, actual intent and observed execution. A governance record can hold the first and the third. It cannot independently establish the second. That is why Sentience's own documentation describes a declaration as recorded and untrusted, and why the record notes who made it.
An example: a support assistant with more access than it needs
The records in this example are genuine Sentience Governor output. They were generated by feeding representative Claude Code hook payloads for two MCP servers, named tickets and crm, into the released Claude Code integration. No MCP server was running, no tool executed and no ticket or customer exists. The payloads were supplied in a fixed order and were not chosen by a live model, so the example shows what is recorded and evaluated, not how an agent behaves. Envelope metadata is omitted and findings are described in words. The scenario continues the one in the MCP entry.
A support assistant is connected to the ticketing system and to the customer records system. Two things in what follows are assumptions of the scenario and not facts in the record: that the assistant holds valid credentials for the customer system, and that its update_ticket request was a request to close the ticket. The record does not establish what any downstream system would authorize, and it does not capture arguments, so it holds nothing that could confirm what the ticket update asked for.
1. The objective. "Summarize support ticket 4812 for the on-call engineer."
2. The declared scope. tickets. The declaration as recorded:
{
"event_type": "INTENT_DECLARED",
"payload": {
"stated_objective": "Summarize support ticket 4812 for the on-call engineer",
"intent_source": "inferred",
"intent_confidence": "inferred_low",
"session_scope_hint": ["tickets"]
}
}The source is marked as inferred, with low confidence, because in this integration the declaration is made by the agent through a tool and not vouched for by the developer who built it.
Three attempted operations followed.
| Attempted operation | Recorded as | Finding at the attempt | |
|---|---|---|---|
| 3 | get_ticket on tickets | Read, target tickets | None |
| 4 | update_customer on crm | Write, target crm | Outside the declared scope, with the default intent rule |
| 5 | update_ticket on tickets (in the scenario, a request to close the ticket) | Write, target tickets | None |
Case 3 is in scope and serves the objective. Reading the ticket is how a summary gets written.
Case 4 is directed at a system outside the declared scope. In the scenario the assistant has credentials for the customer system and the call would be authorized there; the record neither shows nor needs that. It is marked as a mismatch because the task's declaration did not include that system:
{
"event_type": "SCOPE_ASSERTED",
"pass_through": true,
"payload": {
"tool_id": "mcp__crm__update_customer",
"operation_type": "WRITE",
"asserted_permissions": ["write"],
"target_system": "crm"
}
}pass_through: true establishes that the integration did not block the attempted action. It does not establish that a real downstream system executed the operation, or that the operation had an effect. In this run there was no downstream system at all.
Case 5 is the one that matters most. The request is an operation on an allowed system, so it matches the declared scope and produces no finding. In the scenario it also has nothing to do with summarizing the ticket. A scope match establishes that the recorded target satisfied the implementation's structural matching rule. It does not independently establish that the operation respected the boundary the operator intended, or that it served the objective. The prefix example later in this entry makes the first half concrete: a server named ticketsarchive satisfied the rule for a declared scope of tickets, which is unlikely to be what someone declaring tickets had in mind. The record shows a write to the ticketing system. Whether that write was appropriate is a judgment the record supports and does not make.
What these records establish: what was declared, in what order the operations were attempted, the system and type of operation for each, and which fell outside the declaration. What they cannot establish: that the ticket was actually closed or the customer record changed, since each record is of an attempt, and passing a call through says only that the integration did not block it; what the arguments were, since they are not recorded; and whether any in-scope action was relevant to the task.
Scope and autonomy
A declared scope is a boundary, not a script. It does not list the steps an agent will take. Inside it, an agent keeps the freedom that makes agentic AI useful: to choose its own path, to read something unexpected and change course, to retry, to take a verification step nobody planned.
The Agentic AI entry puts the principle this way: governance should make autonomy accountable without removing the flexibility that makes it valuable. Declared scope is one of the simpler instruments for that. It does not require every operation to be anticipated. It asks a narrower question of each adaptation: is this still justified by the objective, and still within the authority and scope that apply? An agent that discovers it must read a second ticket to summarize the first has adapted within its boundary. An agent that decides the summary would be better if it also corrected the customer's record has left it.
Scope across a session
Stating the scope before consequential execution begins is what gives it meaning. A boundary drawn after the fact describes what happened. A boundary drawn beforehand can be compared with what happens.
Work does change, and new information does arrive. The question is who may move the boundary. There are two very different events.
- An authorized change to the task's boundaries. The person or system that owns the task decides it now includes something more, and says so.
- The agent treating newly encountered information as permission. A note inside a ticket asks for an account change, and the agent behaves as though its scope now includes the customer system.
The first is a legitimate re-scoping. The second is the pattern that prompt injection exploits and that ordinary misjudgment also produces. Information met during execution can be a good reason to ask for a wider scope. It is not itself a wider scope.
How a governance system handles this is a design choice, and architectures differ. The behavior of Sentience Governor's current Claude Code integration was verified for this entry. After the three operations above, the agent declared again, with a new objective that included updating the customer's email and a scope of tickets and crm. The declaration call succeeded, in the sense that a second declaration event was written to the record with its own place in the sequence. The next update_customer attempt was still marked as outside the declared scope. The verified behavior of the current Claude Code integration is therefore this: it records a second declaration and continues to evaluate against the first declaration's scope. A successful declaration response does not establish that the session was re-scoped. The new scope is in the record, and it is not what later actions are compared with. This is reported as observed behavior. It should not be read as a complete or intentional design for re-scoping, and how an authorized change of scope ought to be handled, by whom and with what evidence, remains a separate architectural question that this behavior does not settle. Nor should it be read as detection of drift in the objective. Governor does not interpret objectives, and the entry on agent drift covers what it does record.
From declaration to effect
Seven steps are easy to run together and are separate facts.
- Declaring a scope.
- Observing an attempted action at the execution boundary.
- Determining its operation and target: the agent action.
- Comparing the action with the declared scope and the applicable policy.
- Recording the evaluation as governance evidence.
- Deciding on a response: permit, question, flag or refuse.
- Establishing whether the attempted action had an actual effect.
Steps 1 to 5 are the work of runtime governance as evaluation. Step 6 is a response, and enforcement is one possible response among several. Step 7 depends on evidence from the system that was acted on. A scope violation can be recorded without being blocked. A structurally in-scope action can still be inappropriate to the objective. A governance finding, an enforcement decision and a confirmed downstream effect are three different facts, and a record that holds the first should not be read as evidence of the other two.
How Sentience Governor implements declared scope
Representation. A scope is a list of target-system names declared with the objective. The names come from how each integration identifies targets. Direct file operations in Claude Code have the target filesystem. Shell commands belong to a shell namespace, refined by semantic action classification to targets such as shell/process when the command can be classified. MCP tools in Claude Code take the server's name as the host exposes it. In the MCP client wrapper, the target is the part of the tool's name before its first dot.
Comparison. Each attempted action's target is compared with the declared list. A target is within scope if it equals a declared entry or begins with the part of an entry before its first dot. The operation type plays no part in the match once an intent has been declared. The entry on declared intent works through the consequences in detail. Two of them matter here. A dotted entry such as crm.read behaves as crm, so the current representation cannot express "read but not write". And because the test is a prefix test, a server named ticketsarchive was treated as within a declared scope of tickets in the run above.
Who declared it. The record distinguishes a scope supplied by the developer who integrates the agent, which is marked explicit, from one declared by the agent at run time, which is marked inferred. Either way it is recorded as an assertion.
Response. A mismatch is recorded on the event as an advisory finding together with the default intent rule, at the moment of the attempt. The current implementation does not block, approve or modify the action. Operators can add their own signals through a governance profile, and those also produce findings.
What the current implementation does not do. It does not express operation classes, environments or data constraints within a scope. It does not interpret the objective, so it does not distinguish an in-scope action that serves the task from one that does not. It does not verify that a declaration is truthful. It does not confirm effects. And it evaluates only the actions that pass through an instrumented integration.
Scope in the wider architecture
The Sentience white paper names unbounded scope as the first of the governance problems it addresses: agent scopes that are loosely defined, so that systems read and act across datasets and tools with unclear limits. The Governor Model it proposes treats scope as one of three things governed together in a continuous loop, alongside memory and the identities and policies that constrain both, with privileges adjusted as conditions change. That is an architecture and a direction. The current product implements the declaration, comparison and recording described above, and the paper says as much about itself.
Where the concept stops
Declared scope is a reference, stated in advance, that turns "was this action within the task's boundaries?" into a question that can be answered from a record. It is a modest instrument, and its usefulness depends on the precision of the declaration: a scope that names every system the agent can reach is complete and says very little.
It does not grant authority, which belongs to whoever owns the systems. It does not establish relevance, which depends on the objective. It does not prove good faith, which a declaration can assert and cannot demonstrate. It does not prevent anything by being declared. What it contributes that the neighboring concepts do not is the boundary itself: the execution boundary is where an action is seen, the agent action is what is seen, and the declared scope is what it is seen against.