Configuring Custom Policies

this is a deep dive into the custom policy editor what each section does, how to configure it, and how the rules you set combine to produce real‑time enforcement it follows the editor screen by screen for a higher‑level overview of policy types, see policies docid\ swafagwiqwgzevhazm im how the editor is laid out the custom policy editor has four tabs down the left side tab what you do here global protections set the protections that apply to everyone, on every website app rules control access to specific apps and fine‑tune protections on them team exceptions create per‑team (and per‑app) overrides to the rules above summary review everything the policy does before publishing two things happen behind the scenes as you work your edits are saved as a draft nothing affects employees until you publish while you have unpublished changes, an orange badge on each tab shows how many changes are pending there you can build with ai the policy builder includes a chat assistant that can make these changes for you when you describe what you want in plain language the four enforcement levels every rule in a custom policy has one of four levels you'll see these same four everywhere in the editor level what it does allow permitted nothing is logged or blocked log only permitted, but the activity is recorded — no intervention soft block maro intervenes when the activity happens it confirms it's a genuine match, warns the employee, and can offer a way to continue safely (like redacting the sensitive part), but users can dismiss the intervention and proceed (activity remains logged) hard block maro intervenes, but prevents the user from dismissing the activity without remediating a key idea everything is allowed by default you don't grant access — you add restrictions that's why, when you add a behavior or use‑case rule, you only choose between log only , soft block , and hard block "allow" is simply the absence of a restriction ("allow" appears as an explicit choice in two places setting an app's access level, and lifting a restriction for a specific app or team — see below ) global protections this tab defines the restrictions that apply across all employees and all websites global protections define what activity restrictions apply behaviors and use cases are allowed by default across all employees and websites, and adding one creates a restriction it has two sub‑sections, toggled at the top behavior controls and use cases behavior controls behavior controls are the real‑time guardrails — they watch for a specific kind of sensitive activity and act the moment they see it maro ships with common ones ready to use, such as pii — personal data like names, emails, addresses, ssns phi — protected health information payment cards — credit/debit card numbers secrets — api keys, tokens, passwords, credentials you can also build organization‑specific behaviors (for example, "disclosing our unreleased roadmap") to add one under add restriction , search for a behavior, choose log only , soft block , or hard block , and click add each rule you've added appears as a card where you can change its level, expand it to read what it detects, or remove it you can filter the list by level or by category behavior controls you set here apply everywhere — including apps you haven't added under app rules a "hard block secrets" rule fires whether someone pastes a secret into a listed app or any other website the app rules tab does not limit where your global protections apply use cases use cases recognize the kind of work someone is doing — for example "code generation", "summarizing a contract", or "personal use" — rather than a specific piece of sensitive content they give you visibility into how tools are being used to add one under add use case restriction , type a use‑case name, pick a level, and click add use cases are most often used at log only to build a picture of how ai and other tools are being used across the org app rules app rules let you control access to specific apps and tailor protections on each one the tab is a table with these columns app / website — the app, shown with its icon and hostname status — the access level for the app (allow / log only / soft block / hard block) behavior controls — how many app‑specific behavior overrides exist use cases — how many app‑specific use‑case overrides exist redirects — the redirect url, if one is set to add an app search for one of your organization's known apps, or type a url/hostname to create and restrict a new one you can filter the table by status clicking a row opens its drawer , which has three sections app access sets the access level for the app — "set the access level for \[app] for all employees" — with a description of what each level does allow — "allow access to \[app] for all employees " log only — "all employees can access \[app] , but all activity will be logged without intervention " soft block — "soft block access to \[app] for all employees maro will intervene when they try to use it " hard block — "hard block access to \[app] for all employees maro will prevent employees from using it " when you choose soft block or hard block , a redirect to field appears an optional remediation url to send employees to instead (for example, an approved internal alternative) redirects are only available for the two block levels behaviors and use cases (per app) these two sections let you tailor your global protections for this app they're only available when the app's access is allow — if you've blocked the app itself, there's nothing left to fine‑tune each section shows your rules in three groups inherited (unchanged) — rules flowing down from global protections, applied as‑is on this app overridden — an inherited rule you've set to a different level on this app (for example, "allow" a behavior here that's "soft block" everywhere else) additional rules — extra rules that apply only on this app this is how the same protection can behave differently per app relax a control on an internal tool where the activity is expected, while keeping it strict everywhere else team exceptions team exceptions let you give specific teams different rules team exceptions allow role‑specific overrides to global behavior controls and app rules they are scoped by team and app, with room to add additional rules where needed to add one pick a team and click add new override each team override appears as a row showing its priority , team , number of employees , and overrides priority matters when more than one team override could apply to someone, they're considered in priority order drag rows to reorder them opening a team's row reveals a drawer where you choose which app scopes the exception applies to, then edit its behaviors and use cases using the same inherited / overridden / additional groups as app rules each scope can set its own redirect url when it's a soft/hard block a team override can loosen a rule (e g let engineering paste secrets into an internal tool), tighten one, or add rules that apply only to that team summary the summary tab is a read‑only review of the whole policy when you have a draft, it highlights exactly what's changed, lets you jump to where each change was made, and lets you revert individual sections before publishing how the rules combine when an employee does something, maro has to decide which version of each rule applies to that person, on that app it works from most specific to least specific , and the first match wins 1\ team exception for this team, on this app (most specific) 2\ team exception for this team, any app 3\ app rule for this app 4\ global protection (the baseline) this is exactly what the inherited → overridden → additional groups in the drawers represent a rule is inherited from a broader level until a more specific level changes it two things that surprise people global protections apply everywhere — even on apps not in app rules the app rules tab governs app access and per‑app tuning; it does not limit where your behaviors run a global "hard block secrets" fires on any website allowing an app doesn't switch off your protections on it app access only controls visiting the app to exempt an app or team from a specific behavior, set that behavior to allow in the app's drawer or in a team exception — don't rely on the app being allowed when the activity itself is checked visiting an app is governed by the app's status in app rules typing, pasting, or transferring files is checked against every applicable behavior control if more than one matches, the strictest one wins hard block beats soft block beats log only use cases classify what kind of work was happening, for visibility and reporting a worked example say you want to protect secrets everywhere, block reddit for everyone, but let your engineering team use an internal pastebin freely global protections → behavior controls add secrets → hard block now secrets are blocked on every site app rules add reddit com and set its status to hard block optionally set a redirect to an approved alternative app rules add your internal pastebin, leave its status as allow , open its behaviors section, and override secrets to allow for that app team exceptions if only engineering should get that pastebin exemption, instead of step 3 add a team exception for engineering scoped to the pastebin, and set secrets to allow there — everyone else still gets the global hard block summary → publish quick reference section what it controls levels offered scope global protections → behavior controls real‑time detection of sensitive activity log only / soft block / hard block everyone, every site global protections → use cases recognizing the kind of work being done log only / soft block / hard block everyone, every site app rules → app access whether employees can use an app allow / log only / soft block / hard block (+ redirect on block) a specific app app rules → behaviors / use cases per‑app tuning of global rules allow / log only / soft block / hard block a specific app (app access must be allow) team exceptions per‑team overrides of everything above allow / log only / soft block / hard block (+ redirect on block) a team, optionally one app level meaning allow permitted; not logged or blocked log only permitted but recorded; no intervention soft block maro intervenes and can offer a safe way to continue hard block maro prevents the activity outright