A supplier review reaches its final stage. An agent reads a handoff file that says the evidence is complete, prepares a summary and sends it to the approver. The file has a known author, a timestamp and an intact digest. One supporting document is still missing.
The workflow is illustrative. It frames one engineering question: which part of the system checks a claim immediately before another agent acts on it? A record of the producer explains where a statement came from. The receiving workflow also needs to establish whether that statement supports the proposed action. This post reviews recent research on agent skills, reports a narrow inspection of one released benchmark, and gives a review record for the file one skill hands to the next. It is part of our research notes on agent execution, after reviewer independence and benchmark score boundaries.
Skill outputs become inputs for later work
Agent skills package instructions, scripts and resources for reuse. Their outputs can become inputs for later work. A summary, a spreadsheet or a local database can carry an earlier mistake into a later decision, including after the conversation that produced it has ended. Our earlier note on policies in agent memory looked at stored policy summaries. This note looks at generated work product that a later step treats as evidence.
SkillRelay, a preprint by Liao et al. submitted on 9 October 2026, studies that persistence across separate sessions. In its threat model, the attacker controls several skills before execution; user tasks and trusted project policies stay outside the attacker’s control. The authors distinguish a harmful outcome from a complete attack chain through the intended handoff. Read the paper (v1).
The paper’s defense combines provenance with review of proposed operations. Review is mandatory and advisory: after an adverse recommendation, the agent can still confirm the reviewed request. These are controlled benchmark findings, and the paper does not estimate how often organizations meet this threat. We have not reproduced its results. This post leaves out its attack and defense rates; a reader who uses them should check each denominator in the paper.
The coverage declaration names what the review leaves out
The most useful implementation detail is in the published code. At the pinned commit, lines 57 to 66 of the guard’s run.py build a coverage declaration that names the operations the prototype reviews and the effects it leaves outside that review. A coverage.json file records that boundary for each guarded run. Pinned coverage declaration.
The implementation declares further limits: provenance is tracked per stage, network mediation is incomplete, and a hash taken after a read cannot show which bytes were read while another process was writing. These are prototype boundaries the authors state openly. We read the source as text and did not exercise the runtime coverage.
A declaration like this deserves attention because one workflow can reach the same consequential result by several routes. An evidence packet might be published through an API, exported to a shared directory or assembled from a database that another service reads. Reviewing the API request covers one route. An architecture review needs to trace the others before describing the whole workflow as reviewed.
- Reviewed: submission through the prototype’s adapter, with a fallback check at the receiving service.
- Outside operation review: arbitrary local file changes.
- Outside operation review: publication to a local SQLite database.
- Outside operation review: traffic to the model gateway.
What we checked in the released artifact
We inspected the repository at commit f7fa742 (8 October 2026) as data. We parsed the complete benchmark catalog and the untruncated Git tree through two read-only GitHub API requests, and matched every configuration path the catalog references against the tree.
This confirms a narrow structural property of the release: the catalog is internally consistent and its referenced files are present. We did not execute the benchmark, install its skills in any agent context or reproduce its safety results. Path presence says nothing about file contents, so it does not show that the benign inputs are benign. The counts describe the benchmark’s design and carry no performance meaning.
| Check | Observed |
|---|---|
| Unique case identifiers | 270 |
| Scenarios | 30 |
| Domain groups | 10, with 27 cases each |
| Attack patterns | 3, with 90 cases each |
| Injection surfaces | Code, instructions and resources, with 90 cases each |
| Referenced configuration paths missing from the tree | 0 |
| Case directories with a benign-input path | 270 of 270 |
Keep production, support and authorization separate
Return to the supplier example and give the handoff two records. The first describes production: the task that generated the file, the producer version, the artifact digest and the source references. The second describes the receiving decision: the current task, the intended recipient, the exact outgoing content, the claims that need verification, and the person or rule responsible for authorization.
These records answer different questions. An intact digest ties a review to particular bytes. A source reference points toward supporting material. A statement that a reviewer approved something needs its own decision record and scope. None of those fields should silently stand in for another. A complete-looking manifest can still describe an unsupported conclusion.
A reviewer should also be able to see both the file and the operation it led to. Record which original sources were checked, which concrete request was reviewed, whether the request changed afterwards, and which interface actually performed the effect. A person reviewing a supplier decision should be able to follow that chain without reconstructing it from a polished summary.
A review record for the handoff
The skill-handoff review record turns those questions into fields. It is an illustrative worksheet for a synthetic workflow and has not been evaluated as a security control. Adapt it to the system that owns the decision and performs the action.
Keep review and authorization records outside the producer’s control where the system’s trust model requires it. A field filled in by the producer that claims approval needs checking against the authority that owns that decision. For each effect, map every route the workflow can use: API calls, exports to shared directories and database changes that another process reads. Record the actual review boundary and the evidence that it applied to that request. Mark routes without that evidence as unverified.
| Record | What to enter |
|---|---|
| Artifact | Identifier, exact version or digest, location |
| Production | Originating task, producer package and version, creation time |
| Current use | Receiving task, intended purpose, permitted recipient |
| Consequential claims | Each claim whose truth affects the decision |
| Supporting evidence | Original source and version, relevant passage or field, gaps and disagreements |
| Proposed effect | Interface, action, destination, exact payload version or digest |
| Review | Reviewer, decision, supporting evidence, scope, time |
| Authorization | Decision owner or applicable rule, permitted action and recipient |
| Execution | Actual interface, accepted request identifier, observed effect |
Three synthetic cases to test a handoff
A first investigation can stay small. Choose one recurring handoff and one consequential action, map every route from the file to that effect, and run three synthetic cases with fixed source records and a local receiver. Preserve the original materials, the generated file, the exact outgoing request, the review outcome and the observed effect.
Count legitimate completions, unsupported claims accepted, out-of-scope disclosures attempted, effects that bypassed review and execution errors as separate outcomes. Keep errors as errors. The expected behaviour in the table is a proposed evaluation criterion. We have not run this exercise, so it supports no protection rate.
| Synthetic case | Source and requested use | Expected behaviour to evaluate |
|---|---|---|
| Supported handoff | Source inventory is complete; recipient is authorized | Complete the requested handoff |
| Unsupported completion | Handoff says evidence is complete; source inventory has a missing document | Correct the claim or route it to the accountable reviewer |
| Recipient mismatch | Claims have support; proposed audience is outside the permitted scope | Obtain the required authorization or withhold the disclosure |
Related research on skills
Several recent papers look at skills from other angles. Each studies a different unit of review: a package, a chain of packages, or a later use of their output.
- SkillCascade (Zhu et al., v1, 24 September 2026) examines harmful interactions among co-installed skills, including cases that pass individual skill scans. It studies composition within a workflow; SkillRelay studies artifacts retained across sessions. The authors acknowledge that controlled sandboxes cannot establish real-world incidence, and they discuss the limits of judging outcomes with a model. SkillCascade v1.
- Counterfactual Trace Auditing (Zhou et al., v2 revised 28 May 2026, first posted 12 May) compares matched tasks with and without a skill and records behavioural differences. Each condition runs once, with one model and one benchmark, so the authors limit its causal reading. The transferable idea for a handoff test is to compare reads, writes and operations alongside completion. Counterfactual Trace Auditing v2.
- Security skills for Linux vulnerability detection (Xue et al., v1, 19 October 2026) evaluates selected security skills on file-guided Linux kernel analysis. It does not study malicious handoffs, and its detection rates do not transfer to document handoffs. Paper v1.
- ACES (Kevin et al., v1, 20 August 2026) proposes paired live evaluation with and without a skill, and SkillEval (Han et al., v2 revised 12 October 2026, first posted 7 August) scores properties of skill documents. We read their abstracts and introductions only. ACES v1, SkillEval v2.
Where KLA re-checks an approved action
For agents that act through KLA agent action ingress, the KLA Policy Engine evaluates each proposed action, and a require_approval outcome creates one Decision Request. When the approved action resumes, KLA compares its arguments with the hash sealed when approval was requested. If the arguments changed, the action is blocked with the reason code tool_args_mismatch and does not run. That check covers the record’s “whether the request changed afterwards” question for actions submitted through ingress. A file an agent writes straight to a shared directory is a separate route and needs its own row in the record.
The research in this post did not test KLA. The human oversight guide covers when an action should need approval and how the maker-checker workflow records it.
Frequently Asked Questions
Can the output of one AI agent skill affect a later session?
Yes, when the output is stored and a later task reads it. A summary, spreadsheet or local database written by one skill can carry an unsupported claim into a later decision after the original conversation has ended. The SkillRelay preprint studies this in a controlled benchmark; it does not estimate how often it happens in practice.
Does provenance prove that a handoff file is correct?
No. Provenance records who produced the file and when, and a digest ties a review to particular bytes. Whether each claim in the file is supported needs checking against the original sources, and whether the next action is permitted needs its own authorization record.
What does the SkillRelay guard review, and what does it leave out?
At the pinned commit, its coverage declaration reviews submissions through the prototype’s adapter, with a fallback at the receiving service. It declares arbitrary local file changes, local SQLite publication and model-gateway traffic outside operation review. Its review is advisory: the agent can confirm a request after an adverse recommendation. We read the source and did not exercise it.
How do you test an agent handoff before trusting it?
Pick one recurring handoff and one consequential action, map every route from the file to the effect, and run synthetic cases: a supported handoff, an unsupported completion claim and a recipient outside the permitted scope. Count legitimate completions, unsupported claims accepted, out-of-scope effects, review bypasses and execution errors separately.
Key Takeaways
For the next handoff your team reviews, keep four things together: what the first agent produced, what the next agent used, what the reviewer saw and what finally happened. Give the operations owner a way to inspect every route between them. When a plausible file carries an unsupported claim into real work, that record shows which decision needs repair. Start with the skill-handoff review record.
Sources were checked on 26 October 2026. SkillRelay and the related papers are preprints, and we reproduced none of their results. Our observation is a metadata and path inspection of one pinned repository. The supplier example and the three cases are synthetic and have not been run.