Platform · Jubi Guardian · Protection & identity

Who's asking, and what they're allowed to do.

Guardian is the protection and identity layer. It ties every request to a real person, decides which data and which tools the AI is allowed to reach, and keeps a clear record you can replay.

Identity · Policy · Audit — checked on every request

One platform — three parts JubiStudio workspace + JubiGuardian protects + JubiAtlas grounds shared identity · shared audit · shared brand
01 · What Guardian does

Identity, policy, and a record you can replay.

Guardian sits between Studio and your data. Every request answers three plain questions: who is asking, is this allowed, and can we show what happened. Each one maps to real work the platform does before and after the AI runs.

01 · Identity

Each request tied to a real person

Guardian reads identity from your existing single sign-on, so the person behind a request is the same one your IT team already manages. There is no second login, and no separate user list to keep in step.

Signed in through your IdP: the request carries the person's identity and group membership, not an anonymous service account.
  • Inherits your SSO
  • SCIM / group sync
  • Per-request attribution
  • No shadow user list
  • Session-bound
  • No anonymous calls
02 · Policy

Checked against the rules before it runs

Before the AI touches anything, Guardian checks who's asking and what they're allowed to see. When a request is declined, that decision is recorded too, with the reason, so a refusal is as visible as an approval.

Out of scope for the role: the request is declined and the reason is written to the record, not silently dropped.
  • Role-based rules
  • Workspace scoping
  • Checked before run
  • Declines recorded
  • Reason attached
  • Tool access constrained
03 · Audit

A clear, replayable record of each call

Guardian keeps a record of what was asked, who asked it, what was decided, and what came back. The record is replayable, so when someone needs to show their work, the trail is already there.

Reviewing a call later: identity, decision, sources, and answer are all on the record, whether the request ran or was turned away.
  • Per-request log
  • Who · what · when
  • Decision + reason
  • Replayable trail
  • Allowed and declined
  • Source citations kept
Built in

The record is queryable in-platform and streams to your own SIEM, so Guardian's audit trail lands in the same log pipeline as the rest of your estate. Your security team reviews it where they already work.

02 · The request lifecycle

The checks a request passes through.

A single question typed into Studio becomes a request, and that request moves through a fixed set of gates before an answer comes back. This is the order they run in. It is a sequence of checks, not a promise that any one input is safe.

Identity checkstep 01

Guardian resolves who is asking through your single sign-on. A request with no resolvable identity does not proceed.

  • Reads the signed-in user from your IdP
  • Carries group membership with the request
  • No identity, no run
Permission checkstep 02

The request is checked against the person's role and the rules of the workspace they are working in. A request outside that scope is declined, with the reason kept on the record.

  • Role-based rules
  • Workspace scope
  • Declines recorded with a reason
Data-scope checkstep 03

The user's row and column permissions are carried through to where the AI asks. If a person cannot see certain records directly, the AI does not read them on their behalf.

  • Row and column permissions carried through
  • Applied where the query runs
  • The AI sees what the user can see
Grounding via Atlasstep 04

With scope settled, the request draws on the Atlas semantic layer: the metrics, glossary, and entity model your team defined, so the answer reads from your business rather than the model's guess.

  • Canonical metrics and glossary
  • Entity relationships
  • Scoped to the workspace
Answer assemblystep 05

The AI assembles a response from the data it was allowed to read, with citations back to the sources it used, so the answer can be checked rather than taken on faith.

  • Built from permitted data only
  • Citations to source cards
  • Says so when it cannot source an answer
Audit writestep 06

The request, the decision, the sources, and the answer are written to the record. Allowed or declined, the trail is there to replay later.

  • Who asked, what was decided
  • Sources and answer kept
  • Replayable, allowed and declined alike
03 · Access & record

Permissions don't stop at the database.

Two ideas hold this together. First, the access a person already has follows them into every request. Second, what happened is kept where you can find it again. One controls reach; the other lets you show your work.

Carried through Access follows the request
  • The user's identity and permission scope follow the request to where the AI asks
  • Row and column permissions are applied at the point the query runs, not bolted on after
  • If a user can't see customer records, the AI won't surface them in a summary either
  • Scope is set per team and per workspace, so reach narrows as the role does
The AI works within the same boundary as the person asking. It does not widen access; it inherits it.
On the record What happened is kept
  • Each call is tied to a person, with the decision that was made and the reason for it
  • Declined requests are noted alongside the allowed ones, so a refusal is never silent
  • The trail is replayable, so you can revisit who asked what, and what came back
  • Queryable in-platform and exportable to your own SIEM
The allowed requests and the declined ones both leave a record you can show later.
04 · Tools & actions

Every tool the AI can use runs through Guardian.

An agent doesn't get open access to your stack. Each tool, connector, and action it can reach is decided by Guardian, scoped to the person behind the request.

Allowed toolsscoped

The AI can only call the tools and data connectors the asker is already permitted to use. Scope follows role and workspace, not the model's appetite.

  • Per-role, per-workspace tool access
  • No connector the person couldn't reach themselves
Action approvalswrites & actions

Reading is one thing. Anything that writes or takes an action can require explicit sign-off before it runs.

  • Read and write handled differently
  • Human approval where you set it
Sandboxedcontained

Tool calls run in a contained space, not with open reach into your systems. A call does what it is scoped to do and nothing more.

  • Contained execution
  • No standing access to your stack
Web accessallow / deny

Outbound fetches are allow and deny listed, and anything pulled back is treated as untrusted input before it reaches your data.

  • Allow and deny lists on outbound calls
  • Retrieved content treated as untrusted
How it's enforced

Tool scoping, action approvals, sandboxed execution, and per-request enforcement all run through Guardian. We will walk your team through exactly how each control is configured for the deployment you're considering.

05 · Defence in depth

Layers against prompt injection.

Retrieved documents and web pages can carry instructions aimed at the model. No one can promise immunity from that. What Guardian can do is stack a few honest defences, so a single trick is less likely to carry through. This is defence in depth, not a guarantee.

Untrusted by default Content is data, not orders
  • Retrieved and web content is treated as untrusted input, not as instructions to follow
  • Instructions are kept separated from data, so text inside a document is read as text
  • The model's job stays fixed by the request, not rewritten by what it reads
This lowers the odds that injected text takes over a request. It does not claim to catch every attempt.
Constrained reach The blast radius is small
  • Guardian constrains which tools the AI may call on any given request
  • Data-scope checks still apply, so injected text cannot reach past the user's permissions
  • Each request stays on the record, so a suspicious one can be found and replayed
If something does slip through, it runs inside the same narrow boundary as the person who asked, and it stays auditable.
How it fits

Studio reaches. Guardian protects. Atlas grounds.

A question typed into Studio takes the same path each time. The user sees one thread; the platform sees a request, a policy decision, and a grounded answer.

Studio
user asks
Guardian
identity · policy · audit
Atlas
metrics · glossary · permissions

Studio is the surface the user works on. Guardian is the gate that each request, answer, and audit entry passes through. Atlas is the grounding layer the AI reads from instead of guessing. None of the three works alone. See the platform architecture → for the full diagram.