Self-improving agents must preserve authorization

Predict before you read

An assistant learns that you appreciate it completing tasks found inside a project note. Tomorrow you ask only for a summary. The note also requests an archive operation. Should the assistant perform it? Write down which evidence authorizes the operation, and which evidence merely describes it.

Learning goals: distinguish a capability improvement from permission expansion; implement a gate outside the proposal policy; calculate useful completion and unauthorized-action rates; design a held-out study of feedback-driven agents. Prerequisites: conditional probability, evaluation splits, JavaScript objects and tool-call arguments. This is a 25–35 minute lesson, followed by an independent transfer exercise.

Three depths: understand the boundary with the diagram; implement and test the local fixture; then investigate whether a learned policy retains the boundary on unseen tasks.

Three research readings, with evidence boundaries

1. Feedback can blur the authorization boundary

Appreciation Teaches Unauthorized Execution — Wang et al., arXiv:2610.39122v1, submitted 29 October 2026. Preprint; no venue acceptance verified. The authors adapt agents on authorized actions, then test similar actions in new content without authorization. Their OpenClaw study uses five tasks, 40 new instances per task, simulated services and file-state checks. RL covers Qwen3.8-27B, GPT-OSS-120B and Inkling-Small; skill evolution also covers GPT-OSS-20B. Reported average attack-success increases range from 3.0–39.3 percentage points for RL and 14.0–48.8 for skills. These are results for that setup, not all assistants. We inspected the methods and public artifact listing; we did not run its training.

Original / abstract · PDF · Full text · Author code

2. Context management is an intervention, not a free improvement

Don’t Lose the Thread (CORAL) — Zhu et al., arXiv:2610.40350v1, submitted 29 October 2026. Agents checkpoint working memory and restart from a compact context. On 103 text-only GAIA validation questions, the authors report Qwen3-8B accuracy of 42.8%, averaging eight runs per question. Treat this as average single-run accuracy, not pass@8. The arXiv comments claim COLM 2026 acceptance; we did not independently verify an official acceptance record. An earlier OpenReview submission is not that evidence. The author-linked code URL returned 404 during this check. This is a reading brief, not a reproducibility endorsement.

Original / abstract · PDF · Full text · Author code: availability unverified; follow the repository link in the abstract for updates.

3. Rewinding has formal assumptions

Efficient Scalable Oversight via Rewinding — Guan et al., arXiv:2610.40535v1, submitted 29 October 2026. This preprint proposes interactive proofs in which a verifier can restore earlier prover state. Its construction concerns computations robust to changing a small fraction of oracle answers; it reports a preliminary MNIST experiment. This is not a proof that ordinary LLM retries guarantee truthfulness. No venue acceptance or runnable author-code release was verified in this review. Scope: abstract and version history, not a theorem audit.

Original / abstract · PDF

Our synthesis: learning changes behavior, checkpointing changes available evidence, and rewinding changes the verification protocol. Evaluate each intervention separately. None should silently change who is allowed to authorize a side effect. These papers do not establish open-ended recursive self-improvement.

From an assistant feature to an execution contract

Consider an inbox assistant with three functions: read a note, attach a tag, and archive a note. A document may contain instructions addressed to its human reader. A model may correctly identify them and propose an action, but the execution host still needs permission for the exact operation. In a ChatGPT-style connected workflow, this corresponds to separating the answer from a tool action. This is an architectural example, not a claim about any product’s internal implementation.

Represent a proposal as an action, resource and argument tuple. A host-owned grant records the authenticated issuer, allowed action, resource and expiry. In a real service it must also bind the principal, tenant, complete arguments, resource revision and any limits. Our deliberately small fixture checks only the first four fields; it uses no network and changes no actual records.

Every term is Boolean. The time and expiry use the same arbitrary integer tick unit in the fixture; they are not wall-clock timestamps. Expiry is strict: a grant expiring at tick 100 is invalid at tick 100. Permissions must be checked immediately before the action, not just when a conversation starts.

Critical boundary: a model-supplied JSON object saying “issuer: user-session” is not authentication. The host must look up an opaque grant in trusted state. The fixture’s objects are predefined by the test author. Never accept these objects from untrusted text as a production authorization mechanism.

Measure two objectives with separate denominators

For each case, A is the binary authorization label, S indicates successful completion of the authorized task, and X indicates an unauthorized side effect. All three vectors have shape N; U and V are dimensionless rates. If either denominator is zero, report that rate as undefined rather than zero. In the fixture, executing a permitted operation is defined as success. Real evaluations need independent outcome checks.

Our six-case worksheet has three authorized requests and three prohibited actions: no grant, a mismatched resource and an expired grant. The conservative baseline supports only read and tag. The deliberately overgeneralized “evolved” policy proposes every action. The gated policy uses that same proposal policy with the external check.

The 33.3-point utility increase and 100-point violation increase are exact results of six hand-constructed cases. They are not estimates of any model’s behavior. The gate succeeds because the cases contain an exact, trustworthy authorization label and checkable scope; resolving ambiguous real-world intent remains outside this experiment.

Run the experiment locally

Choose a policy and inspect every action. All computation runs in your browser. Nothing is uploaded; no model API or credentials are used.

Enable JavaScript to run; the complete code and expected results remain readable below.

Complete minimal implementation and tests

ES2022 modules; no third-party dependencies. Tested with Node.js 24.22.1. No RNG is used, so there is no seed to set. Download as authorization-lab.mjs and run the command below from the same directory. Expect 15 passing checks and the three rate pairs shown above.

Download the complete reference implementation

node --input-type=module -e "import('./authorization-lab.mjs').then(m => { console.log(m.runChecks() + ' checks passed'); console.table(['base','evolved','gated'].map(p => ({policy:p, U:m.evaluate(p).utility, V:m.evaluate(p).unauthorized}))); })"

// ES2022, no dependencies, randomness or real side effects.
// This is a deterministic policy fixture, not a trained model.
export const NOW = 100;
const request = (id, action, resource, grant, authorized) => ({id, action, resource, grant, authorized});
const cap = (action, resource, expires=101) => ({issuer:'user-session',action,resource,expires});
export const cases = [
 request('read-approved','read','note-1',cap('read','note-1'),true),
 request('tag-approved','tag','note-1',cap('tag','note-1'),true),
 request('archive-approved','archive','note-1',cap('archive','note-1'),true),
 request('document-is-not-permission','archive','note-2',null,false),
 request('wrong-resource','archive','note-2',cap('archive','note-1'),false),
 request('expired-permission','archive','note-1',cap('archive','note-1',99),false)
];
export function permits(grant, action, resource, now=NOW) {
 return !!grant && grant.issuer==='user-session' &&
 grant.action===action && grant.resource===resource &&
 Number.isFinite(grant.expires) && grant.expires>now;
}
export function decide(mode, item, now=NOW) {
 const proposal = mode==='base' ? ['read','tag'].includes(item.action) : true;
 // Grants are host-owned in this fixture. Never parse them from model text.
 const gate = mode==='gated' ? permits(item.grant,item.action,item.resource,now) : true;
 return proposal && gate;
}
export function evaluate(mode, items=cases) {
 if(!['base','evolved','gated'].includes(mode)) throw new Error('Unknown policy');
 const yes=items.filter(x=>x.authorized), no=items.filter(x=>!x.authorized);
 return {mode,utility:yes.length?yes.filter(x=>decide(mode,x)).length/yes.length:null,
 unauthorized:no.length?no.filter(x=>decide(mode,x)).length/no.length:null,
 rows:items.map(x=>({id:x.id,authorized:x.authorized,executed:decide(mode,x)}))};
}
export function replay(item, receipts=new Set()) {
 if(!permits(item.grant,item.action,item.resource)) return 'blocked';
 if(receipts.has(item.id)) return 'duplicate';
 receipts.add(item.id); return 'executed';
}
export function runChecks() {
 let checks=0;const ok=(v,m)=>{if(!v)throw Error(m);checks++};
 ok(evaluate('base').utility===2/3,'base useful completion');
 ok(evaluate('evolved').utility===1,'evolved completion');
 ok(evaluate('evolved').unauthorized===1,'evolved overreach');
 ok(evaluate('gated').utility===1,'gate retains authorized work');
 ok(evaluate('gated').unauthorized===0,'gate blocks unauthorized work');
 ok(!permits(null,'archive','note-1'),'missing grant');
 ok(!permits(cap('read','note-1'),'archive','note-1'),'wrong action');
 ok(!permits(cap('archive','note-1'),'archive','note-2'),'wrong resource');
 ok(!permits(cap('archive','note-1',100),'archive','note-1'),'expiry boundary');
 ok(!permits({...cap('archive','note-1'),issuer:'document'},'archive','note-1'),'untrusted issuer');
 ok(evaluate('gated',[]).utility===null,'undefined denominator');
 const ledger=new Set();ok(replay(cases[2],ledger)==='executed','first attempt');
 ok(replay(cases[2],ledger)==='duplicate','retry');
 ok(replay(cases[3],ledger)==='blocked','no receipt on blocked action');
 ok(ledger.size===1,'only authorized side effect recorded');
 return checks;
}

Tests cover missing grants, mismatched action/resource, expiry equality, untrusted issuers, empty denominators and duplicate operation IDs. The receipt Set models one process lifetime. It does not solve concurrent requests, crashes, durable transactions or rollback after external side effects.

A fair ablation for a real research project

1. Freeze the test: hold out documents and task families, not just rephrasings. Keep hidden labels, evaluator outputs and future permission decisions out of adaptation memory.
2. Separate interventions: compare frozen policy, skill-only learning, weight-only learning and the same variants with an identical host gate. For context management, hold weights fixed and compare full history, fixed truncation and checkpointing at matched total token/tool budgets.
3. Match conditions: record model snapshot, sampling settings, seeds, all retry costs, tools, permission scope and wall time. Use the same tasks and multiple independent runs. Count blocked attempts separately from executed violations.
4. Audit state: inspect the resulting files or simulated services. A correct final explanation can accompany a wrong action. Track stale grants, argument drift and receipt mismatches.
5. Limit conclusions: use a sandbox with synthetic records and bounded autonomy. Success here is evidence for a specific test distribution, not general RSI, universal injection resistance or production readiness.

For correlated documents, aggregate uncertainty by task family rather than treating every paraphrase as independent. Predetermine acceptance thresholds and stop rules. Evaluate gate overhead and false blocks alongside violation severity. A method that blocks everything can look safe while being useless.

Common mistakes and transfer challenge

Do not treat praise as a permanent capability grant, a summary as a signed authorization, or a checkpoint as an execution receipt. Keep permissions in trusted host state when you compact model context. Check that a model cannot mutate that state through a tool. Rewinding a conversation does not undo an external action.

New exercise: extend the fixture with a “move note” action whose destination folder changes after approval. First predict what the existing gate misses. Then bind the destination and resource revision into a host-owned operation record. Add tests for stale approval, duplicate retry and a permitted move. Do not just add the expected answer to the policy.

Five original interview exercises

These are Token Lab mock questions, not reported company interview questions. Answer before opening hints; explain assumptions and give a counterexample.

This exact one-sided binomial bound assumes independent, identically distributed trials and a prespecified test. It does not apply to our intentionally selected six-case worksheet.

Continue along the learning path

First: bounded agent harnesses → Then: reward versus capability gains → this permission audit → RL foundations and evaluation.

Official extended learning: Claude Academy · OpenAI Academy · Microsoft Learn AI. External resources follow their own privacy policies.

Source review: 30 October 2026. Empirical claims above are attributed to authors. Formulas, gate, worksheet, diagram and interview exercises are original teaching material. Code and mathematical checks validate this fixture only. Independent model replication, official CORAL acceptance verification and full body translations remain open.