LLM exposure levels

Every module dataset in a project carries an LLM exposure level that governs what the RebelCore™ Agent is permitted to say about that data when it answers a prompt. The setting is a one-shot decision at module-build time, but it’s enforced live on every inference round-trip — both in the prompt the language model sees and through deterministic post-checks.

This page covers what each level means, how the project’s effective level is computed, and where the rules are enforced.

Why this exists

Different datasets carry different sensitivity. A dataset of marketing-funnel events is fine to quote freely; a dataset of credit decisions is not. Rather than relying on prompt engineering or per-question vetting, RebelCore™ lets you bake the policy into the module — the agent then operates within that policy automatically, regardless of what an analyst asks.

The three levels are progressively more restrictive: Full → Limited → Advisory only. The most-restrictive setting across all modules in a project becomes the project’s effective exposure, and that’s the level the agent honours for every prompt run against the project.

The three levels

Full exposure

The agent may return raw rows, exact values, records, fields, IDs, timestamps, and detailed extracts. It may also provide summaries, aggregates, insights, and advice. It must not fabricate data — only return values present in the data or clearly derived from it.

“In January, South Africa has a recorded temperature of 45°C, with wind speeds ranging from 5–50 km/h.”

Use this for datasets where there’s no privacy or compliance constraint on quoting specifics.

Limited exposure

The agent may discuss metadata, schema, column meanings, data quality, trends, aggregates, categories, and high-level insights. It may return aggregated or summarised information where it doesn’t expose individual rows or exact source records.

It must not return raw rows, row-level records, exact source values, IDs, timestamps tied to records, or any data that allows reconstruction of the original dataset. It avoids quoting exact raw values unless they’re public, explicitly permitted, or are safe aggregate outputs. If the user asks for raw rows or exact records, it refuses that part and provides a compliant summary instead.

“January appears to be very hot, with temperatures around the mid-40°C range. Wind conditions vary from light to strong, but overall indicate some wind exposure.”

Use this for datasets with personal or commercial data where aggregates are safe but individual rows are not.

Advisory only

The agent may use the data internally to reason and solve the user’s business problem. It must not return raw rows, exact values, field-level records, or aggregates, counts, percentages, averages, ranges, minimums, maximums, medians, distributions, or dataset-derived statistics. It must not reveal enough detail for the user to reconstruct the data.

Instead, it translates data into qualitative advice, risk guidance, decisions, recommendations, classifications, or next steps. It uses phrases like “high”, “low”, “material”, “minor”, “likely”, “unlikely”, “strong signal”, “weak signal”, “requires attention”, or “not concerning” instead of numeric outputs.

If the user asks for data, values, aggregates, or statistics, the agent refuses that part and provides advisory guidance only.

“January in South Africa should be treated as very warm to hot, with some wind. Plan for heat protection, hydration, shade, and light wind exposure.”

Use this for the most sensitive datasets — typically those subject to internal-only or regulator-only disclosure rules. The agent can still help analysts make decisions; it just can’t tell them the underlying numbers.

General rules (all levels)

The agent always checks the active exposure level before answering.
It never escalates exposure beyond the active level.
If the user requests something disallowed, the agent briefly explains that the current exposure level doesn’t permit that output and provides the safest allowed alternative.
It does not mention hidden data values, internal rows, or suppressed numbers.
It does not leak data through examples, explanations, reasoning, calculations, charts, filenames, logs, or error messages.
It does not expose data indirectly by giving formulas plus enough context to reconstruct the original values.
When unsure, it defaults to the stricter interpretation.

Setting the level on a module

The level is chosen during the Module Build step (see Create your dataset). The build blade has three radio options — Full / Limited / Advisory only — defaulting to Limited. The choice is stored on the module’s settings and is immutable in the same sense the module set itself is: rebuilding the module is the way to change it.

The module’s level is shown as a coloured badge wherever the module appears:

Full → blue
Limited → amber
Advisory only → rose

You’ll see it on the module picker when creating a project, in the project’s read-only modules list when editing, and as the per-dataset pill in the agent’s settings cog.

Project effective exposure — most restrictive wins

A project can attach more than one module, and those modules can carry different levels. The project’s effective exposure is the most restrictive level among them.

Module mix	Effective level
1× Full	Full
1× Limited, 2× Full	Limited
1× Advisory, 1× Limited, 1× Full	Advisory only
2× Advisory	Advisory only

The order is Full < Limited < Advisory only — Advisory always wins.

This is why it’s important to think of exposure as a policy choice for the whole project, not a per-dataset toggle: the moment you mix in one Advisory dataset, the project as a whole runs as Advisory, regardless of how permissive the others are.

When you create the project

If your selected module set has more than one exposure level, the create blade shows an inline notice above the SAVE button:

“Your selected datasets have different LLM exposure settings (Full × 1, Limited × 2). This project will run as Limited — the most restrictive setting wins.”

The project is created at the effective level. There’s no override — the rule is non-negotiable.

When you edit the project

The (read-only) modules list in the edit blade shows each module’s level pill plus a summary line:

“Effective LLM exposure for this project: Advisory only (most restrictive of 2 different levels)”

This lets operators verify at a glance that the policy still matches what was intended.

On the projects list page

Each project card carries a coloured pill next to its name showing the project’s effective level. Use this to scan exposure posture across your portfolio without opening each project.

How the agent enforces this

Exposure is computed at inference time, not stored on the project. Every prompt round-trip:

The route resolves the prompt’s selected datasets back to their projects’ modules and computes the most-restrictive level among them.
The level is threaded through the inference workflow alongside the prompt.
The final curate step receives a system prompt that includes the level-specific rules verbatim. The language model is told what it may and may not say at this level, with worked examples for the same data answered three different ways.
After the curate produces an answer, a deterministic leak scanner walks the tool result and checks the answer for verbatim row values that shouldn’t be there. If anything slips through, the answer is replaced with a clean fallback rather than shipped.

Computing per-prompt rather than persisting on the project means a module’s level can be changed (by rebuilding) and the next prompt against the project picks up the new level automatically — no project-level migration needed.

Per-response indicator

Every assistant response in the Agent carries a small badge in its footer line: Limited, Advisory, or Full. That’s the level the answer was produced under. Operators auditing a session can see the exposure on every turn without leaving the conversation.

Cross-checks in the audit trail

The super-admin Audit page records the active exposure level on every inference workflow’s audit_finalize payload, plus the leak-scanner outcome on the mcp_curate_answer step. If the leak scanner replaces an answer, an curate_leak_scrubbed event lands on the Activity page for that session.

What if I need to change a level later?

Levels are tied to the module’s stored settings and aren’t editable from the project. To change a level:

Rebuild the module with the new exposure setting.
(Optional) Clean up old projects pointing at the old version if you want them to reflect the new level — every new prompt against any project containing the rebuilt module will pick up the change.

You can also achieve the same effect by adding a stricter module to the project — recall most-restrictive wins. Adding a single Advisory-only module to a project full of Full-exposure modules immediately makes the whole project Advisory.

What’s not in this model

Per-user exposure — exposure is set at the dataset/project level, not per-user. If a user has access to a project, they see answers at that project’s effective level. There is no “this user gets Full but everyone else gets Limited” path.
Per-question exposure — the level applies to the whole prompt round-trip. There’s no way for the user to say “answer this question as if I were Full”.
Soft / advisory mode — the level is enforced both via the curate prompt and via deterministic post-scans. There’s no “warning-only” mode.

Where to go next

Creating a project — picking modules and access settings.
Create your dataset — where the level is chosen at module build time.
RebelCore™ Agent — how the level shows up at inference time.
Audit and Activity — how exposure decisions are recorded.