fix(kb): term:tier told every AI session a typo grants shell - #678
Merged
Conversation
`term:tier` is shipped guidance about a SECURITY control, delivered to AI
sessions as authoritative. It stated:
(lowercase values only — an unrecognised value currently falls back to shell)
Both halves are false, and the first is false in the least safe direction.
`config.rs:754` errors with "unknown AI permission tier" on an unrecognised
value — MAE refuses to start rather than resolving it to anything. There is
even a test at `config.rs:1822` asserting an unknown tier "must be rejected,
never resolved". The node was describing the former BUG as current behaviour,
so an agent reading it would believe a typo in `auto_approve_tier` silently
grants shell.
The second half is wrong too: `PermissionTier::parse` (`crates/ai/src/types.rs:66`)
does `s.trim().to_ascii_lowercase()`, so values are case-insensitive. Harmless
next to the first, but the same drift — it would have someone "fixing" a config
that already worked.
Corrected, and bound to three tests so it cannot silently drift back. They
assert the dangerous CLAIM rather than the current wording, so the node can be
rephrased freely and only reintroducing the falsehood fails:
* the body must not say an unknown value falls back to a tier;
* it must positively state the refusal — a node that simply omitted the
question would satisfy the first assertion while still leaving a reader to
assume some silent default;
* it must not claim lowercase-only.
All three verified failing against the old text before the fix, not merely
passing after it.
This is the hazard CLAUDE.md principle #17 and the SECURITY.md note describe:
a false claim in shipped guidance primes every future session, and is worse
than no claim at all.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
term:tieris shipped guidance about a security control, delivered to AIsessions as authoritative. It said:
Both halves are false, and the first is false in the least safe direction.
The dangerous half
config.rs:754errors withunknown AI permission tieron an unrecognisedvalue — MAE refuses to start rather than resolving it to anything. There is
even a test at
config.rs:1822asserting an unknown tier "must be rejected,never resolved".
So the node was describing the former bug as current behaviour. An agent
reading it would believe a typo in
auto_approve_tiersilently grants shell— exactly backwards from a control that fails closed.
The other half
PermissionTier::parse(crates/ai/src/types.rs:66) doess.trim().to_ascii_lowercase(), so values are case-insensitive. Harmless next tothe first, but the same drift, and it would have someone "fixing" a config that
already worked.
Bound to tests so it cannot drift back
Three tests, asserting the dangerous claim rather than the current wording —
the node can be rephrased freely, and only reintroducing the falsehood fails:
question would satisfy (1) while still leaving a reader to assume some silent
default;
All three were verified failing against the old text before the fix, not
merely passing after it:
Why this is worth a PR of its own
This is the hazard CLAUDE.md principle #17 and SECURITY.md's own note describe: a
false claim in shipped guidance primes every future session, and is worse than no
claim. The same file already carries an honest NOTE about
ai_tierbeingbadge-only — that part was accurate and is untouched.
No overlap with any PR currently open.
🤖 Generated with Claude Code