Query Class

A query class is the group of questions that a poisoned chunk is likely to match during retrieval. It is the practical unit of exposure in a RAG injection because everyone who asks a similar question may receive the same payload, even across different users and sessions.

Expanded Definition

A query class is the retrieval neighborhood that a poisoned chunk can influence in a RAG system. It is not the single query a tester typed, but the broader set of semantically similar questions that the retriever may treat as equivalent enough to surface the same chunk.

That boundary matters because retrieval systems cluster meaning, phrasing, and intent. A payload planted for one question can therefore become visible to users asking related variants, including across sessions, tenants, or roles if the retrieval layer lacks strong isolation. In practice, the query class is the unit that turns one successful injection into repeated exposure.

Guidance versus consensus: teams do not always agree on whether the class is defined by vector similarity thresholds, keyword overlap, intent matching, or reranker behaviour. NHIMG treats the effective class as the set of prompts that reliably retrieve the same contaminated content in the live system, not just the set that looks similar on paper.

A common misunderstanding is to think the risk ends when the original malicious prompt is blocked. In retrieval systems, the stored chunk can remain dangerous long after the first query, because the class persists wherever the retriever still sees enough similarity.

Examples and Use Cases

Query class shows up in day-to-day RAG operations wherever retrieval is reused to answer repeated questions.

• A helpdesk bot retrieves the same contaminated policy fragment for “password reset steps,” “account unlock process,” and “I cannot log in,” because the retriever treats them as one class.
• A procurement assistant surfaces a poisoned vendor summary for both “who is the supplier” and “what is the contract status,” because the chunk matches multiple intent variants.
• A developer assistant answers both “how do I call this API” and “what is the authentication flow” from the same retrieved context, widening the exposure window.
• A customer-facing agent returns the same injected instruction to different users who ask equivalent product questions, showing how reuse across sessions creates shared blast radius.

The tradeoff is straightforward: broader semantic recall can improve answer quality, but it also enlarges the query class that a single tainted chunk can influence. Narrowing retrieval may reduce exposure, but it can also lower recall for legitimate questions.

Security Implications

The security issue is not simply that a poisoned chunk exists, but that it can be reused by many related prompts. Once a chunk falls inside a query class, the attacker does not need repeated injection opportunities; the retriever does the amplification by serving the same payload to a wider set of users and questions.

This creates cross-user contamination risk, especially where retrieval spans shared indexes, weak tenant filters, or coarse access boundaries. It can also produce inconsistent detection, because the malicious content may appear under many different user intents rather than a single obvious trigger phrase.

Operationally, the symptom is often surprising answer convergence: different questions return the same suspicious instruction, policy override, or misleading context. The blast radius expands when the poisoned chunk is highly central to a popular intent, since that class may dominate retrieval traffic.

Domain and Governance Relevance

Query class matters most in retrieval governance and in any environment that treats RAG as a shared decision-support layer. The concept forces teams to think beyond prompt filtering and toward the retrieval boundary that actually determines who can see a poisoned chunk.

For NHI and agentic systems, the relevance increases when a non-human actor, tool, or workflow uses the same retrieval index as human users. A compromised knowledge source can then influence both human queries and autonomous actions, which makes ownership of indexing, corpus curation, and retrieval isolation a governance issue rather than a pure content problem.

In practical terms, query class should be understood as part of the trust boundary around retrieval. If the class is too broad, one contaminated source can affect multiple personas, tools, and sessions; if it is too narrow, the system may fragment knowledge and miss legitimate context.

Related resources from NHI Mgmt Group

• How should security teams govern AI agents that query sensitive data in Snowflake?
• Who is accountable when an AI agent runs a query on behalf of a user?
• What breaks when machine identities are not governed like first-class identities?
• How should security teams govern AI assistants that can query workload IAM data?