Detection Engineering for OpenAI Codex Audit Logs: How to Set It Up in Monad

In Part 1, we covered what security teams should detect in the Codex OTel stream: weakened sandbox settings, prompt logging, destructive tool approvals, network-enabled sessions, and unexpected originators.

This post is the practical follow-up: how to get Codex telemetry flowing into Monad so you can inspect it, normalize it, redact sensitive fields, and route it to the right destination.

Monad’s OpenAI Codex input receives OpenTelemetry data emitted by Codex. The Monad-side setup is intentionally light: create the Codex input, build a pipeline with your output destination of choice, create a write-scoped API key, then configure Codex to send telemetry to Monad using your pipeline ID and API key.

What you’ll need

Before you start, make sure you have:

• A Monad organization
• Permission to create inputs, pipelines, roles, and API keys in Monad
• An output destination for the Codex telemetry, such as your SIEM, data lake, or restricted storage destination
• Access to your Codex TOML config file
• A safe place to temporarily store your Monad pipeline ID and API token while you configure Codex

You will create the Codex input, pipeline, role, and API key as part of the setup below. The only API key permission required is pipeline:data:write.

Step 1: Create the Codex input in Monad

In Monad, create a new input component and select OpenAI Codex.

Give the input a clear name and, optionally, a description so your team can recognize what it is collecting.

There is no extra configuration required on the Monad input itself. The exporter configuration happens on the Codex side.

Step 2: Create a pipeline and copy the pipeline ID

Create a new pipeline with your OpenAI Codex input and your output destination of choice.

Give the pipeline a name and, optionally, a description that identifies the source, destination, and use case.

After the pipeline is created, open the details panel and use the clipboard icon to copy the pipeline ID. You will need this value when you fill out your Codex TOML file.

Step 3: Create a write-scoped API key

Create a new role for the API key that will write data to your pipeline.

Give the role a name and, optionally, a description. The only permission required is pipeline:data:write.

Next, create a new API key. Assign the new pipeline:data:write role to the key, give it a name, add an optional description, and set an expiration time.

When you press Create, Monad will show the API token. Copy it immediately. The token is only shown once, and you will need it in your Codex TOML file.

Step 4: Configure Codex to send telemetry to Monad

Open your Codex TOML config and add the OTLP exporter configuration.

If you do not already have a TOML file, save the snippet below as a new file. If you already have one but it does not have an [otel] section, you can append the snippet to your existing file.

[otel]
exporter = { otlp-grpc = {
  endpoint = "https://app.monad.com:4317",
  headers = { "Authorization" = "ApiKey <your-api-key>", "Monad-Pipeline-Id" = "<your-pipeline-id>" }
}}

Replace:

• <your-api-key> with the Monad API token you copied when creating the API key
• <your-pipeline-id> with the ID of the Monad pipeline that contains your Codex input

For organization-wide enforcement, see the Codex CLI configuration reference.

Step 5: Generate a test Codex session

Start a new Codex session and perform a simple action that should generate telemetry.

For example:

• Start a conversation
• Ask Codex to inspect a test file
• Approve or deny a tool action
• Exit the session cleanly

At this point, you are only validating that telemetry is flowing. Detection logic comes later.

Step 6: Validate events in Monad

Return to Monad and confirm that Codex events are arriving.

Start by looking for events like:

• codex.conversation_starts
• codex.api_request
• codex.sse_event
• codex.user_prompt
• codex.tool_decision
• codex.tool_result

These are the same event types we used for the detection patterns in Part 1.

Check that the basics are present:

• Session metadata
• Service name or originator
• Model
• Sandbox mode
• Approval policy
• Tool decisions
• Prompt metadata

Here is an example of what a Codex audit log event can look like once it hits your pipeline:

{
  "resourceLogs": [
    {
      "resource": {
        "attributes": [
          {"key": "telemetry.sdk.name", "value": {"stringValue": "opentelemetry"}},
          {"key": "telemetry.sdk.version", "value": {"stringValue": "0.31.0"}},
          {"key": "telemetry.sdk.language", "value": {"stringValue": "rust"}},
          {"key": "service.name", "value": {"stringValue": "codex-cli"}},
          {"key": "service.version", "value": {"stringValue": "0.119.0"}},
          {"key": "deployment.environment", "value": {"stringValue": "production"}},
          {"key": "host.name", "value": {"stringValue": "eng-mbp-042.corp.example.com"}},
          {"key": "os.type", "value": {"stringValue": "darwin"}},
          {"key": "team.name", "value": {"stringValue": "platform-engineering"}}
        ],
        "droppedAttributesCount": 0,
        "entityRefs": []
      },
      "scopeLogs": [
        {
          "scope": {
            "name": "codex_otel.log_only",
            "version": "0.119.0",
            "attributes": [],
            "droppedAttributesCount": 0
          },
          "logRecords": [
            {
              "timeUnixNano": "1780934415239000000",
              "observedTimeUnixNano": "1780934415241267000",
              "severityNumber": 9,
              "severityText": "INFO",
              "body": null,
              "attributes": [
                {"key": "event.name", "value": {"stringValue": "codex.user_prompt"}},
                {"key": "event.timestamp", "value": {"stringValue": "2026-06-08T19:20:15.239Z"}},
                {"key": "conversation.id", "value": {"stringValue": "conv_01JY7V6K4M8Q9R2N5Z3H1A7BCE"}},
                {"key": "app.version", "value": {"stringValue": "0.119.0"}},
                {"key": "auth_mode", "value": {"stringValue": "ChatGPT"}},
                {"key": "originator", "value": {"stringValue": "Codex_CLI"}},
                {"key": "user.account_id", "value": {"stringValue": "acct_01JY7T9K0P4ME2D8Q3K6F9G1ZA"}},
                {"key": "user.email", "value": {"stringValue": "alex.rivera@example.com"}},
                {"key": "terminal.type", "value": {"stringValue": "vscode"}},
                {"key": "model", "value": {"stringValue": "gpt-5.2-codex"}},
                {"key": "slug", "value": {"stringValue": "gpt-5.2-codex"}},
                {"key": "sandbox_mode", "value": {"stringValue": "workspace-write"}},
                {"key": "approval_policy", "value": {"stringValue": "on-request"}},
                {"key": "network_access", "value": {"boolValue": false}},
                {"key": "cwd", "value": {"stringValue": "/Users/alex/src/checkout-service"}},
                {"key": "git.repository", "value": {"stringValue": "github.com/example/checkout-service"}},
                {"key": "git.branch", "value": {"stringValue": "feature/retry-idempotency"}},
                {"key": "prompt_length", "value": {"intValue": "184"}},
                {"key": "prompt", "value": {"stringValue": "Review the retry logic in src/payments/idempotency.ts and suggest tests for duplicate webhook delivery."}}
              ],
              "droppedAttributesCount": 0,
              "flags": 1,
              "traceId": "4d2f2b4f6f0a4f64b5b8c1a2d8e7c9f0",
              "spanId": "9f4c8a1b2d7e6c31",
              "eventName": "event otel/src/events/session_telemetry.rs:848"
            }
          ],
          "schemaUrl": ""
        }
      ],
      "schemaUrl": ""
    }
  ]
}

‍Notice the fields that are useful for detections and routing: event.name, originator, model, auth_mode, conversation.id, and prompt-related metadata. Also notice why redaction matters: prompts, user identifiers, hostnames, trace IDs, and span IDs can expose sensitive developer context if they are broadly routed downstream.

Transforms are useful here because they let you shape the Codex stream before it reaches your destination. For example, you can use transforms to redact sensitive fields, remove noisy or unnecessary attributes, and reduce payload size so downstream tools receive the data they need without carrying every raw prompt, tool result, or high-cardinality identifier. See Monad’s Transform user docs for more detail.

Step 7: Decide what gets routed where

Once events are flowing, decide how the stream should be handled before it reaches downstream tools. There is no universal routing model for Codex telemetry: every organization has a different threat profile, data sensitivity model, retention policy, and set of downstream tools.

As a starting point, separate the data that is useful for broad security monitoring from the data that should be more tightly controlled. Session starts, tool decisions, API request metadata, and prompt metadata may be useful in a SIEM or data lake. Prompt bodies, tool output, shell output, file paths, patches, raw payloads, and high-cardinality identifiers may need stronger redaction, tighter access controls, or a separate storage path.

The goal is not to send everything everywhere. It is to preserve the telemetry that helps security teams investigate Codex activity while limiting unnecessary exposure of sensitive developer context.

Step 8: Get value from the data

Once Codex telemetry is flowing, the next step is to put that data to work. One way to do that is by using the detections from Part 1 as a foundation for your own monitoring and investigation workflows.

Troubleshooting

If events are not showing up, check:

• The Codex input exists and is attached to the right pipeline
• The pipeline has the output destination you expect
• The pipeline ID is correct
• The API key has pipeline:data:write
• The Authorization header uses ApiKey <your-api-key>
• The Monad-Pipeline-Id header is present
• The endpoint is set to https://app.monad.com:4317
• The Codex TOML file is saved in the expected location
• Codex generated activity after the config was saved

Closing

AI coding assistants are now core to the software delivery path. That means security teams need visibility into how these tools are being used, what actions they are taking, and where the resulting telemetry is going.

For CISOs, Codex audit logs help answer a basic governance question: can we see and control agentic developer activity before it becomes risk? For practitioners, the value is more immediate: reliable telemetry that can be inspected, shaped, routed, and used in investigations without sending every raw prompt or tool result everywhere by default.

If your team is already experimenting with Codex, start by getting the telemetry into Monad, validating the events, and deciding how the data should be handled. From there, use the detection ideas in Part 1 as a foundation for turning that visibility into practical monitoring. To see how this works in practice, schedule a Monad demo.

‍