Questions, answered.

Yes — this is one of the most important use cases we're building for. The InPolicy API and MCP server (coming soon) will let you route AI-generated outputs through the same policy layer before they're delivered to users. Contact us to get on the early-access list.

Governing agentic actions — not just communications — is the frontier of enterprise AI governance, and it's where InPolicy is headed. Today we focus on the communications layer. As the agent ecosystem matures, we're building toward a broader enforcement layer embedded earlier in the agent decision loop.

InPolicy is available at no cost for a limited time, subject to limitations. We have not yet announced pricing.

For most customers, the technical setup — extension deployment, SSO configuration and policy ingestion — can be completed in under a day. The more meaningful time investment is in policy review and configuration, which varies by organization.

Azure AD and Google Workspace identity.

Yes. For Google Workspace (Chrome), your IT department can install the extension via the Google Admin Console and push it to all managed devices. You can also configure policy to prevent users from disabling or uninstalling it.

InPolicy generally works on standard HTML text inputs. If you have a proprietary internal tool, we can work with you to ensure the extension recognizes the text fields correctly.

We test extensively against common enterprise extensions (LastPass, 1Password, Grammarly, Zoom). We've engineered InPolicy to play nicely with others, but if a conflict arises our support team will investigate.

InPolicy is designed to complement, not replace, existing DLP infrastructure. It operates at the point of composition — before a message is sent — whereas most DLP tools operate at the network or archive layer. Integration partnerships are on our roadmap.

We typically start with a focused pilot — one team, one or two policies — so your legal, IT and end-user stakeholders can experience InPolicy before a broader rollout. Most pilots run for 2–4 weeks. We work closely with you throughout to calibrate confidence thresholds and validate accuracy.

All customers have access to our support team via email. Enterprise customers receive a dedicated customer-success contact, priority response SLAs, and access to roadmap review sessions.

Both are supported. Write policies manually, or point InPolicy at existing documents (PDFs, Word, slide decks, Google Docs) and we'll parse them and suggest policies automatically. We also offer pre-built policy packs for common use cases as a strong starting point.

A three-level hierarchy: Divisions (e.g. Legal, HR, Marketing), Policy Areas within each Division, and individual Policies within each area. Each policy carries metadata that controls how it's enforced — severity, confidence threshold, applicable countries, applicable teams, start and expiry dates, and scope (internal / external / both).

A governed publishing workflow. Policies move through defined states — draft → submitted for review → published → deprecated — with different roles controlling each transition. Editors can attach justifications, leave comments, and discuss changes before they go through the approval flow. All changes are versioned and logged with full history available for audit.

Four default roles: Admin (manages users and billing), Policy Lead (approves and publishes policies for their division), Policy Editor (drafts and submits policies for review), and Viewer (end users who see violations in the extension but don't manage policies).

Yes — policies can be scoped to specific teams, divisions or countries.

Yes. Point InPolicy at a public web page — such as a regulatory guidance page or a published style guide — and we'll enforce the policies described on it directly. If the page is updated, enforcement reflects the current version automatically, with no re-import required.

On the roadmap. Conflict detection will flag when a new or edited policy contradicts an existing one and surface them for review before publishing.

Admins see aggregate, anonymized data across the organization: which policies are being flagged, how frequently, and how often users accept the suggested fix. All analytics are at the policy and team level — no data is linked to individual users.

No. InPolicy does not track or report violations at the individual level. This is a deliberate design choice — our analytics help organizations improve their policies and training, not monitor individuals.

Yes — admins can export analytics reports to CSV.

This depends on the permissions you set within InPolicy.

InPolicy is a suite of products that turns your policies into active, real-time guardrails:

• Browser extension — scans text as employees type in email, chat and docs, flags potential policy violations, explains the issue and suggests a fix before anything is sent.
• Web application (the "Policy Layer") — manage your policy library with roles & permissions, version control, comments, source-of-truth references, and a promotion flow for approvals.
• Policy Bot — an agent that lives in Google Docs as a commenter, flagging policy violations across long-form documents.
• API and MCP server (coming soon) — lets developers integrate InPolicy into their own applications and AI agents, so AI-generated outputs are constrained by policy too.

Any kind — legal, compliance, HR, brand, communications and beyond. Common patterns:

• Sales — prevent reps from promising features that don't exist yet.
• Legal — flag communications where employees inadvertently acknowledge liability before it leaves the building.
• HR — catch inappropriate or discriminatory language in recruiting communications.
• Finance — enforce quiet-period policies by flagging forward-looking statements.
• Marketing — enforce embargoes and launch timing.
• Medical / Life sciences — ensure adverse-event responses follow required procedures.

The shared pattern: a human or AI is drafting a communication, the stakes are high, and InPolicy catches the problem before it's sent.

Yes. Policies can be scoped to external-facing communications only, internal only, or both. Useful when, for example, a forward-looking-statements policy should apply to customer or investor messages but not to internal Slack.

InPolicy currently works on any text field within the Chrome browser. Support for Microsoft Edge and Microsoft Office products is planned.

Currently, InPolicy is optimized for English.

For detailed information on InPolicy's security architecture, data handling practices and privacy posture, see our Data Handling Overview, Privacy Policy, and Data Processing Agreement (DPA). For specific procurement or legal requirements, contact us at security@inpolicy.ai.

InPolicy does not use customer data — including policy documents, communications, or violation metadata — to train, fine-tune or improve any AI model.

For organizations with requirements around data residency or model access, private inference options — including deployment configurations that keep all data within your own cloud environment — are on our roadmap.

During onboarding, we ingest your policy documents — PDFs, wikis, playbooks — and parse them into structured, individual policies. Each policy is enriched with the metadata that makes it enforceable: applicable teams, jurisdictions, severity, confidence threshold, effective dates and more. Policies can also be written or added manually at any time.

InPolicy handles a spectrum of policy complexity:

• Standalone policies — evaluable from the content of the message alone (prohibited phrases, required disclaimers, formatting rules).
• Conversational policies — depend on what was said earlier in a thread. Our conversational context compression makes this practical without feeding entire thread histories to the model.
• Policies referencing an external source of truth — e.g. unsupported product claims, which require knowing what your product actually does.
• Policies requiring tenant context — facts not present in any internal doc. We build and maintain the specific knowledge base required for each policy.

Context handling is our proprietary, patent-pending core, approached on two levels:

Tenant context. Many violations can't be detected without real-world knowledge that isn't in the policy itself. We pre-assemble the specific, scoped knowledge required to enforce each rule.

Conversational context. For email and chat, the extension considers the surrounding thread, not just the current sentence. InPolicy compresses the thread down to only policy-relevant content before running the check.

No. InPolicy uses a retrieval-augmented (RAG) approach: every alert includes a citation linking back to the specific section of your uploaded policy document. If the AI can't find a source text to back up the claim, it doesn't flag the violation.

False-positive rates vary with your confidence thresholds and the specificity of your policy documents — more precisely written policies produce more accurate results. You can tune confidence per policy, and your admin can review flagging patterns over time to identify any over-triggering rules and adjust them.

Yes — it's core to our design philosophy. InPolicy supports enforcement at both stages of AI generation: injecting relevant policy constraints into the model's context before it generates a response, and checking the output afterward as a second layer. Developer integrations via API and MCP server are coming soon — contact us for early access.

A reasonable workaround for a one-off check, but it breaks down quickly for enterprise enforcement:

• Policy documentation — enterprise policies accumulate across teams over years. InPolicy manages your library as a governed dataset.
• Conversational context — meaningful violations depend on what was said earlier; raw threads are too long and too noisy. We compress them to the policy-relevant signal.
• Tenant knowledge — many policies need real-world facts not in the policy text. We pre-assemble exactly what's needed.
• Data governance — pasting sensitive communications into a consumer AI tool raises serious concerns. InPolicy is built for enterprise use, with SSO and audit capabilities.

Yes. You can configure a different confidence threshold for each individual policy.

No — InPolicy does not block any human user from sending a message.

We design for low friction. With appropriate confidence thresholds, most end-users see InPolicy only a few times per week. Users also learn from InPolicy and therefore see it less over time.

When a violation is flagged, the user may see a Rewrite button. Clicking it generates a new version of the sentence that conveys the same meaning without the risky language. The user can accept, edit or reject the suggestion.

No. Analysis happens asynchronously — we don't block the UI thread, so typing stays smooth even while the AI is thinking.

Nothing — and that's intentional. InPolicy is a real-time coaching tool, not a surveillance or enforcement system. Violations are surfaced privately to the individual user in the moment. No violation data is stored tied to any individual; no one gets in trouble; there is no follow-up or escalation.

InPolicy currently supports Chrome, including enterprise-managed Chrome via Google Workspace. Microsoft Edge and Microsoft Office support is planned. Firefox and Safari are not currently on the roadmap.