Week 8 self-check answer guidance

Use these explanations after your first attempt. Tie each conclusion to one observed effect and one limit.

Q1

The refusal invariant failed: a denied call must leave protected state unchanged. The message was right and the order of events was wrong. A response reports what the boundary said; only the effect list shows what it did.

Q2

No. The sentence is data on both surfaces and carries no authority on either. A model receives notes, tool results and the user's request as tokens in one context with no trustworthy mark of which text may grant permission, so imperative wording can shape its next proposal. The decision belongs to a controller that checks each proposed action against what the user authorized, after the proposal and before any effect.

Q3

The authorized read returned the text; the text steered a second proposal, export; the boundary answered tool_denied; and export was already in effects. The failure is between the proposal and the refusal: the effect was recorded before the permission check ran. Proposing export is not the failure; a model will sometimes propose it.

Q4

A permitted read_label must still return the supplied text and record only read_label. A deny-all patch passes every denied case while breaking the task the boundary protects; in the chain it shows as task_completed being false.

Q5

denied_unlisted still fails: delete_label is not export, so the call reaches the effect append before the later check refuses it. The contract is an allowlist, in which only read_label is permitted and every other name is refused before any effect. The chain only ever proposes export, so a patch written against that one attack passes it. Keep the case-by-case checks, including a tool nobody wrote down, as the regression.

Q6

Refused calls count against the attempt budget. After two refusals the third call returns budget_exhausted and effects stays empty.

Q7

No. The in-memory check covers dispatcher ordering only, and a process that bypasses the dispatcher is not constrained by it. The environment answers the credential question: inspect what the directory or container the agent runs in actually holds and can reach, meaning files, network and credentials. If no credential is present there, there is none to read.

Q8

The approval setting decides when a person is asked before a tool call. The environment decides what a command can reach whether or not anyone is asked. Switching prompts off removes the first control and leaves the second, so the second must be real. If the agent can edit its own settings, injected text can ask it to switch approval off, which is why that file belongs outside what the agent may write.

Q9

The package's identity and intended source, the exact version and lock digest, its transitive dependencies and what its install script does. A plausible name is data, and resolving it is already an effect.

Q10

Nothing about the dependencies: the scanner looked for a uv.lock, found none and audited nothing. Record the scan as "dependencies not scanned", with the command and date, and either supply a lock file the tool reads or use a dependency audit that fits the project. A zero next to "not audited" is not a clean result.

Q11

Pass ordinary JSON text with an in-memory recorder in place of the loader. The starter calls pickle.loads on caller text, so the finding is reachable without running any payload. Replace the loader with the data-only decoder and remove the import. A JSON-first, pickle-fallback parser still fails for two reasons: the file still imports pickle, and the verifier also sends six texts that are not JSON, each of which must raise an error without reaching a loader.

Q12

Record "needs more evidence" and name the missing fact: whether the optional extra is installed where the application runs. The deciding check reads that runtime, for example the install command that builds it and its installed distributions. A version in the range is a fact; on its own it makes the row neither exploitable nor safe.

Q13

Whether any code path reads, sends or compares the string as a credential decides the row, not how the string looks. If none does, record the search beside a narrow exception and rerun the scan. If one does, treat it as a hard-coded credential: move it out of the code, and if the value was ever real, revoke it and check the repository history.

Q14

The reproduction stays local and inert: its input stays in memory or goes only to a mock on 127.0.0.1, it reads no real credential, touches nothing outside its working directory and runs only against code on your own machine. Before describing it publicly, read the project's security policy; if it asks for private reports, report privately and keep the reproducer out of public issues and pull requests.

Spaced retrieval and transfer

Retrieval 1. Run the input the review names, an inactive owner trying to edit, against your change. Mark the finding confirmed if the edit is allowed, refuted if it is denied on the path the review describes, and cannot tell if you have no way to run it, naming the missing run.

Retrieval 2. The survival tells you that no test in the suite distinguishes the mutant from the original, so the suite has a gap at trailing characters. A test of an invalid input with a trailing character, expecting rejection, would notice it.

Transfer. Add a positive check that read_summary returns its text and records only read_summary, and keep the denied export and unlisted-tool checks. Change the allowlist before writing the handler.

Decision with sufficient evidence

You can accept the dispatcher claim for these inputs: the permitted read crosses the boundary, denied, unlisted and malformed attempts add no effect, and every attempt is counted. A claim about the environment needs its own evidence: what the directory or container holds and can reach. The in-memory result does not supply it.