Guardrails & execution boundaries

A refusal is one layer, not the security boundary

Several Phase 2 configurations stopped at provider safety boundaries. That is an observation about those runs, not a guarantee that every future request will be refused. The correct engineering response is to enforce authorization outside the model as well as using provider controls.

A secure harness assumes that the model can misunderstand scope, misread a tool response or follow an untrusted instruction. It therefore validates each requested action against a policy it cannot rewrite. Scope should be machine-readable and tied to real execution permissions, not a sentence in a system prompt.

A policy decision needs concrete inputs

An allowlist is not only a text comparison. Hostnames can resolve differently, redirects can leave scope and tool arguments can introduce unintended destinations. Validate the effective operation, and keep network restrictions as a backstop. Default-deny is easier to reason about than trusting a model to enumerate every forbidden action.

Treat retrieved content as data

A web page, README or tool description can contain instructions aimed at the model rather than relevant task data. Quoting “ignore previous instructions” inside target content must not grant it authority. Preserve provenance so the harness and reviewer know whether text came from the user, the trusted policy or an untrusted target.

Do not give a worker access to unrelated credentials merely because it may need to inspect a page. Use scoped tokens, separate identities and short-lived secrets. Keep a secret out of a context when the task does not require it. Redaction after the fact is less reliable than limiting access before execution.

Approval should describe the actual action

A useful approval request names the target, exact operation, expected side effects, data involved and stopping condition. “Allow the agent to finish” is too broad. If parameters materially change after approval, request a new approval rather than treating an old one as a blanket grant.

Keep human-finished actions separate in the evaluation record. An analyst may legitimately take over an authorized lab task, but the outcome should still distinguish what the agent accomplished. Never teach provider-safeguard circumvention as the recovery method for a blocked workflow.

Test the boundary with harmless fixtures

Use a deterministic mock tool to test rejected destinations, unknown arguments, expired approvals and budget exhaustion. The fixture can return synthetic HTTP observations without any network access. Verify that the controller denies unsafe inputs even if the model’s explanation sounds confident.

Then test the real isolated runtime with a non-sensitive operation and confirm the expected logs. A policy document that is never connected to execution is not an enforced control. A successful positive test is incomplete without negative tests showing that prohibited operations are actually blocked.

Checkpoint

An agent says a destination is “owned by the client,” but it is absent from the signed scope. Should the tool execute? No. An assertion generated by the worker cannot extend its authority. Stop and obtain an explicit scope update through the trusted approval process.

References & source notes

Source mapping: supplied report, pp. 27–40, 45–50. Read the full bibliography and editorial notes, or find a tool in the upstream reference catalogue.