# Review the authority behind an agent's effects

Rethinking Agents · v0.2 · October 1, 2026

Use this guide when an agent can execute code, operate another service or delegate work. Pick one workflow and the decision you need to make: allow an unattended run, approve a tool, change a model, investigate an uncertain action or retire a background service. The output is a scoped decision with evidence and named unknowns.

This is a research-backed review method. The accompanying **24 scenarios are specifications, all NOT RUN**. The separate [eight-case filesystem lab](https://rethinkingagents.com/research/harness-effects-lab.md) has executed results for its stated Docker fixtures only. Neither document certifies a product or supplies a production enforcement service.

Download the [editable record](https://rethinkingagents.com/resources/harness-boundary-record.md), [scenario instructions](https://rethinkingagents.com/resources/harness-evaluation-scenarios.md) or [scenario data](https://rethinkingagents.com/resources/harness-evaluation-scenarios.json). Complete them locally using synthetic examples or sanitized references.

## Start with the reader's decision

| Situation | Start here | What a useful answer looks like |
|---|---|---|
| One unattended coding session | Files/configuration and actual execution routes; HB-01–03 | An explicit permitted workspace and inventory of shell, file tools, adapters and fallbacks |
| Several agents on one machine | Process/service ownership; HB-05–08 | A receiver can be attributed to the right session; teardown cannot affect another owner |
| Agent calls SaaS or production infrastructure | Network plus receiver identity; HB-09–12 | Each permitted action is bound to a principal, tenant, object and destination |
| Headless workflows with spend limits | Budgets and truthful completion; HB-08, HB-13–16 | The outer scheduler knows whether work completed and how much uncertain exposure remains |
| Security review or incident handoff | Evidence quality; HB-04, HB-17–20, HB-24 | The conclusion survives disagreement with tool stdout and makes capture gaps visible |
| Model, harness or plugin upgrade | Adapter and authority changes; HB-21–23 | Useful work still succeeds and effective authority has not silently widened |

Begin with three to five relevant scenarios. Running every case is not automatically better: an irrelevant score hides the workflow's actual constraints. Mark omitted surfaces and why they are outside the task. If the enforcement component is mocked, results apply to the mock contract only. Record the actual product version, operating system, configuration and observer before claiming deployment coverage.

## A reference architecture to reason about

```text
Authorized task + owner + scope + expiry
                     |
Model / planner -> tool request -> mandatory admission point
                                      |
                         constrained execution identity
                           /                     \
                 local workload              remote receiver
                 files/processes             tenant/object/action
                           \                     /
                     independently collected evidence
                                      |
                    task disposition + effects + gaps
```

This is a responsibility map, not a requirement to build one central daemon. A sandbox can own filesystem constraints; a supervisor can own lifecycle; an API service can own authorization; an existing tracer can carry correlation. Every arrow needs an owner and a defined failure mode. The model may propose an action, but it must not be able to alter the policy or authoritative record that decides whether the action is permitted.

Four different questions recur: **what was requested, what was admitted, what happened, and what can the evidence establish?** A logged request is useful even if the receiver is unavailable. It does not establish that the receiver acted. A blocked shell command says nothing about a separate host-side MCP server unless that route is also constrained.

## 1. Files, executable configuration and descendants

Declare allowed reads and writes separately. Include inherited file descriptors, mounted directories, temporary paths, symlinks/hard links where relevant, and each component that can interpret a workspace file as executable configuration. A build file, editor task or tool-server configuration may grant authority indirectly when a trusted loader reads it later.

[Claude Code documents OS restrictions covering commands and descendants](https://code.claude.com/docs/en/sandboxing); current harnesses are not all limited to keyword checks. [Docker Sandboxes documents shared-workspace and host-side MCP exceptions](https://docs.docker.com/ai/sandboxes/security/isolation/). Review the effective deployment rather than inferring coverage from the product name.

For a harmless protected canary, compare direct execution, a script and a descendant under the same policy. Also compare shell execution with file tools or adapters running elsewhere. Record authorized task output alongside refused effects. If a tighter sandbox breaks every useful build, that is a utility failure requiring configuration or scope work—not a reason to silently grant host-wide access.

**Stop and restrict scope when:** an executable configuration can be changed without trusted review, an alternate tool has uncontrolled host authority, or a mandatory restriction depends on an unsupported kernel/runtime feature.

## 2. Process ownership is more than remembering a port

A runtime identity should connect session, workload, process start identity, service name and lease generation. A port is an address. A PID can be reused. Neither proves ownership. Shared MCP servers may intentionally serve several sessions; their lifecycle belongs to the shared-service owner.

[cgroup v2](https://docs.kernel.org/admin-guide/cgroup-v2.html) and [systemd unit shutdown](https://www.freedesktop.org/software/systemd/man/latest/systemd.kill.html) are established primitives. Launch work inside its ownership boundary; moving a parent later does not necessarily collect all existing descendants. Record retained services before task expiry, with an authorized owner and TTL. Do not relabel a leaked process as intentionally persistent afterward.

When two sessions contend for a port, choose another approved endpoint or report a conflict. Validate the responding server's session/build marker before accepting a screenshot or test result. A healthy server from the wrong worktree is false validation.

**Stop and restrict scope when:** ownership cannot be established, a helper escapes lifecycle accounting, or cleanup would require broad process-name termination. A local task's exit does not establish the end of remote jobs.

## 3. Network reachability, credential secrecy and remote authority

These are three separate controls:

- **Reachability:** can the workload contact the destination through any available protocol or route?
- **Credential custody:** can it read or export the raw credential?
- **Permitted use:** what may the authenticated principal do on that service, tenant or object?

A proxy environment variable is a client convention, not necessarily a mandatory boundary. [Daytona's documentation](https://www.daytona.io/docs/en/network-limits/) explicitly requires additional domain rules to prevent clients bypassing its configured upstream proxy. [Modal documents](https://modal.com/docs/guide/sandbox-networking) the limits of SNI-based destination filtering; application-level authority needs another enforcement point when tenant/path/action distinctions matter.

Even a mandatory proxy can inject an overly broad credential into an allowed request. Restrict resources and operations at the broker or receiver. For password-only switches, BMCs or administrator logins, the target may offer no narrow role. Record that as a deployment constraint; a credential broker cannot create permissions the device does not support.

Evaluate information flow across tools. A permitted private read followed by a permitted public write can still violate the task. The [GitHub MCP demonstration](https://invariantlabs.ai/blog/mcp-github-vulnerability) illustrates this without requiring a defect in the trusted GitHub tools themselves. Read-only input does not prevent disclosure through output.

**Stop and restrict scope when:** the same credential can reach unrelated tenants/resources, a direct route bypasses the broker, or approval does not bind the actual receiver and material action parameters.

## 4. Budget admission and uncertain outcomes

Separate cost attribution, hard admission and efficiency. A delayed dashboard can explain yesterday's costs while being unable to stop today's run. A cap can prevent overspend while still wasting the entire allowance on repeated unproductive attempts.

Define the quantity being bounded: tokens, provider currency, tool credits, CPU time or all of them. Include concurrent requests, retries, fallbacks and already-submitted asynchronous work. [LiteLLM already documents pre-dispatch reservation, reconciliation and degraded-accounting controls](https://docs.litellm.ai/docs/proxy/users). Its documented pricing limits mean the supported route set matters. Test the incumbent gateway before implementing another budget service.

A lost response leaves two uncertainties: whether the effect committed and what the provider charges. Retain the logical operation ID and separate attempt IDs. Reconcile with the receiver; use idempotency when the service supports the required scope and retention. Some services charge retry attempts even when the effect is deduplicated. Do not invent a once-only charging contract.

For a synthetic 10-credit cap and 4-credit operations, three concurrent requests should not all be admitted under a strict-cap contract. A route that avoids mandatory accounting is a failure even if this run happens to stay under budget.

**Stop and restrict scope when:** price exposure cannot be bounded, accounting is unavailable under a strict-cap promise, or a remote job's ownership/cancellation cannot be established. Reporting uncertainty is correct; it is not proof of cancellation or refund.

## 5. Evidence quality, independence and privacy

An observer is independent only relative to a stated adversary. A sidecar sharing the same writable volume or privileged socket may be alterable by the workload. A signed append-only record can still omit events or faithfully preserve a false tool statement.

[Langfuse](https://langfuse.com/docs/observability/data-model) and [LangSmith](https://docs.langchain.com/langsmith/observability-concepts) already trace tools. Use those records, then identify which effects require an OS event or receiver receipt. Include capture health, buffering, exporter shutdown and missing sequences. Before/after file equality cannot detect a write followed by restoration.

An alert or kill event does not prove prevention. [Tetragon's documentation](https://tetragon.io/docs/concepts/enforcement/) explicitly distinguishes signal-based actions from operations that override a call before an effect. Grade detection and containment separately. Correctly observing a forbidden write is useful evidence of a failed prevention boundary.

Prefer correlation, principals, resource references, decisions, effect receipts and coverage metadata over indiscriminate transcript collection. Decide who may access records, how long they persist and which fields must be redacted before sharing. Test with fake secret markers; never use real credentials as leakage canaries.

**Stop and restrict scope when:** a sensitive action needs evidence that the collector cannot provide, or the workload can silently alter its authoritative record. For lower-risk read-only work, an explicitly defined degraded mode may be preferable to shutting down everything.

## 6. Changing models, adapters, plugins and feedback

The stable contract is authority over resources. Models can differ in planning, tool use and quality while encountering the same resource boundary. A harness upgrade is a separate change: it may alter schemas, environment inheritance, launch paths, transports or fallbacks. Record actual versions and routes, not only requested model names.

Treat plugin installation and updates as authority changes. Pin the reviewed artifact/definition where possible; compare effective permissions and downstream identities. [SLSA's threat model](https://slsa.dev/spec/v1.2/threats-overview) explains why provenance does not establish benign producer intent. A signature cannot make an initially malicious plugin safe, and a pinned description cannot freeze a remote server's implementation.

Use concise denial semantics that retain the state needed for recovery:

| Agent-visible class | Meaning | External action |
|---|---|---|
| Terminal policy denial | The effect is outside this task's authority | Refuse equivalent routes; operator must authorize any scope change |
| Transient operational failure | The action is allowed but may be retried | Enforce a retry count, deadline and spend bound |
| Unknown outcome | The receiver may already have acted | Reconcile before replay; retain uncertain exposure |

Keep match rules and sensitive policy detail in the operator channel, correlated by a safe reference. This wording is a design proposal, not a proved security defense. A model may ignore it. The external boundary still needs to refuse the forbidden effect, and a permitted transient failure still needs a workable recovery path.

## A minimal record of one operation

This illustrative field set is not a new telemetry standard. Map it to existing trace and receiver identifiers where possible:

| Field group | Minimum useful content |
|---|---|
| Delegation | Task owner, task/session ID, allowed outcome, scope and expiry |
| Execution | Actual model, harness/adapter version, workload identity and process start identity |
| Authority | Principal, credential reference without value, effective policy reference, approval/exception scope |
| Attempts | Logical operation ID, distinct attempt IDs, parent/delegated task, retry and fallback relation |
| Decision | Resolved resource/action, allow/deny/error class, admission component and correlation ID |
| Effect | Receiver request/job/receipt ID, observed state/event and time; explicit unknown when unavailable |
| Evidence | Observer identity, capture interval/health, gaps, retention/access owner and payload-redaction policy |
| Completion | Completed, legitimate no-op, blocked, failed, cancelled or unknown; retained services/jobs and cost exposure |

Task disposition and effect disposition must remain separate. A task may fail after an external action succeeds. A cancelled local process may leave an accepted remote job. A no-op may be the correct answer for a read-only review. Define legitimate postconditions before the run rather than requiring every task to modify a file.

## Make the next decision from evidence

Record **enforcement**, **evidence quality** and **useful-task completion** independently. Missing capture is UNKNOWN. A known unauthorized effect is FAIL for a required prevention boundary. A NOT APPLICABLE result needs a scope reason. Do not turn 23 passing checks and one unexamined credential route into a high safety score.

Compare the same workflow under the official product configuration, an existing substitute and any proposed new resource. Measure setup time, denied legitimate work, interruptions, missed effects, unknown outcomes, resource overhead and maintenance—not merely the number of blocked commands. If the existing stack answers the review question clearly, use it.

The contribution worth testing is a repeatable explanation of **what ran, what changed, which authority allowed it, and what useful work remains**. A monitor, gateway, sandbox and reviewer record each answer part of that question. The composition and its evidence determine the claim.