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.
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:
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.
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:
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 |