Permissions and isolation

Olga respects every user RBAC scope and can never reach another organization data.

Phase 1

This is part of what RunOlga delivers in Phase 1.

Two boundaries shape everything Olga can see. She works inside the access scope of the person she is talking to, and she works inside one organization's instance and only that one. Both boundaries are enforced in the application, not in her instructions, so they hold on every query — including ones designed to talk around them.

Permission scoping (RBAC)

Olga respects the access scope of the user she is talking to. Every retrieval she runs is scoped to that user's permissions before it executes, the same way the rest of RunOlga scopes what each person sees. She has no separate, wider view of the organization to draw from.

When a user asks about something they do not have permission to see, Olga does not silently return nothing, and she does not invent an answer. She also does not pretend the data does not exist when access is the actual limitation. Instead she gives a graceful acknowledgment: the information exists, it is simply not in this user's scope. That honesty matters — telling someone "there is nothing" when the real answer is "you cannot see this" is its own kind of misinformation.

An illustrative out-of-scope exchange:

You: What's our cash position this month?

Olga: That sits with the Chief Care Officer's financial view, which isn't in your access. I can't open it here. If you need it, the Chief Care Officer or your administrator can grant access or share the figure directly.

Two things hold in that reply. Olga confirms the data is real rather than denying it, and she points to the human path forward — without exposing a single number.

Enforced at the application layer

RBAC is enforced at the application layer, not the prompt layer. The scope is applied to every query before it runs, in code. Olga is not deciding, request by request, whether to honor a permission boundary; she does not have the ability to read outside the user's scope, so there is nothing to talk her around.

Quality does not vary by rank

Permission scoping changes what Olga can retrieve. It does not change how well she works. A Care Manager gets the same thoughtful, grounded, available partner the Chief Care Officer does. Olga's voice, the depth of her help, and her responsiveness are the same in every seat. The only difference between two users is the set of records each is allowed to see — never the quality of the partner working with them.

Instance isolation

Olga only has access to the instance the user is authenticated into. She cannot reference any other organization's data. She does not know what other organizations using RunOlga look like, what they have configured, or even that any specific other organization exists. The instance the user is signed into is the entire world she can see.

This is a stronger guarantee than permission scoping. Permission scoping is a boundary within one organization. Isolation is the boundary between organizations, and it is absolute: there is no role, no permission level, and no administrator inside an instance that can reach across it.

Architecturally impossible, not policy-enforced

Cross-instance leakage is architecturally impossible, not policy-enforced. It is not a rule Olga follows and might miss under a clever prompt — the path to another organization's data does not exist for her to take. No query she can run, and no way a user can phrase a request, opens a route to another instance.

The practical effect: a user in GCS's instance is working with GCS's data and nothing else. Another organization on RunOlga could have priorities, issues, and processes named identically, and Olga would still have no way to see them, mention them, or be influenced by them. Each organization's Olga is grounded only in that organization.

How this is verified

Both boundaries are part of RunOlga's acceptance criteria, and Phase 1 is not complete until they are verifiably met. See Acceptance criteria for the full list.

Permission scoping is tested with at least three role and permission combinations. A user with a given scope cannot extract data through Olga that they could not extract through the UI. Olga is held to the same boundary as the rest of the product.
Instance isolation is tested against prompt manipulation. A user authenticated to one instance cannot, through any Olga query or attempt to manipulate the prompt, reach another instance's data. The test is not whether Olga politely declines — it is that no route to the data exists at all.

How this fits the other guarantees

Permission scoping and instance isolation are two of the four guarantees that make Olga safe to rely on. The other two are grounding with provenance and confirmation before every write. Within a single interaction they work together: scoping and isolation decide what Olga is allowed to see, grounding ensures her answer comes from real records, and confirmation gates anything she would write back.

For grounding and the confirmation-before-writes guarantee, see Grounding and confirmation. For the overview of all four, see Trust and safety. For what Olga does and does not do in Phase 1, see Scope and roadmap.