Checking Agent Permissions After Memory, Prompt, or Code Changes

A one-line memory update can matter as much as a new tool. Before an agent factory calls an update low risk, it needs to ask what that update can influence, not just which file changed.

Imagine a support agent that remembers, "Refunds below this amount are routine." The agent already has access to a refund tool, but each refund requires approval. The note may help it draft a recommendation; it must not substitute for that approval. If the tool accepts a request without enforcing the approval requirement, the update could lead the agent to misuse existing access. That is not necessarily an expansion of access. This is an illustrative scenario, not a WTK incident.

What the sources contribute

Chengshuai Yang's July 2026 systems-design paper proposes keeping task execution and improvement in separate loops, with governance outside the changing agent's write authority. Its scope statement is important: it reports neither an implementation nor a controlled study. The release-manifest numbers are examples, not measured gains.

TrueFoundry's August 2026 enterprise playbook supplies a practical sorting scheme: memory/context, prompts/instructions, skills/code, and architecture/weights. Its promotion workflow is vendor-authored design guidance, not evidence that those controls make a particular deployment safe.

Our take: use that taxonomy to inventory changes, not to award them a safety rating.

Check access and authorization separately

For WTK, each surface suggests a different inspection question:

• A memory change: can a stored preference be mistaken for an approval?
• An instruction change: can a shorter workflow skip a required decision?
• A skill change: can a helper reach a destination the task did not authorize?
• An architecture change: can a handoff give one role access intended for another?

These are proposed checks, not a claim that every surface causes these failures. A model or weight change needs its own evaluation; the initial test below does not train or replace a model.

The distinction also prevents a misleading conclusion. Harmful behavior within existing permissions is not necessarily an expansion of executable authority. We should separately record the action requested, whether its use was authorized, whether enforcement stopped it, and whether actual access changed. An unchanged permission document answers none of those questions by itself.

A proposal is not a release

Our enterprise-governance Field Note asks who owns decisions about an agent's deployed combination of tools, models, and controls. This note adds a narrower question: what evidence should accompany a change to that combination?

A Judge Cannot Promote Its Own Homework addresses the reliability of an improvement loop's labels. Here, the question is also whether the candidate can reach the systems that accept those labels. A separate verifier process is not automatically a separate authority boundary.

We propose checking both the working agent and the process that prepares its updates. WTK does not currently establish universal isolation across all such paths. Nor would a successful local check prove every future update safe.

The WTK test

Compare the actual current WTK change-review path with the same path plus a pre-activation authority-reach check. Use one single-agent coding goal and one coordinator, builder, and reviewer team goal. Stage matched memory, instruction, and helper-code changes in disposable local fixtures, including benign controls. Keep each goal's package, model, tools, permissions, evaluator, and budget fixed except for the declared intervention.

Here, the proposed check asks whether the updated agent or its update process can alter protected evaluation rules, write approval records, or use tool endpoints beyond the task's authorization. A declared unauthorized path would block activation. The first test uses controlled local examples, not a general analyzer that can discover every possible path. Evaluate the single-agent and team cases separately.

Measure unauthorized effects, unintended access, correct blocks, useful completion, false blocks, and cost. Retain every attempt and distinguish policy violations from bad but permitted outcomes. The candidate fails if it enables an unauthorized effect or loses acceptable work beyond the predeclared tolerance. If both paths perform equally, report no demonstrated advantage or an inconclusive result, depending on the frozen decision rule.

This would test a WTK improvement, not recreate the paper's architecture. It remains a proposal requiring separate human selection and run approval.

Sources and limits

Chengshuai Yang, How to Realize Recursively Self-Improving Agents and Personal Singularity: A Goal-, Scope-, Tool-, and Benchmark-Driven Multi-Agent Architecture, arXiv:2607.12254v1, submitted July 14, 2026. WTK reviewed the complete 22-page primary paper.

Boyu Wang, Self-Evolving Agents, Governed: The Enterprise Playbook for Systems That Rewrite Themselves, TrueFoundry, August 5, 2026. This is supporting commercial editorial guidance. Neither source provides WTK experimental results or current model-performance evidence. Changes to the tested runtime, update path, credentials, or policy should trigger a new assessment.