Security and data
How managed controls affect requests, what capture redaction protects, and where approved telemetry is stored, retained, and accessed.
Actions
Access rules, rate limits, and hard budgets can refuse managed requests. Alert-only budgets do not refuse them.
| Outcome | Behavior | Boundary |
|---|---|---|
| Allow | Continue when no applicable blocking condition matches. | Default allow is not human approval. |
| Block | Refuse a managed request with HTTP 403, 429 or 402. | The applicable control must be configured on that path. |
| Redact | Scrub supported retained/captured text. | Does not establish upstream request redaction. |
| Steer | Replace a model on a qualified Smart Router path. | Preserve the original when a compatible replacement cannot apply. |
Smart Router restrictions govern replacement choices; access rules govern the original model's admission. Refusal records can be missing, so history is not a complete audit log. Roles and visibility do not introduce request approvals. Routing does not establish prompt rewriting; context collection leaves prompts unchanged.
Policy model
| Stage | What the evidence establishes |
|---|---|
| Observed | Available captured request, response or action. |
| Evaluated | Assessment of those facts or a rule match. |
| Decided | Requested outcome/reason at the control point. |
| Applied | Correlated refusal or outbound model change. |
| Verified | Destination evidence for that same request/action. |
Read the event's session, messages, and available tool activity. Follow retained source or file occurrences when available and check original/retained completeness. Correlate each stage for the same request or action. A finding or captured action does not prove prevention; a decision does not prove its applied action or downstream effect.
Capture redaction
Your capture policy controls supported request bodies, response bodies, and WebSocket messages. Captured data can include the provider, timestamps, permitted content, and response status.
- Removed on device. Authorization headers, cookies, API-key headers, and secret query parameters.
- Best effort on device. Supported text request and response bodies and WebSocket messages are scrubbed for recognized personal information and secret patterns. Opaque or binary bodies can be uploaded unchanged.
- Before managed storage. When managed personal-information (PII) redaction is enabled, Cortex also scrubs uploaded text before storing it. If redaction fails, Cortex rejects the upload. If redaction is disabled, uploaded body text can be stored unchanged.
On-device body scrubbing happens after the provider has processed the request and returned its response. A redacted Atlas record does not prove that the provider received a redacted request. Verify upstream redaction through a separate managed enforcement path and outbound evidence.
Deployment options
| Deployment | Where telemetry is processed and stored |
|---|---|
| Cortex Cloud | The documented Cortex environment, with service, region, and retention settings agreed for your deployment |
| Customer Data Plane | Your configured warehouse or VPC, as defined by the deployment architecture |
| Customer Hosted | Your supported infrastructure, subject to architecture review and documented integration requirements |
Access to synced data
Enrollment is required before synchronization. Cortex roles limit who can review synced evidence; source permissions also apply to workplace records. Storage, retention, and deletion follow the selected deployment policy. Recent captured exchanges and prompt and response previews remain inspectable locally while sync is disabled, under the local retention policy.
Before rollout, confirm your region and operating model. Review architecture and data flow, identity and access, retention and deletion controls, subprocessors, applicable assurance reports, and security questionnaire support.
Decision evidence and failure behavior
Check configuration, admission, applied action, and downstream effect separately. A saved rule does not prove a match; a missing denial does not establish admission either way.
Cortex refuses requests when it cannot validate the intended upstream, so credentials are not forwarded to an unverified destination. Rate limits can allow requests when usage cannot be checked. Hard-budget behavior during a spend-check outage depends on your deployment, including grace periods using last known spend. Confirm your failure behavior in Troubleshoot refusals.
Use Gateway errors and limits for response shapes, and Policy constraints for replacement/application boundaries.
Control is reversible
To disconnect, restore provider base URLs, disable browser routing, remove certificate trust, and stop Cortex Defender. Follow Offboard or replace a device or your deployment's removal procedure.