Know what runs where.

Cortex uses a local relay and supported capture paths to make AI work inspectable. Pinned traffic keeps its selected provider. Configured routing can choose among eligible models. Capture is prepared on device, and synchronization follows the policy of the selected deployment.

Looking for connected sources? Open the Semantic Model integrations overview.

System Overview

Provider traffic and Cortex telemetry follow separate paths.

A request follows its selected provider route. Cortex captures supported activity locally, then synchronizes only approved telemetry to the selected deployment under its access, retention, and deletion policy.

Fig. 1: System overview

The relay carries model traffic. Capture runs on a separate channel and does not change the selected provider path.

Device boundary

The Sensor, local relay, browser proxy, capture policy, and on-device Inspector run at the device boundary.

Provider boundary

The selected provider receives the request on its own route and returns the response on the same provider path.

Data-plane boundary

Approved telemetry can synchronize under the storage, processing, retention, and deletion policy of the selected deployment.

Access boundary

Access to synchronized evidence is limited by the deployment’s access controls and the source permissions that apply.

The next section follows one request through those boundaries.

Request flow

Follow one request end to end.

A supported tool sends its request to the local relay. The relay validates the intended upstream, forwards the request, and streams the provider response back to the tool. Policy-enabled capture is reconstructed in parallel and handled on the telemetry path.

Fig. 2: Request lifecycle

The selected provider streams its response back through the local relay. Policy-enabled upload handles approved, minimized telemetry on a separate path.

Supported tools enter this flow through documented local connection paths.

On-device capture

Capture and minimization start at the device boundary.

The Cortex Sensor supervises the local relay, browser proxy, capture policy, and upload state. Supported surfaces depend on deployment configuration. Local policy determines which telemetry is written and prepared for synchronization.

On macOS, the tray app runs in the background, supervises the sidecar, manages local trust, and applies the configured browser proxy settings.

CLI agents connect by pointing supported provider proxy or base URLs at the local relay. The sidecar can also run headlessly when the deployment does not use the tray.

Component	Address	Role
CLI relay	127.0.0.1:9000	Forwards supported CLI and agent traffic to the validated upstream
Browser proxy	127.0.0.1:9001	Handles supported browser and desktop traffic under the configured proxy path
PAC server	127.0.0.1:19090	Serves host-scoped proxy configuration to supported browsers
Local store	Application data directory	Holds captured exchanges, upload state, counters, and diagnostics under local policy

Cortex Sensor runs quietly in the background.

Employees keep their existing tools. Operators can review relay health, capture coverage, minimization, and synchronization state from the local Sensor.

Background runtimeLocal status

Cortex SensorRunning

Configured locally

Local capture for configured CLI, browser, and desktop surfaces. Capture is prepared on this device before approved telemetry synchronizes.

Capture healthThis sensor process

Capture policy

Applied

Path coverage

Configured

Synchronization

Policy-enabled

Capture modesSensor · CLI · Browser

CLI captureConfigured

Configured CLI clients use the local relay under the selected capture policy.

Browser captureConfigured path

Supported browser traffic follows the configured PAC and local proxy path.

SynchronizationPolicy-enabled

Approved, minimized telemetry follows the selected deployment policy.

Capture policy applies on device

Synchronization follows the selected deployment policy

The runtime is shared. Each supported surface still has its own connection path.

Supported capture connections

Connect supported tools through documented local paths.

CLI agents use the local relay. Supported browser and desktop surfaces use configured proxy paths. Coverage depends on the tool, provider, authentication mode, and deployment policy.

Fig. 3: CLI relay request flow

The tool sends the request to the local relay. The relay validates the upstream, forwards the request, and streams the provider response back. Capture is reconstructed in parallel.

Browser and desktop surfaces

Supported browser surfaces use a host-scoped proxy. The PAC routes selected AI hosts through the local browser proxy. Path-level capture decisions happen inside the sidecar after local TLS termination.

Chrome
Safari

Fig. 4: Browser capture

Host-scoped routing sends supported browser traffic through the local proxy. The sidecar forwards requests to the validated origin and applies path-level capture policy.

The tray serves a PAC file from 127.0.0.1:19090.

A managed browser uses the configured PAC URL or operating-system proxy configuration.

The PAC sends supported AI hosts through the browser proxy on 127.0.0.1:9001.

The proxy terminates TLS with the locally trusted Cortex certificate.

The proxy forwards decrypted requests to the validated origin. Only supported paths are captured.

Source context

Connection paths explain transport. The Semantic Model explains source evidence.

Capture mechanics live here. For source records, provenance, availability, and the work model built from them, see the Semantic Model.

See connected sources

A connection does not decide what Cortex retains or synchronizes. Policy does.

Data flow

Control what is captured, synchronized, and retained.

Secrets are removed on device. The active capture profile determines whether supported request and response bodies are written. Semantic reconstruction stays local by default. Synchronization is explicit and follows the selected deployment policy.

Fig. 5: Egress pipeline

Local minimization runs before synchronization. Enrollment, access, retention, and deletion policy apply to approved telemetry after it reaches the selected data plane.

Removed on device

Authorization headers
Cookies
API-key headers
Secret query parameters

Controlled by capture policy

Request bodies
Response bodies
WebSocket frames
Explicit production allowlists

Local by default

Semantic reconstruction
Turn grouping
Prompt and response previews
Inspector data

Sample capture payload after local secret removal

{
  "session": "selected-session",
  "events": [{
    "surface": "configured-surface",
    "provider": "selected-provider",
    "request": {
      "method": "POST",
      "path": "/configured-path",
      "headers": { "content-type": "application/json" },
      // removed on device before telemetry is written
      "headers_removed": ["authorization", "api-key", "cookie"],
      "body": "{ …captured under the active profile… }"
    },
    "response": { "status": 200, "body": "{ … }" }
  }]
}

Sample capture payload after local secret removal. Body capture remains subject to the active profile.

Enrollment is required before synchronization. Retention follows the selected deployment policy.

Capture policy

Supported device capture applies local policy before telemetry is written or prepared for synchronization.

Policy-controlled synchronization

Approved telemetry moves to the configured data plane under capture, access, retention, and deletion policy.

Scoped evidence access

Cortex access controls determine who can review synchronized evidence. Source-system permissions remain part of the deployment boundary.

For source evidence, provenance, and the work model it supports, see the Semantic Model.

Configured control point

Apply policy only where Cortex participates in the path.

At a configured control point, Cortex can evaluate the policy and the context available to that deployment before a supported action proceeds. This is a boundary, not a claim of universal coverage. The Semantic Model explains the evidence and decision record behind a result.

Context in scope

Use only evidence available to the selected deployment and configured path.

Configured decision

A recommendation, approval, restriction, or block is possible only when a supported action reaches a configured Cortex control point.

Reviewable result

The action and policy applied at that point remain available for review.

The architecture review turns those mechanisms into a deployment boundary your security and procurement teams can verify.

Security & Trust

Know the boundary. Prove the control.

Before Cortex connects to an environment, review the request and telemetry boundaries, selected deployment, access and retention controls, and the current assurance package.

Deployment

Choose the data boundary that fits your environment.

Each deployment model has a different storage, processing, access, and operational boundary. Confirm the selected architecture and integration requirements during the security review.

Cortex Cloud

Managed Cortex services with data handling defined by the selected service, region, and retention configuration.

Data lives

Documented Cortex environment

Customer Data Plane

Cortex telemetry is processed and stored in the customer-controlled cloud environment defined by the deployment architecture.

Data lives

Your configured warehouse or VPC

Customer Hosted

A customer-operated deployment subject to architecture review, supported infrastructure, and documented integration requirements.

Data lives

Your supported infrastructure

Where a supported connector is configured, Cortex uses the access mode and permissions documented for that source. Do not assume in-place reads or identical behavior across connectors.

Security review

Current evidence for the review you are running.

Reports and certifications change over time. Cortex provides the current package, scope, and applicability directly to your security and procurement team.

Architecture and data-flow documentation
Identity and access-control overview
Retention and deletion controls
Subprocessor and deployment information
Current assurance reports, when applicable
Security questionnaire support

Procurement FAQ

The questions security teams ask first.

The answer depends on the selected deployment. Cortex Cloud, a customer data plane, and customer-hosted options have different infrastructure and operational boundaries. The architecture review documents the applicable storage, processing, and integration path.

Cortex access controls scope who can review synchronized evidence. Source-system permissions, identity-provider configuration, tenant isolation, service identities, and administrative access are reviewed as separate controls for the selected deployment.

Cortex can provide current architecture and data-flow documentation, identity and access information, retention and deletion controls, subprocessor information, applicable assurance reports, and security-questionnaire support. The team confirms scope and currency during the review.

Operations

Control is reversible.

Cortex is local-first and designed to unwind cleanly when a deployment changes or a pilot ends.

Fail-closed credentials

Cortex refuses a request when it cannot validate the intended upstream. Credentials do not move to a guessed destination.

Reversible configuration

Restore provider base URLs, disable the PAC, remove the local certificate, and stop the sidecar to return the machine to its prior setup.

Local inspection

Capture state and the Inspector remain available on device when synchronization is disabled, subject to local retention policy.

Review Cortex on your stack.

Bring one provider path, your deployment constraints, and the security requirements that govern it. We will trace the request, show the capture boundary, and map the current evidence package to your review.