Governance and policies
Define what may be sent to AI tools, detect sensitive data, and review violations.
Governance lets you state what your organization considers acceptable to send to an AI tool, and see when it happens. It is an Enterprise feature, configured under Settings → Governance.
The pieces
Policies describe what must not reach an AI tool, who they apply to, and what happens at the moment of risk. A policy is built in four steps: Trigger (what kind of policy it is and what it looks for), Scope (a group or everyone, and any connected tool or specific applications), Response and Mode. It can be saved as a draft and published later; a draft is never evaluated.
A policy's trigger is one of three kinds:
- Sensitive data: personal and financial data found in prompts by local detectors, such as names, emails, payment card numbers, national identifiers and secrets. Each entity type has its own confidence threshold, so you can be strict about card numbers and lenient about person names, which produce far more false positives.
- Intent-aware rule: a rule you write in plain language, which Joring grades on every message. Joring drafts the policy from your rule, what counts, what does not, and worked examples, and tells you which parts of it cannot be read from a message at all. See Intent-aware rules.
- Application use: any prompt sent to the applications in scope. This is how an app is blocked outright, or how people are coached toward the approved one: the notice names the approved app and opens it in one click.
Responses run from a soft nudge to a hard block: Log records the match, Nudge shows a coaching note the person can act on, Rewrite replaces sensitive values before the prompt is sent, and Block holds the send. A blocking response can start in Dry run, which records what would have been blocked without stopping anyone.
Custom term lists cover what generic detection cannot know: internal project codenames, unreleased product names, customer names.
Exceptions carve out what must not fire again: allow-listed values and domains, the sender's own identity, and what happens while the analyzer is unavailable.
Violations are what you review afterwards, under Governance → Issues.
Intent-aware rules
An intent-aware rule is a document, not a sentence. You write one line, such as "Do not ask an AI tool to write the substance of a response to a regulator", and Joring drafts the rest: what counts, what does not count, and four to six worked examples from both sides of the line. You edit any of it. What you publish is exactly what the judge reads before every message.
How a message is judged
A message is graded against every rule that covers it in one pass, so a team with ten rules waits no longer than a team with one. That pass returns a verdict for each rule and nothing else. Anything it flags then gets a shorter second step, over those rules alone, which picks out the line of the policy that matched and the sentence that matched it, and writes the two sentences you see: the reason the person reads, and the neutral one-line description that appears under Issues. A message that matches no rule stops after the first pass and costs nothing further.
What Joring can see
Joring reads the message being sent, on its own: not earlier turns, not files, not the AI tool's reply, and not what happens outside the chat. It also knows which app the message is going to and which group the sender is in. A rule that needs anything else cannot be judged, and Joring says so while you write it.
The parts it cannot verify
Words like "unreleased", "approved" or "private" name facts about the world, and a message does not carry them. Joring names each such part of your rule and offers four answers: widen the rule to the observable case ("financial results" rather than "unreleased financial results"), narrow it to what the message itself says, ask the person at the moment of send and record their answer, or bind it to something Joring already knows, such as the audience or the applications the policy covers. Asking the person is the default.
See what it would have caught
Before an intent rule can block, you run it over the last 30 days of messages from the people in scope. Joring reports how many it would have flagged, as a rate with its denominator, and what that means in interruptions a week. Each match is a one-line description of what the message asked for over a short, masked excerpt around the sentence that matched. Mark a flag right or wrong. A wrong call asks for the reason, and the reason becomes a line in the policy or an example the judge sees, so the rule is sharpened where it was wrong.
The response ladder
Log records the match. Nudge shows a coaching note. Nudge and ask shows the note and asks for one line about why the message is needed; the message goes with the line attached, and the line is recorded with the decision. Block holds the send. New intent rules start on Nudge. A block requires a completed run on the current version of the document. When Joring is not sure, it asks the person for a reason rather than blocking on a guess.
What the person sees
The sentence that matched, the reason in the policy's own words, and what to do next. On the ask rung, a field for their reason. Never a confidence score.
What you see afterwards
The Issues record shows the reason, the clause of the document that decided it, the version of the policy, a one-line description of what the message asked for, and what the person did, with their reason if they gave one. Mark a violation Confirmed or Not a violation with a cause; a "not a violation" comes back as a proposed line for the policy.
Read flag rate, not accuracy
A specific rule fires on a small fraction of one percent of messages. Joring reports how often a rule fires and what it cost in interruptions, because an accuracy figure over a base rate that low tells you nothing. Intent-aware policy prevents mistakes and drift at scale and raises the cost of deliberate exfiltration; it is not a control against a determined insider.
Start in dry run
Publish a blocking policy in Dry run first, and test a sample prompt against the draft before publishing at all. Every organization discovers that some category fires constantly for a legitimate reason, and finding that out by blocking people mid-task is expensive in goodwill.
Once the violation stream is quiet enough to be meaningful, switch the policies you are confident in to Enforce and leave the rest in Dry run.
Custom term lists are where the value is
Generic PII detection is table stakes and mostly catches things people already know not to paste. The findings that matter are usually organization-specific: an unreleased product name, an acquisition codename, a named account. Those only get caught if someone adds them.
What administrators see
A violation shows who, which tool, which policy and why. For a sensitive-data policy it shows the values the detectors found and a short window of the message around them. For an intent-aware rule it shows a one-line description of what the message asked for, the sentence that matched and a masked window around it, with the rest of the message left out. Nothing else from the conversation is shown, and a message no policy flagged leaves no text anywhere an administrator can read.
Every governance change is recorded in the audit log.
NextBilling and seatsSee which features each plan includes.