A review bot describes its own operations in prose - what does that give an attacker that public product docs do not?
answer
- docs describe the product
- the reply describes this installation
- which subset did this owner enable?
- a sketch, not a register
- no types, no required fields, no completeness
basics
~20 sDocs describe the product; the bot's account describes this installation - which operations are wired up here and roughly what the arguments are called. The paraphrase loses exact names, types and required fields, and proves nothing.
solid answer
~40 sPublished documentation is about the product; the bot's self-description is about the deployment. That is the whole difference in value. From prose an attacker learns which subset of operations this installation enabled, roughly what the arguments are called, and which ones the bot presents as read-only versus effectful - none of which the docs can tell them, because installations differ. What the paraphrase loses is fidelity: no exact identifiers, no types, no required-versus-optional distinction, no enumerated values, no constraints. And it comes with no guarantee of accuracy, because the model is describing itself rather than reading a register. So the attacker gains targeting and pays in uncertainty: everything on the list is a lead that only holds up if a later request is actually acted on.
go deeper
Know the basic distinction: documentation is about the product in general, while the assistant's own answer is about the copy running here. The second is more specific and less reliable at the same time.
Be able to list what a paraphrase drops - exact identifiers, types, required versus optional, enumerated values, completeness - and explain why each gap makes a later request fail outright rather than partly.
Demonstrate the provenance discipline: the reply establishes what the model said, not what the deployment holds. Write findings that state the description as a description, and say what would confirm it.
The judgment worth owning is how much configuration detail a deployment reveals about itself as a matter of course, and whether an assurance claim written against the product's documentation says anything about a specific installation at all.
## Two artefacts that look alike and are not The published documentation for a review assistant and the assistant's own account of what it can do read similarly. They are different artefacts with different reference points. - **The documentation describes the product.** It is written once, for every installation, and it enumerates what the software is capable of supporting. - **The prose account describes the deployment.** It is generated by this instance, in this repository, with whatever subset of operations this owner turned on and whatever wiring they added themselves. An attacker probing a public pull-request bot already had access to the first. What they did not have, and now do, is the second. ## What the deployment-specific account is worth Three things travel in the paraphrase and matter: 1. **Which operations exist here.** Two installations of the same assistant differ - one has the CI log reader attached and the other does not; one can leave a comment and another can also apply a label. That difference decides what a later request could even aim at. 2. **Roughly what the arguments are called.** Not the schema, but the vocabulary: whether a run is addressed by an identifier or a branch name, whether a comment is addressed to a pull request or to a review thread. 3. **How the bot characterises each one.** Which it presents as merely reading and which as producing something a person will see. The attacker's position moves from *guessing at a surface* to *working from a description of it*. That is what reconnaissance buys: the next step is aimed rather than speculative, and every failed attempt they no longer have to make is cost they no longer pay. ## What the paraphrase costs the attacker This is the half candidates skip, and it is the half an interviewer is listening for. | Present in a machine-readable definition | Present in a prose account | |---|---| | Exact identifiers, spelled as the system expects | An approximation, possibly renamed for readability | | Types, required versus optional, defaults | Rarely, and unreliably | | Enumerated values and constraints | Almost never | | Completeness - the register is the register | No completeness guarantee at all | Every one of those gaps is a place where a later request built on the description simply fails. A misspelled identifier is not a near miss; it is nothing. So the attacker is holding a sketch, and the sketch has to be reconciled against reality before it is worth anything. ## The accuracy problem, stated in the right direction The deepest point is about provenance. When a model describes its own capabilities it is generating text conditioned on what is in its context, not reading a register and reporting it. The description is therefore an *account*, and an account can be: - **incomplete** - an operation held but not mentioned; - **inflated** - a plausible-sounding operation named that this installation does not have; - **renamed** - the right operation under a wrong label, which is the most expensive kind of wrong because it looks usable. So the correct statement of what was learned is: *the model produced this description*. Not: *the installation holds these operations*. Confirmation comes only from a later request being acted on or not - and until that happens, a report that presents the list as an inventory of record is overstating its own evidence. ## Why this still beats the docs Given all those losses, why is it worth anything? Because the failure mode is cheap and the payoff is directional. A wrong name costs one more interaction. A right one collapses a large search space - the attacker stops enumerating the product's possibility space and starts working inside this installation's actual one. Reconnaissance is valued on the search it eliminates, not on the precision of any single fact. ## How to answer this in a loop Say both halves. The gain is deployment specificity - what is wired up here, in this owner's configuration, which no published document can tell you. The loss is fidelity and provenance - a description is not a register, and nothing on the list is established until the system behaves as though it is. A candidate who names only the gain sounds like they have never had a lead fail; a candidate who names only the loss sounds like they do not understand why anybody bothers.
- Why is a wrongly remembered argument name more expensive to an attacker than a missing one?A missing name is a known gap - you know you have to find it. A wrong name looks usable, so effort goes into building on it before the mismatch shows up, and the failure reads like the whole approach being wrong rather than one token being wrong. Confident-looking bad detail costs more than an acknowledged blank.
- How does deployment specificity change how you describe the finding in a report?It makes the finding about this installation, not the product, so the report should be explicit that the disclosed surface is configuration-dependent and may differ elsewhere. That framing also keeps the claim honest: you observed what the bot said in this repository, on this configuration, at this time.
saying these in an interview costs you the question
- Treats a prose account as equivalent to a machine-readable definition
- Says the list proves the installation holds those operations
- Assumes published docs already give away the same information
- Ignores that argument names in prose may be approximations
- Claims completeness from a description that guarantees none