Your First Detection: A Guided Walkthrough

A ten-minute exercise: install Zeuslock, paste a safe AWS test key into ChatGPT, and watch the incident appear in the Operator Console in real time.

What you will do in the next ten minutes

By the end of this walkthrough you will have triggered a real Zeuslock detection, watched it land in the Operator Console, and stepped through the same finding under all three policy modes: Monitor, Anonymize, and Block. No real secrets are used at any point.

Prerequisites

  • The Zeuslock browser extension installed in Chrome, Edge, Firefox or Safari, and paired to your organization.
  • An account with the Operator role on the Operator Console at app.zeuslock.ai.
  • A logged-in ChatGPT session in the same browser profile.

The test value we use, AKIAIOSFODNN7EXAMPLE, is the example AWS access key ID published in Amazon's official documentation. It is not a real credential, it grants no access to anything, and it is safe to paste into a chat window. Zeuslock's regex still detects it because the structural pattern matches a real AWS key.

Step by step

  1. Set your org to Monitor mode. In the Operator Console, go to Settings → Detection Policy → Default profile and set Mode: Monitor. Save. Monitor mode forwards prompts unchanged but still records every finding — this is where every rollout should start.
  2. Open ChatGPT. Load chat.openai.com in a new tab and confirm the Zeuslock toolbar icon is green. Green means the extension is paired, the policy is loaded, and the page is in scope.
  3. Paste the test key. In a new chat, type the sentence Here is my AWS key for the deploy script: AKIAIOSFODNN7EXAMPLE and submit it.
  4. Observe the in-browser indicator. Immediately above the prompt box, Zeuslock surfaces a small banner: 1 finding: AWS access key (monitor mode — sent as-is). The prompt is forwarded to OpenAI unmodified, exactly as the policy intended.
  5. Switch to the Operator Console. Open the Incidents tab. Within roughly three seconds the new incident appears at the top of the list, showing severity, finding type (api_key:aws), an anonymized prompt preview, the user, the browser, and the source URL (chat.openai.com).
  6. Drill into the incident. Click it to open the full timeline. You will see the regex hit on the first detection layer, the ML confirmation score from the EU-hosted model, the local context heuristics, and a recommended next action. The raw secret is never stored in the console — only a salted hash and a redacted preview.

Now repeat the same test under stricter modes

The whole point of Zeuslock's rollout pattern is that you can prove each mode safely on real traffic before you tighten the screws. Go back to Settings → Detection Policy → Default profile and change Mode to Anonymize. Save, refresh your ChatGPT tab, and submit the same sentence again.

This time, the prompt that actually reaches ChatGPT is Here is my AWS key for the deploy script: AKIAIO********7EXAMPLE. The model still receives a structurally valid-looking token, so any downstream reasoning about "a key was provided" still works, but the real value never leaves the browser. The Operator Console records a second incident with an anonymized tag.

Now switch the same profile to Block, save, and try a third time. The prompt is intercepted before submission. ChatGPT sees nothing at all. Your end user gets a friendly modal explaining what was blocked and why, with a link to your internal policy if you have configured one. The Operator Console records a third incident, tagged blocked, with full attribution.

How to read the three results side by side

Open the Incidents tab and filter by your own user. You should now see three rows for the same prompt, one per mode. Compare them:

  • Monitor — the prompt was sent, the secret left the browser, you have visibility but no protection.
  • Anonymize — the prompt was sent in a sanitized form, the model still works, the secret stayed local.
  • Block — nothing left the browser; the user was coached in the moment.

This is exactly the staged rollout we recommend: Monitor for the first two weeks to map your real exposure, Anonymize for the next three, then Block from week six onwards for the finding types where false positives are negligible (AWS keys, Stripe keys, IBANs, and similar high-confidence patterns).

Next steps

  1. Invite your teammates. Operator Console → Settings → Team, send invites, and assign the Operator or Viewer role. SSO via Okta, Azure AD or Google Workspace can be enabled from the same screen.
  2. Wire up Slack. Settings → Integrations → Slack, paste your webhook URL, and route high-severity incidents to your security channel. HMAC signatures are on by default.
  3. Build a custom detector. If your organization issues its own internal identifiers (employee IDs, internal project codes, customer reference numbers), open Detectors → Custom → New, provide a regex and a handful of positive and negative examples, then run the backtest against the last 30 days of incidents before you flip it to Block.

You now have a working detection, a real incident, and a feel for how each mode behaves. Move on to defining your first production profile.