§11: Resource scope checks MUST use the resolved form of the identifier (closes the path-traversal gap from #29)

[murilomartins-tech]

Context

In #29 I reported a traversal case: a resource identifier such as posix:///workspace/123/../456 passes a prefix check against a scope of posix:///workspace/123/ while it actually resolves outside that scope.

@astrogilda recorded it in probityai/agent-evidence-vectors#60, but it sits in the awaitingText list: the spec pinned by the corpus (9d4a9da) fixes the URI form of a resource identifier (§11, "Resource identifiers MUST use URI form") with no requirement to check its resolved form against a granted scope. Without a normative sentence, the negative vector, its positive control and the unresolvable case cannot become corpus members.

This Discussion proposes that sentence, as the first step before a type:proposal issue and a PR against integration. I understand negative conformance vectors are deferred to v0.2.0 (#53); the aim here is to get the normative text agreed so the vectors are ready when that work lands.

Proposed normative text (new §11.x, "Resource scope matching")

R1. Before comparing a resource identifier against any granted scope, policy prefix, or intent scope (§8.4, §9.1), the Guardian MUST compute its resolved form: percent-decoding applied exactly once, dot-segments removed per RFC 3986 §5.2.4, and scheme and host lowercased.

R2. The comparison MUST be performed on the resolved form only. The identifier as submitted MUST NOT be used for the scope decision.

R3. Prefix matching MUST respect path-segment boundaries: a scope /a/b matches /a/b and /a/b/..., and MUST NOT match /a/bc.

R4. If the Guardian cannot establish the resolved form with certainty (for example, the path crosses a symbolic link or mount point the Guardian cannot inspect), it MUST NOT return ALLOW. It MUST return DENY with reason code resource_unresolvable, or DEFER with reason insufficient_context.

A resource whose resolved form falls outside every granted scope MUST be denied with reason code resource_out_of_scope.

Nothing new goes on the wire: the two values ride the existing DENY reason_codes element (§6), and the §17.1 error registry stays unchanged, since these are policy outcomes, not protocol errors.

Vectors this text makes citable

Scope for all cases: posix:///workspace/123/

#	Resource	Expected	Cites
1	posix:///workspace/123/../456/secrets.txt	DENY resource_out_of_scope	R1, R2
2 (positive control)	posix:///workspace/123/./docs/../notes.txt	ALLOW (resolves to /workspace/123/notes.txt)	R1, R2
3	posix:///workspace/123/%2e%2e/456	DENY resource_out_of_scope	R1
4	posix:///workspace/1234/file.txt	DENY resource_out_of_scope	R3
5	posix:///workspace/123/link/data where link is a symlink the Guardian cannot resolve	DENY resource_unresolvable or DEFER insufficient_context, never ALLOW	R4

Cases 1 and 2 are the negative vector and positive control from #29; case 5 is the unresolvable verdict.

Open questions

1. Should R1 also normalize Windows forms (file:///C:/..., backslashes, case-insensitive drive letters), or should that be left to a platform profile?
2. Should R4 prefer DENY or DEFER by default? I lean towards DENY (fail-closed), with DEFER allowed only when an ASK path exists.

If the direction looks right, I'll open the type:proposal issue linking this thread and follow with a PR against integration.

cc @astrogilda — related: #29, #53, probityai/agent-evidence-vectors#60

[avp9-nexus]

The direction looks right to me, and R1 to R3 are things a Guardian can do from the identifier alone. R4 is where I think the text needs one more fact.

Nothing in ACS gives a Guardian a view of the Observed Agent's filesystem. toolCallRequest fires "after the framework has parsed a tool call from the LLM's output, but before the tool is dispatched to its handler" (hooks.md), and nothing in the envelope says whether a segment of the path is a symlink or a mount point. So from what it receives, a Guardian cannot establish the resolved form "with certainty" for any filesystem path: read literally, R4 applies to every one of them, or a Guardian claims a certainty it has no basis for.

The fact exists on the Observed Agent's host, before dispatch, and it is lost if the framework does not send it, which is the proposal form's test for putting something on the wire. The framework would resolve the identifier before the hook fires and send the resolved form beside the argument, filled by deterministic framework code as provenance is, never by the model. #232 proposes an optional resource URI on toolCallRequest; the resolved form could ride it or a sibling member. R4 then has something to test: no resolved form from the framework, no ALLOW on a scope decision.

On your second question, I would take DEFER for the unresolvable case. Its timeout_decision already defaults to deny, so it fails closed, and it keeps the split #53 asks for between evidence measured and found wrong, your resource_out_of_scope, and evidence that could not be measured.

One limit worth stating in the text: the path can change between the check and the dispatch, for example a link swapped in between. These rules narrow the gap between what the policy reads and where the action lands; they do not close that race.

Avp9.

[murilomartins-tech]

Thanks, @avp9-nexus. You're right on R4, and it also corrects a line in my post: "nothing new goes on the wire" doesn't hold for filesystem identifiers. The fact R4 needs exists only on the Observed Agent's host, so it has to travel.

Revised R4

R4. For an identifier whose resolution depends on the Observed Agent's filesystem (symbolic links, mount points), the resolved form is established by the framework, not inferred by the Guardian. Before toolCallRequest fires, the framework SHOULD resolve the identifier and send the resolved form beside the argument, populated by deterministic framework code as provenance is, and never by the model. A Guardian MUST NOT return ALLOW on a scope decision for such an identifier unless the request carries a framework-supplied resolved form; R2 and R3 then apply to that form. If the resolved form is absent, or the framework reports that it could not resolve the identifier, the Guardian MUST return DEFER with reason insufficient_context.

R1 to R3 stay as written, since they only need the identifier.

Wire slot. I'll align with #232 rather than add a second shape: the resolved form rides its optional resource URI on toolCallRequest, or a sibling member if #232 keeps that field for the submitted form only. I'll follow whatever #232 settles on.

DENY or DEFER. Agreed on DEFER. With timeout_decision defaulting to deny it fails closed, and it keeps the split #53 asks for: resource_out_of_scope for evidence measured and found wrong, insufficient_context for evidence that could not be measured. I'll drop resource_unresolvable.

Stated limit (non-normative note).

These rules narrow the gap between the identifier the policy evaluates and the object the action reaches. They do not close the time-of-check to time-of-use race, for example a link swapped between the check and the dispatch. Frameworks SHOULD dispatch using the same resolved form they reported.

Vector changes

#	Resource	Expected	Cites
5 (revised)	posix:///workspace/123/link/data with no framework-supplied resolved form	DEFER insufficient_context, never ALLOW	R4
6 (new)	posix:///workspace/123/link/data, framework-supplied resolved form posix:///etc/data	DENY resource_out_of_scope	R2, R4

Case 6 is the one that actually needs the new slot: the submitted identifier passes R1 to R3 and only the resolved form shows it leaves the scope.

The Windows question (R1 normalization for file:///C:/..., backslashes, drive-letter case) is still open. My inclination is to leave it to a platform profile and keep R1 to RFC 3986 forms.

Unless there's an objection, I'll open the type:proposal issue with this text, linking this thread, #29, #53, #232 and probityai/agent-evidence-vectors#60, then follow with a PR against integration.

[avp9-nexus]

Agreed with the revised R4, and the dispatch sentence in the note is a good addition.

One interaction to check before the issue. §6 bounds cascading deferrals per session, and §9.2 counts a substituted DEFER toward that limit; an R4 DEFER would presumably count the same way. A framework that never supplies the resolved form would then turn every filesystem scope decision into a DEFER until the bound is reached. §9.2 already draws the line for approvers: DEFER when the issue might resolve, DENY with a reason code when no recovery path exists, the Guardian knowing the client's capability by deployment-defined means. The same split would fit R4: DEFER insufficient_context when a resolution failed, DENY when the deployment's framework does not supply resolved forms at all, which would bring back a code like resource_unresolvable for that case only.

Avp9.

[murilomartins-tech]

Good catch, @avp9-nexus. Checked against the text: §6 bounds cascading deferrals per session, and §9.2 item 1 counts a substituted DEFER toward that limit, so a framework that never sends the resolved form would burn through the bound on filesystem scope decisions alone. A DEFER there also promises a recovery that can't come.

Taking the §9.2 split as you suggest. R4, final form for the issue:

R4. For an identifier whose resolution depends on the Observed Agent's filesystem (symbolic links, mount points), the resolved form is established by the framework, not inferred by the Guardian. Before toolCallRequest fires, the framework SHOULD resolve the identifier and send the resolved form beside the argument, populated by deterministic framework code as provenance is, and never by the model. A Guardian MUST NOT return ALLOW on a scope decision for such an identifier unless the request carries a framework-supplied resolved form; R2 and R3 then apply to that form. Otherwise the Guardian MUST return one of:

1. DEFER with reason insufficient_context and timeout_decision: "deny": when the framework supplies resolved forms but did not supply one for this request, or reported that it could not resolve the identifier. The verdict counts toward cascading-deferral limits (§6).
2. DENY with reason_codes: ["resource_unresolvable"]: when the deployment's framework does not supply resolved forms at all, so no recovery path exists. The Guardian determines this by deployment-defined means, as for approver capability (§9.2), and MUST record the denial as an audit event so the enforcement gap is visible.

The audit-event line is borrowed from §9.2 for the same reason it exists there: a deployment running without resolved forms should show up in the record, not only in the denial rate.

Vector changes

#	Resource	Deployment	Expected	Cites
5a	posix:///workspace/123/link/data, no resolved form in the request	framework supplies resolved forms	DEFER insufficient_context, timeout_decision: deny	R4.1
5b	posix:///workspace/123/link/data, no resolved form in the request	framework does not supply resolved forms	DENY resource_unresolvable	R4.2
6	posix:///workspace/123/link/data, resolved form posix:///etc/data	framework supplies resolved forms	DENY resource_out_of_scope	R2, R4

5a and 5b share the request and differ only in deployment configuration, which is the point: the verdict depends on whether a recovery path exists, not on the identifier.

I'll open the type:proposal issue with this text next, linking this thread, #29, #53, #232 and probityai/agent-evidence-vectors#60.

[murilomartins-tech]

Opened as #295 with the final R1 to R4, the note, and vectors 1 to 6 (5 split into 5a and 5b). Filed as deferred and tracked, since the vectors belong to #53. Thanks again, @avp9-nexus.