Browser extension

Catching data before the submit fires.

The extension reads the composer of supported AI tools before a message is submitted. That timing is the whole design: it is what allows warn and block to work without intercepting TLS, and without a device-trusted root certificate.

MESSAGE SEND
Caught at the composer, while stopping it is still possible.
Chrome and Edge MV3 Force-installed by policy No TLS interception

Composer, not network

Prevention beats detection.

Itzal supports both paths. The extension is primary because most AI tool use is web-based and because a message you can still stop is worth more than one you can only report.

Extension compared with a TLS-inspecting proxy
 Browser extensionTLS-inspecting proxy
Sees textBefore sendAfter send
Can block too late
Needs a trusted root CA
Defeated by certificate pinningSometimes
Covers desktop apps
Employee-visible intrusivenessLowerHigher

On each submission

Five steps, and the third matters more than it looks.

The deadline is enforced in the extension, at send time — not when the agent acknowledges. So an agent that hangs, crashes, or was never installed produces exactly the same experience as one that is merely slow. There is no configuration in which a broken agent silently freezes someone’s work.

  1. 01

    Read the outbound text and its destination

    From the composer, before submission.

  2. 02

    Hand it to the local agent

    Over native messaging — same device, no network.

  3. 03

    Start its own timer

    At send time, independent of the agent.

  4. 04

    Apply the decision

    Allow, warn inline, or block the submit.

  5. 05

    Or release, if the timer wins

    And mark the event as deadline-exceeded, visibly.

What the person sees

The category, never the value.

Log only: nothing. No banner, no delay. Warn: an inline banner naming the data type found — “this message appears to contain a card number” — and either outcome is recorded. Block: the submit is prevented, with the same explanation, until the content is edited.

Warnings name the category, never the matched value, and never a count-with-value combination that would let the banner itself become the leak.

Coverage honesty, in the extension itself

Binding is verified, not assumed.

The extension checks on each page load that its hooks are actually bound to the live composer, and reports binding state. When an AI tool ships a redesign and a selector stops matching, that surfaces as a coverage incident rather than a quiet decline in detections — the difference between “we see nothing happening” and “we have stopped seeing”.

It also does not claim what it cannot do. File attachments, pasted images and private windows are enumerated as gaps, in the console as well as on the coverage page. Firefox and Safari are not currently supported; if unmanaged browsers are permitted in your environment, size that gap deliberately.

Straight answers

Why an extension rather than a network proxy?

An extension reads text in the composer before submission, so it can block a message that has not been sent. A proxy sees traffic only after send, and requires a device-trusted root CA.

Can employees disable it?

Not when force-installed via Chrome or Edge enterprise policy through Intune, GPO, Jamf or Kandji. Removal attempts and unbinding are reported as coverage events.

Does the extension send page content anywhere?

No. It passes the outbound text block to the local agent over a native messaging channel on the same device. Nothing leaves the machine except the redacted event record.

Force-installed, not requested.

Users do not install it, cannot remove it, and never need to know its ID.