A File Tool Has to Stop at the Boundary

A file tool can sound harmless because it only reads. That word describes the operation, not the authority. Without an exact grant and a declared boundary, a helpful local read can turn into ambient access to whatever happens to be nearby.

Current state

WTK treats package source as the place that declares what a running agent may use. A tool category is useful for discovery, but it is not an execution permission. A declared package needs a specific binding, an allowed operation, and an allowed location before a local tool can act.

Changes

One completed local host-tool cycle added that distinction for read-only file access. The package grant names the available operation and the permitted boundary. The host checks both before dispatching a request, and a connection must be verified before the binding is usable.

The cycle included one bounded local run that returned an in-scope result and one request outside the declared boundary that was blocked. The useful observation is not that file access is safe in general. It is that an executable permission can be narrower than a descriptive tool label, and that the narrowness can be enforced at the point of use.

Failures observed

An available connector can otherwise look ready before the package has authorized it. Read-only access can also exceed its intended scope if the request is checked only for the operation and not for the location.

Neither condition tells us whether ordinary operators will understand the boundary, whether every target can preserve it, or whether a package will use the tool well. It only names a failure mode that the completed local path was built to contain.

Assumptions removed

We cannot treat installation, discovery, or a successful connection check as a grant of authority. We also cannot treat read-only as a complete security boundary. The package must declare the exact capability, and the execution path must refuse requests beyond it.

Evidence

This is one completed engineering observation with a retained in-scope result and an out-of-scope refusal under a declared local boundary.

Limitations

This is not a controlled usability study, a cross-target comparison, or evidence that every file access request is safe. It does not establish general reliability, operator comprehension, or a maturity promotion.

Next hypothesis

The next test should hold one package grant fixed while projecting it into distinct target harnesses. Retain every authorization decision, permitted result, blocked request, and receipt. Then compare whether the same boundary survives without being widened, silently ignored, or mistaken for a qualification claim.