Your telemetry toggle was a file access control

Claude Code read AGENTS.md only when telemetry was enabled. That is the finding. A file the agent is expected to load was read under one condition and skipped under another, and the condition that decided between them was the telemetry setting. The behaviour has been marked fixed. The fix closes the instance. It does not retire the class of error, and the class is what matters here.

Telemetry is an observability control. Its function is to report on the system. It is not an authorization control and it is not an access control. When the decision to read a file is bound to whether telemetry is on, the read is being governed by a signal that has no relationship to the read. That is a defect in the design of the control boundary, not a setting a user got wrong. The user changed one thing. The system changed two.

State the position plainly. A behaviour that should be governed by need was instead governed by a diagnostic toggle. Whether AGENTS.md carried anything security relevant in a given session is not confirmed. What is confirmed is that its loading depended on telemetry state. Any control whose enforcement point is an unrelated feature flag is not a control. It holds until someone flips the flag.

The observable behaviour had two states. With telemetry enabled, AGENTS.md was read. With telemetry disabled, AGENTS.md was not read. Same file. Same repository. Same user. The only variable that moved between the two outcomes was the telemetry toggle. The file’s contents were present in the agent’s operation in one state and absent in the other, and the deciding factor was observability.

What AGENTS.md contributes to the agent when loaded is not specified in this finding, so treat its contents as not confirmed. The confirmed behaviour is narrower and more important. The presence or absence of the file’s contents in the agent’s operation was a function of the telemetry setting. A user who turned telemetry off did not act to change which files the agent reads. The system tied those together anyway, so the input and the outcome diverged.

Telemetry itself did what telemetry does. There is no evidence in this finding that reporting broke, and none should be assumed. Whether this coupling changed output correctness, whether it was exploited, and how long it persisted are all not confirmed. The failure is specific and it is enough on its own. Access to a file tracked an observability control, and that binding was observable from outside the system by toggling one setting and watching whether the read occurred.

The read decision tracked exactly one input. Not the file. Not the user’s authorization. Not the repository state. The telemetry flag. When that flag was the only variable that changed the outcome, the flag was the enforcement point. The behaviour was a direct function of telemetry, which means whatever set telemetry state also set whether the file was read.

Two independent concerns were wired into one dependency. Telemetry answers whether the system reports on itself. Reading a configuration file answers whether that configuration should apply. Those are separate questions with separate owners and separate reasons to be on or off. In this behaviour they collapsed to a single switch. Controlling the observability setting controlled the file access, and there is no path in the finding by which the two could be set independently.

The direction of that coupling is the part that matters. Disabling telemetry is a privacy decision. In this system, that same decision suppressed the file read. The more restrictive posture produced the less complete configuration state, and the more permissive posture produced the fuller one. Access was scoped to a diagnostic toggle rather than to need. That is the mechanism by which least privilege breaks. Privilege bound to an unrelated flag is not granted by need and cannot be reasoned about by need. It follows the flag.

The mechanism is an access decision resolved against the wrong input. An agent reading a file is an access operation. It has a subject, the agent acting in the user’s context. It has an object, AGENTS.md. It has a decision that resolves to read or do not read. A sound decision resolves against properties of the subject and object: who is acting, what they are authorized to reach, what the operation needs. In this behaviour the decision resolved against none of those. It resolved against telemetry state. The input to the access decision was a property of the observability subsystem, which has no authority over the file and no relationship to the subject or object.

Once an access decision reads from an input, that input is part of the control. This is not optional. The enforcement point is wherever the deciding value lives, regardless of what the designer intended that value to mean. Telemetry was intended to answer whether the system reports on itself. In this behaviour it also answered whether a file loads. That second answer was never a stated purpose of telemetry, and that is the defect. An enforcement point that no one designed is an enforcement point that no one guards. Its state can be changed by anyone who can change telemetry, for reasons unrelated to access, with an effect on access that is not visible from the setting they touched.

Identity is the boundary, and here the boundary was drawn in the wrong place. The user’s authorization to read AGENTS.md did not change between the two states. What changed was a diagnostic toggle, and the file’s presence in the agent’s operation followed it. The effective boundary was not the user’s identity or grant. It was the telemetry flag. Whether any specific session’s AGENTS.md contents mattered is not confirmed. The mechanism does not depend on that. The mechanism is that need and access were decoupled, and a signal with no authority was inserted between them. When you can move the outcome of an access decision without touching the subject, the object, or the grant, the thing you moved is the control.

The pattern is an access or behaviour decision gated on a signal that carries no authority over that decision. It does not require telemetry specifically. It requires two concerns that share a code path but not a purpose, wired so that setting one silently sets the other. The observable signature is constant across instances of this mechanism. One setting has a documented effect and a second, undocumented effect. The operator changes the setting for the documented reason and inherits the undocumented one without notice.

The direction of the coupling is what makes this class dangerous rather than merely untidy. In this behaviour the more restrictive privacy posture produced the less complete configuration state. Disabling an observability feature suppressed a read. That direction means the safe-looking choice degrades the system quietly, and the operator who made it has no signal that anything else moved. A coupling that failed in the opposite direction, where the restrictive setting also restricted access, would still be a defect, but it would fail toward less privilege. This one failed toward a state the operator did not select and could not observe from where the setting sat.

A flag is a branch, and every branch is a place where one concern can be made to depend on another. When a single flag guards a block that contains both the reporting logic and an unrelated read, the flag governs both, and nothing in the flag’s name or documentation says so. The reported instance was marked fixed. The pattern is not closed by closing an instance, because the pattern is a design habit: resolving a decision against whatever value happens to be in scope rather than the value that holds authority. Every place that habit is repeated is another undocumented enforcement point waiting for someone to flip a setting.

The fix closed the reported behaviour. It did not establish the property that would have prevented it. State the property directly. An access decision must depend only on inputs that hold authority over that access: the acting identity, the grant, the need. Observability state is not one of those inputs. Any code path where a diagnostic setting changes what is read, executed, or reached is a defect on sight, whether or not it has produced a visible failure.

Controls that are not enforced are not controls, and a control whose enforcement point is an unrelated flag is not enforced. It holds until the flag moves. That is not a control. It is a coincidence with an expiry date. The requirement that must now be true is separation. The decision to report on the system and the decision to load configuration must resolve against different inputs and be settable independently, so that changing one cannot change the other. If they still share a switch, the defect is present regardless of the current default.

Whether this coupling was exploited, how long it existed, and whether it altered any output are not confirmed, and none of that changes the position. Least privilege is not a posture you claim. It is a property you can prove by showing that access tracks need and nothing else. In this behaviour access tracked telemetry, so the property did not hold. The instance is closed. The obligation is to find every other decision resolved against a signal with no authority over it, and to sever it, before the next flag becomes a boundary no one meant to draw.