Local data protection for Codex.

TigerMole temporarily processes content from supported flows in memory, replaces the sensitive values it detects, and sends the remaining content to the selected provider. It does not keep the prompt or response as an on-disk conversation.

AVAILABLE · Windows 10/11 · Ubuntu 20.04+ / Debian 11+ · Available since TigerMole 1.4.6

CONCEPTUAL FLOW · CODEXAVAILABLE
01Code contextAPI_TOKEN=[fictional_value]
02TigerMole · local boundarytemporary in-memory processing
03Replaced value[redacted_credential_01]
04Selected providerremaining content
An illustrative view of the boundary. The coverage matrix documents the exact behaviour of each version.
01 · LOCAL BOUNDARY

Context is checked before it is sent.

TigerMole adds a data boundary to supported Codex flows without assuming tool authorization or content classification.

STEP 01

Process in memory

TigerMole temporarily receives content on the device to examine the values present in a supported flow.

STEP 02

Replace detected values

Values that match active rules are locally replaced with opaque references.

STEP 03

Continue to the provider

The remaining content is sent directly to the selected provider to complete the request.

02 · EVIDENCE

Explain the control that actually exists.

Local evidence helps describe where the boundary acts and which metadata it retains without turning TigerMole into a conversation repository.

Local technical metadata

Recorded entries provide metadata about detections and protection actions. The published schema defines the fields available in each version.

  • Local metadata about detections.
  • Protection actions applied by the boundary.
  • The persistent audit does not include the prompt, response, or original secret.

Coverage, not universal promises

Detection depends on rules, context, and version. A value that is not detected is not automatically replaced.

  • TigerMole does not decide whether Codex is authorized.
  • It does not replace DLP, CASB, contracts, access controls, or internal policies.
  • Protection is limited to supported flows and detected values.
Review coverage and architecture
03 · GETTING STARTED

Verify the integration with fictional data.

The first test should confirm version, state, and coverage without introducing real secrets into a demonstration.

01

Check the version

Install a TigerMole version equal to or later than the minimum shown for Codex.

02

Follow the guide

Complete the documented installation and configuration for your platform and licence.

03

Review the result

Use a fictional preset, confirm the protection state, and review the resulting local event.

04 · QUESTIONS

Questions about Codex and TigerMole.

These answers describe the published scope. The Security Evidence Pack remains the versioned technical reference.

Does TigerMole store Codex conversations?

TigerMole does not keep the prompt or response as an on-disk conversation. The persistent audit is limited to metadata defined by its published schema.

Does detection cover every type of secret?

No. Coverage depends on active rules and their context. The versioned matrix documents categories, limitations, and supported flows.

Does TigerMole authorize the use of Codex?

No. The organization continues to decide which tools it authorizes. TigerMole complements—it does not replace—contracts, DPAs, access controls, internal policies, and assurances from the AI provider.

Put a local boundary before the context.

Review the flow with your technical team and validate the integration with fictional data.

Your privacy, your choice

We use essential storage to keep the site working and, only with your consent, analytics through PostHog and Google Analytics 4. We do not load advertising providers. Read our Privacy Policy.