Have Questions?

InPolicy includes the following features: • Browser extension • Web application for managing policies (the "Policy Layer") • Agent for reviewing long form documents in Google Docs (the "Policy Bot") • API and MCP server for developers (coming soon) The browser extension helps companies enforce their policies in real-time. It uses AI to scan text as employees type in email, chat, and documents. When it detects a potential policy violation (like harassment, insider trading risks, or data leaks), it alerts the user, explains the violation, and suggests a fix before the message is sent. The web application is a tool for teams to collaborate on policies, with robust roles and permissions, version control, and commenting. It supports ingesting existing policy documents, referencing external source of truth documents, and a promotion flow for approving new policies or edits to policies. The Policy Bot agent can be added as a commenter on Google Docs, and will flag any policy violations, including those that require long form context. This is particularly valuable for legal teams who currently spend time manually reviewing sales proposals, marketing materials, and other long-form documents before they go out — the Policy Bot handles the first pass automatically. The API and MCP server will allow developers to integrate InPolicy into their own applications and AI agents, so that AI-generated outputs are also constrained by policy. (Coming soon — contact us to get on the early access list.)

InPolicy can enforce any kind of company policy — legal, compliance, HR, brand, communications, and beyond. A few examples: • Sales — Prevent reps from promising features or capabilities that don't exist yet, reducing legal exposure and customer expectation mismatches. • Legal — Flag communications where employees inadvertently acknowledge liability or legal risk, before those words leave the building. • HR — Catch inappropriate or discriminatory language about candidates in recruiting communications and internal discussions. • Finance — Enforce quiet period policies by flagging forward-looking statements or material disclosures during restricted windows. • Marketing — Enforce embargoes and launch timing, such as preventing any mention of a new brand or product before an announced release date. • Medical / Life Sciences — Ensure that responses to adverse event reports follow required procedures and don't contain language that could create regulatory exposure. These examples share a common pattern: a human or AI is drafting a communication, and the stakes of getting it wrong are high. InPolicy catches the problem before it's sent.

Yes. Policies can be scoped to apply to external-facing communications only, internal communications only, or both. This is useful when, for example, a legal policy about forward-looking statements should only apply when writing to customers or investors, not in internal Slack messages.

InPolicy currently works on any standard HTML text field in Chrome — `<input>`, `<textarea>`, and `contenteditable` elements. Custom canvas-based editors (e.g. the Google Docs body) are handled separately by the PolicyBot agent rather than the in-page extension. Support for Microsoft Edge and Microsoft Office products is planned.

Currently, InPolicy is optimized for English.

During onboarding, we ingest your policy documents — PDFs, Wikis, Playbooks, and more. Rather than simply storing these as raw text, InPolicy parses them into structured, individual policies and enriches each one with the metadata required to make it enforceable: applicable teams, jurisdictions, severity, confidence threshold, effective dates, and more. This structured representation is what allows the AI to know not just what your rules say, but when and to whom each one applies. Policies can also be written or added manually at any time, either from scratch or with assistance from our team.

InPolicy is designed to handle a spectrum of policy complexity: • Standalone policies — These can be evaluated based on the content of the message alone, without any additional context. Examples: prohibited words or phrases, required legal disclaimers, formatting requirements for regulated communications. • Conversational policies — Policies that depend on what has been said earlier in a thread. For example, "if a customer raises a billing dispute, do not make any commitments about refunds." Detecting this requires understanding the thread, not just the current message. • Policies referencing an external source of truth — Some policies can only be enforced by checking against an authoritative external document. A policy prohibiting unsupported product claims, for example, requires knowing what your product actually does. • Policies requiring tenant context — These policies refer to real-world entities or facts that aren't in any internal document. A policy prohibiting disparagement of competitors, for example, requires knowing who your competitors are.

Context handling is where InPolicy's proprietary, patent-pending technology makes a huge difference, at two levels. The first is tenant context: many policy violations can't be detected without real-world knowledge that isn't in the policy document itself. InPolicy pre-assembles the specific, scoped knowledge required to enforce each policy — not a general profile of your company, but precisely the facts needed to evaluate whether a given rule has been violated. The second is conversational context: for short-form communications like email and chat, the extension considers the surrounding thread, not just the sentence being typed. Rather than feeding an entire message history to the AI, InPolicy compresses the thread down to only the policy-relevant content before running a check. For longer documents, the Policy Bot is designed specifically for full-document review, so violations that only emerge from cumulative context are caught.

To prevent this, InPolicy uses a "Retrieval Augmented Generation" (RAG) approach. Every alert includes a reference to the specific policy from your library that the AI matched against. If the AI can't ground the flag in one of your active policies, the alert is suppressed.

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

Yes — and this is a core part of our design philosophy. As enterprises adopt AI tools and chatbots, those systems can produce outputs that violate company policy just as humans can. InPolicy supports policy enforcement at both stages of AI generation: injecting the relevant policy constraints into a model's context before it generates a response, and checking the output after generation as a second layer. Developer integration options via API and MCP server are coming soon.

It's a reasonable workaround for a one-off check, but it breaks down for enterprise policy enforcement — for a few fundamental reasons. First, the policy documentation problem: enterprise policies accumulate across teams over years, go stale, and are updated frequently. InPolicy manages your policy library as a governed dataset — structured, versioned, and scoped. Second, the conversational context problem: most meaningful violations depend on what was said earlier in a thread. InPolicy compresses entire conversation histories down to the policy-relevant signal before running a check. Third, the tenant knowledge problem: many policies can't be enforced without real-world knowledge that isn't in the policy document at all. InPolicy pre-assembles and maintains exactly the facts needed to enforce each policy. Finally, the data governance problem: pasting sensitive company communications into a consumer AI tool raises serious data governance concerns. InPolicy is designed for enterprise use, with appropriate data handling practices, SSO, and audit capabilities.

Yes. You can configure different confidence thresholds for each individual policy.

Both options are supported. You can write policies manually, or you can point InPolicy at existing documents — PDFs, Word docs, slide decks, or Google Docs — and InPolicy will parse them and suggest policies automatically. We also offer pre-built policy packs for common use cases (such as competition law, financial services communications, and medical sales) that give you a strong starting point out of the box. For organizations that want more hands-on help, our team can work with you directly to draft policies tailored to your needs.

InPolicy structures your policy library in a three-level hierarchy: Divisions (e.g. Legal, HR, Marketing), Policy Areas within each Division (e.g. Antitrust, Employee Communications), and individual Policies within each area. Each policy carries metadata that controls how it's enforced — including severity, confidence threshold, applicable countries, applicable teams, start and expiry dates, and whether it applies to internal communications, external communications, or both.

InPolicy supports a governed publishing workflow. Policies move through defined states — draft, submitted for review, published, and deprecated — with different roles controlling each transition. A Policy Editor can draft and submit changes; a Policy Lead can approve and publish them. Each Division and Policy Area has a designated owner who is responsible for approving changes within their scope. Policy Editors can attach a justification to any policy explaining the reasoning behind it. Editors can also leave comments on policies, making it easy to discuss proposed changes before they go through the approval flow. All changes are versioned and logged, with full history available for audit.

InPolicy has four 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). Permissions can be scoped system-wide or down to individual policy areas.

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

Yes. You can point InPolicy at a public web page — such as a regulatory guidance page or a published style guide — and InPolicy will enforce the policies described on that page directly. If the page is updated, enforcement automatically reflects the current version, without any re-import required. Support for using internal documents such as Google Docs as live policy sources is planned.

This is on our roadmap. Conflict detection will flag when a new or edited policy contradicts an existing one — for example, if two policies in different areas give inconsistent guidance on the same topic. Conflicts will be surfaced for review before a policy can be published.

Admins can see aggregate, anonymized data across the organization: which policies are being flagged, how frequently, and how often users are accepting 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 are built to help organizations improve their policies and training, not to monitor individual employees.

Yes. Admins can export analytics reports to CSV.

This depends on the permissions you set within InPolicy.

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 their sentence that conveys the same meaning but removes the risky language. The user can accept, edit, or reject this suggestion.

No. Analysis happens asynchronously. We do not block the UI thread, so typing remains buttery smooth even while the AI is thinking.

Nothing — and that's intentional. InPolicy is designed as 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 user, no one gets in trouble, and there is no follow-up or escalation. At the organization level, admins have access to aggregate, anonymized analytics — which policies are being flagged, how often, and how often users are accepting the suggested fix. This helps compliance teams understand where training or policy clarity may be needed, without monitoring any individual employee.

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

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. We provide onboarding support to help your team get to a confident go-live.

We support 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 have 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; reach out if you have a specific integration requirement.

Yes — this is one of the most important use cases we're building for. The InPolicy API and MCP server (coming soon) will allow you to route AI-generated outputs through the same policy layer before they're delivered to users. This means your internal chatbots, copilots, and automated workflows will be subject to the same compliance rules as your human employees. 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 policy enforcement layer that can be embedded earlier in the agent decision loop.

We typically start with a focused pilot — one team, one or two policies — to let your legal, IT, and end-user stakeholders 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.

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