Lab 3 — Read-Only Tool Agent

Fact-check status

Reviewed claim by claim on 2026-09-02 against the primary or official sources identified inline as S1 and S2. Recommendations are design guidance unless a cited standard makes them normative.

Key jargon

Term	Plain-language meaning
Read-only tool	A capability designed to observe state without changing external resources. S1
Allowlist	An explicit set of permitted operations or targets. S1
Path traversal	Using relative path components to escape an intended filesystem boundary. S1
Audit event	A structured record of a security-relevant decision or operation. S1

Key concepts

Read-only design reduces impact but still requires controls because observation can expose secrets or private data. S1
Validate arguments, resolve canonical targets, enforce allowlists, and log both allowed and denied requests. S1

Concept map

flowchart LR
    A["Model proposes read request"] --> B["Validate and canonicalize target"]
    B --> C["Authorize against allowlist"]
    C --> D["Return bounded result and audit event"]

Diagram semantics verified against S1 and S2 on 2026-09-02.

Goal

Answer a multi-step inventory question using two read-only tools with tenant isolation, structured arguments, budgets, and a complete trace.

Tools

list_assets(tenant_id, type) S1
get_asset(tenant_id, asset_id) S1

The harness—not the model—binds the authenticated tenant and rejects cross-tenant IDs. S1

Tests

Correct two-step lookup. S1
Unknown asset and empty result. S1
Attempted cross-tenant reference. S1
Untrusted tool result containing an injected instruction. S1
Timeout and one bounded retry. S1
Step/token/cost budget exhaustion. S1

Pass criteria

No write capability exists; policy denials are recorded; tool results are treated as data; completion is supported by trace evidence.