Before you begin
Use an organization-managed Windows 11 device and Chrome profile for the proposed first pilot. Obtain the organization’s consent, device-management approval and named policy owner before deploying any sensor.
- Agree the exact cohort, test origin and fallback policy.
- Check that the pilot agreement and processing terms have been reviewed and agreed.
Supported scope and current status
The first-pilot browser scope is typed and pasted text in the standard signed-in ChatGPT composer. Endpoint, other browser, file and sync-root functions are broader product surfaces outside the proposed first pilot unless separately approved and verified.
- Compare each requested device path with /coverage and /faq#disclosures.
- Require a current managed-device result before calling the cohort protected.
Compare this path with the published coverage table and the coverage guide.
Set up the path
After workspace approval, coordinate the managed Chrome installation through your device-management administrator. Use the release-specific package and approved policy supplied for your tenant; do not improvise a package or policy source.
- Admit one test device and confirm the installed sensor and tenant binding.
- Activate the approved policy separately and keep a rollback path.
Use the workflow
Begin with one safe synthetic submission and compare the browser result with the policy decision. Add devices only in agreed stages after the first device’s install, policy and evidence all read back correctly.
- Document the actual device and browser profile used.
- Repeat the same scoped test after each rollout stage.
Verify the result
A downloaded package or management assignment is not proof of an active control. Read back enrollment, sensor health, policy version and the destination outcome from the managed device.
- Confirm an allowed synthetic value reaches the destination.
- Confirm a sensitive synthetic value receives the expected refusal or transformation and a matching event.
Coverage references: 19 requirements, 0 currently passed
This guide is bound to 19 requirements in RedactWall's acceptance crosswalk, which is maintained internally and not published. A requirement counts as passed here only after current evidence for every bound scenario and authority has been published; none has been published yet.
See the public verification overview and the documentation coverage guide.
Denials and recovery
If install, tenant binding, policy adoption or evidence fails, stop expansion and restore the last known safe managed assignment. Do not infer safety from an empty event list when the device is unreadable.
- Capture non-sensitive diagnostics and the current policy version.
- Re-test one device after the administrator completes rollback or repair.
For customer-side next steps, read Recovery and support.
Billing and integration handoffs
One managed device consumes one seat even if both a browser sensor and an endpoint agent are present. Your MDM administrator owns assignment and removal; RedactWall assists with the release-specific package and enrollment handoff.
- Check the /pricing seat rule before expanding the cohort.
- Coordinate any separate gateway or identity integration with its own owner.
Limits to keep in view
Managed installation and composer interception have not yet been run on a managed Windows 11 endpoint in the published pilot proof. A declared package, MDM policy or supported OS name does not prove a successful deployment.
- Do not enroll customer data until release-specific proof exists.
- Keep Edge, BYOD, file/image/voice modes and other apps out of the first-pilot claim.
Review the current Disclosures before relying on a capability.