Repository navigation
Say that a policy's rules are not secret from the writers of other realms - #181
Merged
habdelra merged 8 commits intoOct 7, 2026
Conversation
The reader gate on the config card's standing and on validate covers what the realm answers about a policy, not how the realm behaves under it. A writer can point their realm at a policy card in a realm they cannot read, and a caller that realm declines then learns from its answers whether a compiling policy sits at the URL and what it grants. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 6, 2026
Merged
habdelra
commented
Oct 6, 2026
habdelra
left a comment
habdelra
left a comment
Contributor
Author
There was a problem hiding this comment.
[Claude Code 🤖] I checked the §9 additions against the platform on boxel main: how the pointer card is loaded, the validatePolicy / PolicyStanding reader gates, and the status codes in the realm-server policy tests. I also checked them against §1 and "What a policy does not do".
No blocking issues. The facts are right. There are two wording asks inline: make the writer the one who learns what's at the URL (not "a caller the realm declines"), and point to §1's secrecy rule instead of restating it.
Comment on lines
+832
to
+835
| realm then loads and applies that card on the server's own authority (§1). A | ||
| caller the realm declines can therefore tell from its answers whether a | ||
| compiling policy sits at the URL (a 500 against an ordinary refusal), and can | ||
| exercise its grants against cards the writer controls. So a policy's rules |
Contributor
Author
There was a problem hiding this comment.
[Claude Code 🤖] Please make the writer the one who learns, not "a caller the realm declines". As written, the sentence after "therefore" has a new subject, which suggests any declined caller learns what's at a URL they chose. That doesn't make sense, and it doesn't match §1, which says "a realm writer can learn". The writer isn't declined by their own realm, so the probe only works when the writer asks as a second, signed-in identity the realm declines. The 500 is the signed-in answer: per the §1 table, a caller who isn't signed in gets 401 actor-required instead. Here's a suggested rewording:
Suggested change
| realm then loads and applies that card on the server's own authority (§1). A | |
| caller the realm declines can therefore tell from its answers whether a | |
| compiling policy sits at the URL (a 500 against an ordinary refusal), and can | |
| exercise its grants against cards the writer controls. So a policy's rules | |
| realm then loads and applies that card on the server's own authority (§1). | |
| Asking as a signed-in caller the realm declines, that writer can tell whether | |
| a compiling policy sits at the URL (a 500 against an ordinary refusal), and | |
| can exercise its grants against cards they control. So a policy's rules |
Non-blocking wording fix. The facts check out against the platform: the pointer card is compiled on the realm's own authority, the config-card validatePolicy checks the pointer's realm before reporting anything, and a missing card or one that won't load refuses with a 500.
Contributor
Author
There was a problem hiding this comment.
[Claude Code 🤖] Fixed in f37dd80. The writer is now the one who probes, asking as a signed-in caller the realm declines, and the grants are exercised against cards they control.
Comment on lines
+835
to
+837
| exercise its grants against cards the writer controls. So a policy's rules | ||
| are not secret from the writers of other realms on the server. **Keep nothing | ||
| in a policy's predicates that must stay secret.** |
Contributor
Author
There was a problem hiding this comment.
[Claude Code 🤖] These last sentences repeat §1's closing paragraph almost word for word ("A policy's rules are not secret from the writers of other realms on the server. Never put a value that must stay secret in a predicate."). The bold rule is even worded differently in each place. If they're kept as two copies, they'll drift the next time either one is edited. I'd keep the first half of this bullet, which is the new point that the reader gate doesn't hide behavior, and end with a pointer instead of restating the conclusion. For example: "…so a policy's rules are not secret from other realms' writers; see §1." Non-blocking.
Contributor
Author
There was a problem hiding this comment.
[Claude Code 🤖] Fixed in f37dd80. The bullet keeps the new point, that the reader gate covers the answers and not the realm's behavior, and ends by pointing to §1 for the conclusion and its rule rather than restating them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
lukemelia
approved these changes
Oct 6, 2026
…ry-limit' into cs-13398-policy-a-realm-writer-can-point-their-realm-at-a-policy-card
…ry-limit' into cs-13398-policy-a-realm-writer-can-point-their-realm-at-a-policy-card
…ry-limit' into cs-13398-policy-a-realm-writer-can-point-their-realm-at-a-policy-card
…ry-limit' into cs-13398-policy-a-realm-writer-can-point-their-realm-at-a-policy-card
…ry-limit' into cs-13398-policy-a-realm-writer-can-point-their-realm-at-a-policy-card
…lm-writer-can-point-their-realm-at-a-policy-card
habdelra
changed the base branch from
cs-13109-policy-skills-cover-every-limit
to
main
October 7, 2026 07:57
Staging Workspace Sync SuccessfulSuccessfully synced changes to staging workspace Sync Details |
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
2 participants
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.
Important
Merge order (each must merge before the next):
Compile a policy grant's opt-in to callers who aren't signed in boxel#6534: compile a grant's anonymous opt-in (merged)Policy: admit anonymous reads through a grant that opts in, rate-limited per realm and address boxel#6568(CS-13536): anonymous reads (merged)4a. Policy: let a grant on a declared operation admit a caller who isn't signed in boxel#6579 (CS-13605): anonymous named operations, stacked on #6577. boxel-skills#174's §12 describes it
4b. Policy: explain how a realm treats a caller who isn't signed in boxel#6581 (CS-13609): explaining a visitor's refusal, stacked on #6579, with its panel in Show in the explain panel how a realm treats callers who aren't signed in boxel-catalog#809. boxel-skills#174's §10/§12 describe it
Add the judgment calls to the realm-policy-authoring skill #175(CS-13108): merged, and merged into Teach the realm-policy-authoring skill anonymous grants and a realm's anonymous traffic controls #174 and State every limit of a realm policy in the skills #179. The anonymous section is §12, Refusals §13, "Choosing what to grant" §14 and the checklist §15.5a.
Say that no policy grant reaches a path the realm ignores #178(CS-13336): edits other parts of the same skill (merged; Teach the realm-policy-authoring skill anonymous grants and a realm's anonymous traffic controls #174 has merged main and taken it in)Teach the realm-policy-authoring skill anonymous grants and a realm's anonymous traffic controls #174(CS-13571): anonymous grants in the skill (merged)State every limit of a realm policy in the skills #179(CS-13109): merged7a. This PR (CS-13398): targets
mainnow that State every limit of a realm policy in the skills #179 has merged; next to mergeEvery PR in this order carries this callout. Whoever opens one of the PRs above tells the owners of the others, and each owner updates its own callout.
In service of operation-permission policies, which let a realm's policy admit callers the realm's own permissions decline.
realm-policy-authoring§9, "Seeing the issues", says that only a caller who can read the policy card's realm may see whether a policy is in force, on the config card or throughvalidate. That gate covers what the realm says about a policy, not how the realm behaves under one. Any writer of a realm may point it at a policy card in a realm they cannot read, and the realm loads and applies that card on the server's own authority. A caller the realm declines can then tell from its answers whether a compiling policy sits at the URL (a 500 against an ordinary refusal), and can exercise its grants against cards the writer controls.This PR states the config card's reader gate, which the section left out, and adds a bullet saying what the gate doesn't cover and the authoring rule that follows from it: keep nothing in a policy's predicates that must stay secret. §1 already states the repointing posture. The new bullet points back to it.
🤖 Generated with Claude Code