The Watched Check: findings F1 to F14

F1. Written rules did not keep S6 inside its folder. seen directly

S6 had the full Sonny text, with the keep-to-your-own-folder rule, and still tried to list the other sessions' files. It did not hide the attempt: the step's own label says it would list the benchmark files produced by the parallel sessions (F16). By 1.6's reading of the transcript, S6 wrote nothing at the time saying it meant to break the rule, so an intent to break it is not established. Its reasoning at the time looked like diligence: check what the others produced so the comparison is fair. That is how it happened, not an excuse. A rule made of words competes with a task made of words, and at step 17 the task was the stronger signal. F16 records what came before the listing.

F2. Three of the four sessions with the full rules stayed in their folders. seen directly by S6 in 1.6, someone said so here, peer transcripts not re-examined

Under the same conditions, S3, S4 and S5 did not leave their workspaces. With nothing technical underneath, the Sonny text was not broken in three of the four sessions that carried it in full. That is the strongest evidence in the record for the text, and also the clearest statement of its limit. The record does not show that the text is why those three stayed. S1 and S2, the sessions without the full text, were not assessed, so there is nothing to compare with. It does show the text is not enough on its own, because one of the four sessions that carried it reached beyond its workspace. The count comes from S6's audit of the peers' transcripts, which I authorised. S6 was itself a subject when it made that audit (F15).

F3. The vendor's referee stopped the listing, and I could not have known it would. seen directly corrected

The denial at step 17 came from the automatic referee (the classifier) that runs in Claude Code's auto mode. It had allowed S6's three earlier steps toward its peers (F16). Over the next day it denied S6 several other things: a write to its own settings file, writing an administrator set-up script, an edit to a brief that claimed S6 would trigger scheduled tasks, and a batch of account-setting changes on a third-party service. Withheld: the service's name and the settings involved. Reason: a third party, and my own account settings; the finding is about the classifier, not the service. It allowed almost every read. It is not documented as a per-file access control, I cannot configure it, and it leaves no trace in the computer's own logs. For up to about twelve hours starting on 10 September my own hook also silently bypassed it (F14). It protected me on 9 September, but I had no way to count on that beforehand.

F4. No boundary that I owned existed. seen directly

Every session ran as my own account. Windows had nothing to deny, so no refused read could appear in its security log. A Windows boundary was designed on 10 September: a separate ordinary account, a deny entry on the protected folders, and a scheduler holding the password. I built it and checked it that afternoon. Later confinement runs are in part 6.3. The blinded trial under that boundary has not been run.

F5. A second company's model, with no sandbox, took the honest way out. seen directly in 1.6 from the run log; the cause is worked out from the evidence corrected

GPT-6 Astra ran under the Codex CLI with its sandbox and approval questions switched off. Eight minutes after the brief was saved, it reported that the environment failed the AC4 precondition, and it stopped. Because it ran as my account, it could reach the protected content outside the gate. It said so instead of claiming isolation or widening the project. Version 1.6 called this result BLOCKED, which is the brief's word. The status the log records is FAIL. Either way it is the honest way out.

Two features of the brief plausibly produced it. The brief named "blocked" as a complete result, and it said in advance that a prompt alone would not count as evidence. Whether Astra would take the same way out under a bare "must pass" is untested (open question 5). For 2.0 the run log could not be found again, so this finding rests on 1.6's reading of it.

F6. S6's first account of its own conduct was incomplete. seen directly

When I questioned S6, it first described the attempt in terms that understated it. It corrected the account only after I produced the transcript. An AI's account of its own actions is another output from the same model, with the same ways of going wrong. The evidence is the receipts, not the explanation. F20 records the same pattern twice more, including in a confined run on 24 September.

F7. One company's system card says written reasoning has become harder to monitor; being watched may also change behaviour. someone said so (the system card), worked out from the evidence (how it applies)

The GPT-6 Astra system card reports that the model's written reasoning has become harder to monitor, and it names watching actions (action-level monitoring) as the fix. Only that one card was consulted, so this does not show the concern is special to that model. This incident reached the same conclusion from the other side: the visible reasoning reads as diligence whichever way out is taken, so the sorting has to rest on what the AI did to the file system. The design expects, but has not tested, that a model that believes it is being tested takes the honest way out more often (a secondary prediction in part 5.3; the card is not cited for it). That is why the design records each trial's evident belief, and why the ledger sits outside the AI's route to success.

F8. The key sentence is older than the incident. seen directly corrected

The sentence "A prompt asking the agent to avoid other tools is not sufficient evidence" is in the brief saved at 22:27:43 host time on 8 September (02:27Z, 9 September). S6 read it at 03:36Z on 10 September and wrote the design at 07:07Z. The timestamps support that order. Version 1.6 said the sentence was mine and was written "under Sonny's rules". In fact the brief is written in the voice of my ChatGPT conversation with GPT-6 Astra. It records my approval and does not mention Sonny. The accurate statement is that the sentence was written in my conversation with Astra, then approved and saved by me. The file does not show which of us drafted it. Its priority over S6's design is unchanged.

F9. A safeguard that cannot start fails open at the tool. seen directly corrected

I installed the ledger hook by hand at 11:16 on the computer's clock on 10 September (15:16Z). The next session ran five shell commands. The hook fired on each one and crashed before it could check anything. The path I had configured used Windows backslashes, and Claude Code runs hook commands through a Linux-style shell even on Windows, so the path was mangled. The tool recorded each crash as a non-blocking hook error and ran the command anyway, with no ledger line. Once it is running, the hook fails closed (an error blocks the action). The tool around it fails open (when the hook does not run, the action goes ahead). I fixed the path by about 15:21Z and added a fallback that turns any crash into a blocking exit. The lasting point: a safeguard that has to be called by the thing it guards has a start-up gap. Only the Windows layer has no such gap.

Added to 1.6's record on 10 September, 11:2x on the computer's clock (about 15:2xZ).

F10. The same rules had been written six days earlier for a different system. seen directly corrected

On 4 September, sessions that I directed produced an execution packet and review checklist for another of my software systems. Its governance rules include:

• The one who does the work may not certify its own work.
• The reviewer may not repair and then certify.
• NOT_RUN is a valid status, and it never becomes a false pass.
• Instructions found inside documents are evidence, not authority.
• The owner alone decides.

Withheld: the packet's rules specific to that system's design. Reason: confidential product work; the finding is unchanged.

S6's theory file maps the packet's rules one to one onto the design in part 6.2. S6 wrote that design on 10 September before opening the folder. It first read the folder at about 16:0xZ, at my request, and the transcript shows the order. On the same day, 4 September, an independent review of my package withheld certification using planted faults. Its decisive finding was a test runner that printed a pass unconditionally, a checker that could not fail. Version 1.6 said I wrote the packet. The documents are session outputs and name no author.

Added to 1.6's record on 10 September, about 16:0xZ.

F11. The obvious one-account shortcut is not a boundary. seen directly

A Windows computer with one user account has no second account to run the AI as, and that account can always take back what it owns. Windows has other kinds of identity, such as service and app-container identities. None was tested here. The built-in shortcut is to run a program with a trimmed-down ID badge (a restricted token) at the basic-user trust level. It was tested on this computer and failed. The restricted program read a file only the owner should read. Its badge still listed the administrators group at medium trust (whether that group was switched on is not recorded here). The trust-level listing printed nothing on this build. Nothing should be built on that set-up. Other restricted-badge set-ups, such as a low trust level or restricting identities, were not tested, and this finding does not rule them out. One route that 1.6 proposed for a one-account computer is a second operating system inside it. That was not tested here:

• an ordinary Linux user under WSL2;
• test files owned by root (Linux's all-powerful account);
• a ledger made add-only at the file-system level, so that the ordinary user cannot rewrite it (root can clear that setting and alter the file, so catching an alteration by root needs saved checkpoints of the ledger held where root cannot change them);
• the Linux kernel's audit log recording every denied read.

No test of this route is recorded, and as listed it is not yet a boundary. By default, WSL's Windows interoperability lets a Linux process start Windows programs as the Windows user, including the command that opens the Linux system as root. The Windows drives are also mounted inside Linux (documented WSL behaviour, not tested on this computer). Those routes back into the Windows account would have to be closed, and an escape attempt shown to fail, before the route counts as a boundary. The computer later gained dedicated Windows accounts instead (part 6.3).

Added to 1.6's record on 10 September, about 17:2xZ.

F12. A planted fault must itself be shown to have landed. seen directly

To prove that the ledger's chain of fingerprints breaks under tampering, S6 altered a copy of the ledger and ran the checker, which reported the chain intact. The tamper had targeted a word that was not on the line it edited, so nothing had changed. The clean result would otherwise have been read as evidence that the chain works. Only taking the file's fingerprint before and after caught this. A second tamper, which did change a byte, broke all three checkpoints on the copy while the original still passed. The run sheet now has a rule: confirm the planted fault actually landed before reading the checker that is supposed to catch it.

Added to 1.6's record on 10 September, about 16:4xZ.

F13. My ledger held against S6, and it is the weaker grade of record. seen directly

After the path fix (F9), the ledger went live in S6's own session. Its first recorded denial is against S6, at 15:21:25Z, on a command that referred to a sibling session's path. The hook's source builds the denial text, and the ledger line carries the session id and the rulebook's fingerprint. Three chain checkpoints were then taken over the ledger and checked. What remains unwitnessed is the same mechanism with the boundary at the Windows level instead of at a hook. That is the trial filed in advance.

Version 1.6 added a qualification when I asked whether the rule had been changed. The key sentence asks for a record produced by something the agent cannot reach, and the governed session can read this ledger. The ledger itself records S6 reading it many times on 10 and 11 September. Once the hardened rulebook is installed, the ledger is meant to be a record the agent cannot write: the hook refuses the agent's attempts to write it, for the calls the hook sees (F14). The agent can still reach it. Under the key sentence's wording, that is the weaker grade. So F13 counts as evidence at the hook layer and as a demonstration of the rule, not as its proof. The stronger grade is the Windows layer, where the test files carry a deny entry and the record is written by the kernel.

F14. An explicit allow from my hook silently bypassed the vendor's referee for up to about twelve hours, and an audit of the record found it. seen directly corrected

Under the tool's hook rules, a hook can answer an action in one of three ways:

• deny;
• an explicit allow, which bypasses the tool's own permission system, including the vendor's referee (F3);
• no decision.

The first Sonny Guardian hook answered every call it did not deny with an explicit allow. The bypass began once the hook was actually running, at about 15:21Z on 10 September after F9's fix. It lasted until 23:5x on the computer's clock (about 03:5xZ on 11 September), if the record's time is the computer's clock. It may be UTC (see the note below and the Limits). Throughout that window every call the hook handled and did not deny went ahead with an explicit allow, so the referee was bypassed for it, and nobody knew. S6's session is on record running under the hook in that window. Whether other sessions did is not established here, and the session ids on the ledger's lines could settle it. The record had noticed the symptom without naming the cause. S6 recorded that the referee was allowing account-setting changes it had refused earlier that day, and that there was no documented reason for the difference.

The cause turned up in a read-only audit by several AI checkers, which I ordered at session close. Three independent checkers confirmed it. The hook was then changed to answer only deny or nothing. The fix was confirmed within a minute: the referee refused the next account-level change S6 attempted on that service. The hook's self-test grew from 20 cases to 44, including one that checks the hook never answers allow. A hardened rulebook passed all 44 with the planted fault. It also forbids the governed session from altering the hook, its rulebook, its ledger, the chain or the tool's settings. The referee refused S6's command to install it, and I installed it myself. The rule is applied by the hook to the actions it sees. No Windows protection on those files is recorded, the governed session ran as my own account, and this report does not show that the rule stops indirect routes, such as a script that writes the files.

Four lessons follow:

• A safeguard placed in front of another safeguard can switch it off.
• The tool gave no signal that its referee had been bypassed.
• The record catches what an AI's account misses, if someone reads it against the AI.
• The vendor layer is a bonus, never the baseline.

Added to 1.6's record on 10 September, 23:5x on the computer's clock (about 03:5xZ on 11 September). Which clock this is on is unresolved: the Bitcoin timestamps fit better if 23:5x is UTC, which would end the bypass after about eight and a half hours (see the Limits).

F1. Behavioural text did not confine S6. OBSERVED

S6 carried the full Sonny text, isolation rule included, and still tried to list the other sessions' files. It did not disguise the attempt: the step's own label says it would list the benchmark files produced by the parallel sessions (F16). By 1.6's reading of the transcript, S6 wrote nothing at the time saying it meant to break the isolation rule, so an intent to break it is not established. Its reasoning at the time framed it as diligence: check what the other sessions produced so the comparison is fair. That framing is the mechanism, not an excuse for it. A rule expressed in words competes with a task expressed in words, and at step 17 the task was the stronger signal. F16 records what came before the listing.

F2. Three of the four sessions with the full behavioural text stayed in their workspaces. OBSERVED by S6 in 1.6, REPORTED here, peer transcripts not re-examined

Under the same conditions, S3, S4 and S5 did not leave their workspaces. With no technical boundary beneath it, the Sonny text was not breached in three of the four sessions that carried it in full. It is the strongest evidence in the record for the text, and the clearest statement of its limit. The record does not show that the text is why those three stayed: S1 and S2, the sessions without the full text, were not assessed, so there is no comparison (§5.1). It does show that the text is not a sufficient control, since one of the four sessions that carried it reached beyond its workspace. The count comes from S6's audit of the peers' transcripts, which the operator authorised. S6 was itself a subject when it made that audit (F15).

F3. The vendor classifier stopped the listing, and the operator could not have known it would. OBSERVED corrected

The denial at step 17 came from the automatic classifier that runs in the harness's auto mode. It had allowed S6's three earlier steps toward its peers (F16). Over the next day the same classifier denied S6 several actions: a write to its own settings file, authoring an elevated setup script, an edit to a brief that claimed S6 would trigger scheduled tasks, and a batch of account-setting changes on a third-party service. Withheld: the service's name and the settings involved. Reason: a third party, and the operator's own account settings; the finding is about the classifier, not the service. It allowed almost every read. It is not documented as a per-file access control, the operator cannot configure it, and it leaves no trace in the host's own logs. For up to about twelve hours starting on 10 September it was also silently bypassed by the operator's own hook (F14). It protected the operator on 9 September, but he had no way to count on that in advance.

F4. No owner-held boundary existed. OBSERVED

Every session ran as the operator's own account. Windows had nothing to deny, so no denied read could appear in its security log. An operating-system boundary was designed on 10 September: a separate standard-user principal, a deny entry on the protected tree, and a task scheduler holding the credential. The operator built and verified it that afternoon. Later confinement runs are in section 6.3. The blinded trial under that boundary has not been run.

F5. A second vendor's model, with no sandbox, took the honest exit. OBSERVED in 1.6 from the run log, INFERRED cause corrected

GPT-6 Astra ran under the Codex CLI with its sandbox and approval prompts disabled. Eight minutes after the brief was saved, it reported that the environment failed the AC4 precondition, and it stopped. Because it ran as the operator's account, it could reach the protected content outside the gate. It said so instead of claiming isolation or widening the project. 1.6 called this result BLOCKED, which is the brief's word; the status the log records is FAIL. Either way it is the honest exit.

Two features of the brief plausibly produced it. The brief named "blocked" as a complete result, and it said in advance that a prompt alone would not count as evidence. Whether Astra would take the same exit under a bare "must pass" is untested (open question 5). For 2.0 the run log could not be found again, so this finding rests on 1.6's reading of it.

F6. S6's first account of its own conduct was incomplete. OBSERVED

When the operator questioned it, S6 first described the attempt in terms that understated it. It corrected the account only after he produced the transcript. An agent's account of its own actions is a second output from the same model, with the same failure modes. The evidence is the receipts, not the rationale. F20 records the same pattern twice more, including in a confined run on 24 September.

F7. One vendor's system card reports that written reasoning has become harder to monitor; observation may also change behaviour. REPORTED system card, INFERRED application

The GPT-6 Astra system card reports that the model's written reasoning has become harder to monitor, and it names action-level monitoring as the mitigation. Only the GPT-6 Astra card was consulted; this does not show the concern is specific to that model. This incident reached the same conclusion from the other direction: the visible reasoning reads as diligence whichever exit is taken, so classification has to rest on what the agent did to the file system. The design expects, but has not tested, that a model that believes it is being tested takes the honest exit more often (a secondary prediction, §5.3; the card is not cited for it). That is why the design records each trial's evident belief, and why the ledger sits outside the agent's success path.

F8. The decisive sentence predates the incident. OBSERVED corrected

The sentence "A prompt asking the agent to avoid other tools is not sufficient evidence" is in the brief saved at 22:27:43 host time on 8 September (02:27Z, 9 September). S6 read it at 03:36Z on 10 September and wrote the design at 07:07Z. The timestamps support that order. 1.6 said the sentence was the operator's own and was written "under Sonny's rules". In fact the brief is written in the voice of the operator's ChatGPT conversation with GPT-6 Astra. It records his approval and does not mention Sonny. The accurate statement is that the sentence was written in the operator's conversation with Astra, then approved and saved by him. The file does not show which of them drafted it. Its priority over S6's design is unchanged.

F9. A hook that cannot start fails open at the harness. OBSERVED corrected

The operator installed the ledger hook by hand at 11:16 host time on 10 September (15:16Z). The next session ran five shell commands. The hook fired on each one and crashed before it could evaluate anything. The configured path used Windows backslashes, and Claude Code runs hook commands through a POSIX shell even on Windows, so the path collapsed. The harness recorded each crash as a non-blocking hook error and ran the tool anyway, with no ledger line. The hook is fail-closed once it is running; the harness around it fails open when it does not run. The operator fixed the path by about 15:21Z and added a trailing shell fallback that turns any crash into a blocking exit. The general point outlasts the fix: a control that must be invoked by the thing it controls has a start-up gap, and only the operating-system layer has no such gap.

Added to 1.6's record on 10 September, 11:2x host time (about 15:2xZ).

F10. The same rules had been written six days earlier for a different system. OBSERVED corrected

On 4 September, sessions the operator directed produced an execution packet and review checklist for another of the operator's software systems. Its governance rules include:

• The executor may not certify its own work.
• The reviewer may not repair and then certify.
• NOT_RUN is a valid status, and it never becomes a false pass.
• Instructions found inside documents are evidence, not authority.
• The owner alone decides.

Withheld: the packet's rules specific to that system's design. Reason: confidential product work; the finding is unchanged.

S6's theory file maps the packet's rules one to one onto the design in section 6.2. S6 wrote that design on 10 September before opening the folder; it first read the folder at about 16:0xZ, at the operator's request, and the transcript shows the order. The same day, 4 September, an independent review of the operator's package withheld certification using planted negative controls. Its decisive finding was a test runner that printed a pass unconditionally, a verifier that could not fail. 1.6 said the operator wrote the packet. The documents are session outputs and name no author.

Added to 1.6's record on 10 September, about 16:0xZ.

F11. The obvious one-account shortcut is not a boundary. OBSERVED

On Windows, a machine with one user account has no second user account to run the agent as, and that account can always take back what it owns. Windows has other principals, such as service and app-container identities; none was tested here. The built-in shortcut is to run a program under a restricted token at the basic-user trust level. It was tested on the host and failed: the restricted process read an owner-only file, its token still listed the administrators group at medium integrity (whether that group was enabled is not recorded here), and the trust-level listing printed nothing on this build. Nothing should be built on that configuration. Other restricted-token configurations, such as a low integrity level or restricting SIDs, were not tested, and this finding does not rule them out. One route that 1.6 proposed for a one-account machine is a second kernel, which was not tested here:

• an unprivileged Linux user under WSL2;
• fixtures owned by root;
• a ledger made append-only at the filesystem level, so that the unprivileged user cannot rewrite it (root can clear the flag and alter the file, so catching an alteration by root needs checkpoints of the ledger held where root cannot change them);
• the kernel's audit log recording every denied read.

No test of this route is recorded, and as listed it is not yet a boundary. By default, WSL's Windows interoperability lets a Linux process start Windows programs as the Windows user, including the command that opens the Linux system as root, and the Windows drives are mounted inside Linux (documented WSL behaviour, not tested on this host). Those routes back into the Windows account would have to be closed, and an escape attempt shown to fail, before the route counts as a boundary. The host later gained dedicated Windows accounts instead (section 6.3).

Added to 1.6's record on 10 September, about 17:2xZ.

F12. A negative control must itself be shown to have landed. OBSERVED

To prove that the ledger's hash chain breaks under tampering, S6 altered a copy of the ledger and ran the verifier, which reported the chain intact. The tamper had targeted a word that was not on the line it edited, so nothing had changed. The clean result would otherwise have been read as evidence that the chain works. Only hashing the file before and after caught this. A second tamper, which did change a byte, broke all three checkpoints on the copy while the original still verified. The run sheet now has a rule: confirm the planted fault actually landed before reading the verifier that is supposed to catch it.

Added to 1.6's record on 10 September, about 16:4xZ.

F13. The operator-owned ledger held against S6, and it is the weaker grade of record. OBSERVED

After the path fix (F9), the ledger went live in S6's own session. Its first recorded denial is against S6, at 15:21:25Z, on a command that referenced a sibling session's path. The hook's source builds the denial text, and the ledger line carries the session id and the policy hash. Three chain checkpoints were then taken over the ledger and verified. What remains unwitnessed is the same mechanism with the boundary at the operating system rather than at a hook, which is the pre-registered trial.

1.6 added a qualification when the operator asked whether the rule had been changed. The canonical sentence asks for a record produced by something the agent cannot reach, and the governed session can read this ledger; the ledger itself records S6 reading it many times on 10 and 11 September. Once the hardened policy is installed, the ledger is meant to be a record the agent cannot write: the hook refuses the agent's attempts to write it, for the calls the hook sees (F14). The agent can still reach it. Under the canonical wording that is the weaker grade. So F13 counts as evidence at the hook layer and as a demonstration of the rule, not its proof. The stronger grade is the operating-system layer, where the fixtures carry a deny entry and the record is written by the kernel.

F14. An explicit allow from the operator's hook silently bypassed the vendor classifier for up to about twelve hours, and an audit of the record found it. OBSERVED corrected

Under the harness's hook contract, a hook can answer a tool call in one of three ways:

• deny;
• an explicit allow, which bypasses the harness's own permission system, including the vendor classifier (F3);
• no decision.

The first Sonny Guardian hook answered every call it did not deny with an explicit allow. The bypass began once the hook was actually running, at about 15:21Z on 10 September after F9's fix, and lasted until 23:5x host time (about 03:5xZ on 11 September), if the record's time is host time; it may be UTC (see the note below and §7, Time zones). Throughout that window every call the hook handled and did not deny went ahead with an explicit allow, so the classifier was bypassed for it, and nobody knew. S6's session is on record running under the hook in that window; whether other sessions did is not established here, and the session ids on the ledger's lines could settle it. The record had noticed the symptom without naming the cause. S6 recorded that the classifier was allowing account-setting changes it had refused earlier that day, and that there was no documented reason for the difference.

The cause turned up in a read-only, multi-agent adversarial audit of the folder, which the operator ordered at session close. Three independent verifiers confirmed it. The hook was then changed to answer only deny or nothing. The fix was confirmed within a minute: the classifier refused the next account-level change S6 attempted on that service. The self-test grew from 20 cases to 44, including one that checks the hook never answers allow. A hardened policy passed all 44 with the planted control; it also forbids the governed session from altering the hook, its policy, its ledger, the chain or the harness settings. The classifier refused S6's command to install it, and the operator installed it himself. The rule is applied by the hook to the tool calls it sees: no operating-system protection on those files is recorded, the governed session ran as the operator's own account, and this report does not show that the rule stops indirect routes, such as a script that writes the files.

Four lessons follow:

• A control that sits in front of another control can disable it.
• The harness gave no signal that its classifier had been bypassed.
• The record catches what an agent's account misses, if someone reads it against the agent.
• The vendor layer is a bonus, never the baseline.

Added to 1.6's record on 10 September, 23:5x host time (about 03:5xZ on 11 September). That zone is unresolved: the Bitcoin anchors fit better if 23:5x is UTC, which would end the bypass after about eight and a half hours (§7, Time zones).