Arcjet privacy
Arcjet splits processing between your environment and the Arcjet cloud. The SDK analyzes what it can locally – a sandboxed WebAssembly module inspects request details, and the request body doesn’t leave your application. The Arcjet Cloud API handles the work that local analysis can’t do on its own: real-time decisions, background analysis, and the activity that you review in the Arcjet Console.
The Arcjet privacy policy sets out the legal basis for processing. This page describes what Arcjet processes, where, and for how long.
Where Arcjet processes data
Section titled “Where Arcjet processes data”The following table summarizes where each kind of data is processed:
| Data | Where it’s processed |
|---|---|
| Request body | Your environment |
| Local policy inputs | Your environment |
| Request IP address, headers, custom characteristics, and email addresses | Arcjet cloud |
| Text that you pass to prompt injection detection or content moderation | Arcjet cloud |
| Decision metadata and server policy inputs | Arcjet cloud |
| Coding agent and other agent activity | Arcjet cloud |
Arcjet uses the data that it processes in the cloud for the following purposes:
- Make real-time decisions.
- Run background analysis and reporting.
- Show request and agent activity in the Console.
Request protection
Section titled “Request protection”When you call protect(), the SDK sends the following request data to Arcjet:
- The IP address.
- The method, host, path, and query string.
- The headers.
- Any custom characteristics that you use for fingerprints.
- The email address, if you use email validation.
- The text that you pass for prompt injection detection, if you use it.
Everything else, including the request body, stays in your environment. For example, sensitive information detection on HTTP request bodies runs locally, so the body isn’t sent to Arcjet. The SDK reports the type and position of each finding, but not the matched text.
Guards and agents
Section titled “Guards and agents”When you call guard(), use a coding agent, or submit other agent
activity, Arcjet receives the values that it needs to evaluate your policies and
show the activity in the Console. These values can include the following:
- Decision metadata, such as the conclusion, the rules that fired, timings, and correlation identifiers.
- An actor identifier, when your application asserts one.
- Server policy inputs that you map for a Guard policy – for example a recipient address, a command, or the paths and domains in a tool call.
- The text that you pass to a prompt injection or content moderation rule.
- Tool call details, prompts, and related session metadata from coding agents and other agent submissions.
Values that you mark as local policy inputs stay in your environment. Only their declared kind and evaluation result leave the SDK.
Data retention
Section titled “Data retention”Arcjet retains decision and activity records so that you can investigate traffic and agent sessions in the Console, API, CLI, and MCP server. Depending on the product, a record can include the following:
- Request and Guard decision outcomes, and the rules that contributed to them.
- Request metadata processed in the cloud, such as the IP address and headers.
- Server policy inputs and agent session details that were sent for a decision.
What Arcjet stores by default
Section titled “What Arcjet stores by default”Arcjet doesn’t store everything that it processes. By default, it handles the text that you send for detection as follows:
- Prompt injection text is stored with the decision, so that you can
investigate a detection. This covers the text that you pass to
protect()and to a Guard prompt injection rule, and the server policy inputs that a prompt injection detector reads. - Content moderation text isn’t stored. Arcjet keeps the verdict and the billing count, but not the text.
- Server policy inputs are stored, except values that the server-side sensitive information detector flags. Arcjet removes a flagged value and keeps only the entity types and positions.
- Sensitive information that the SDK detects is recorded as entity types and positions only. The matched text stays in your environment.
- Captures and agent activity are stored. This includes SDK captures, coding agent hook events, OpenTelemetry exports, and Claude Compliance imports.
Arcjet redacts the values of authentication headers, such as Authorization,
before it stores a request.
To stop Arcjet from storing prompt injection text for your organization, contact support@arcjet.com. To stop Arcjet from storing customer content altogether, use zero data retention.
How long Arcjet stores data
Section titled “How long Arcjet stores data”How long Arcjet stores a record depends on its type:
| Record | Storage period |
|---|---|
Request decisions from protect(), including prompt injection text | 30 days |
| Request headers and query parameters | 3 days |
| Guard decisions, including server policy inputs and prompt injection text | 90 days |
| Captures and agent activity, including coding agent hooks, OpenTelemetry, and Claude Compliance | 90 days |
Arcjet also keeps backups for disaster recovery, and a backup can retain data for longer than the storage period.
Your plan’s log retention sets how far back you can view records in the Console, API, CLI, and MCP server, up to the storage period. For example, the Individual plan shows the last hour and the Startup plan shows the last 24 hours. Enterprise plans can include custom retention. For each plan’s window, see Arcjet pricing. Arcjet keeps aggregated data for longer, so that you can review traffic patterns over time.
Zero data retention
Section titled “Zero data retention”For organizations that can’t allow a vendor to store customer content, Arcjet offers zero data retention (ZDR). To find out whether your organization is eligible, contact support@arcjet.com.
With ZDR, Arcjet evaluates requests and actions as usual, so your protections work the same way. The difference is what Arcjet keeps after it responds:
- Kept: decision structure. The allow or deny conclusion, the rules that fired, timings, structural metadata such as tool names and kinds, and the shape of each policy input.
- Not kept: customer content. Prompts, tool arguments, server policy input values, and other metadata that carries a value. A tool name that Arcjet records as decision metadata is kept, but the same text sent as a server policy input value isn’t.
- Unchanged: request metadata. Records from
protect()still include the request metadata processed in the cloud – the IP address, headers, custom characteristics, and email addresses used for validation.
Log exports that Arcjet sends for you contain the same records, without the customer content.
Agent session data
Section titled “Agent session data”Agent session analysis needs recent session context to work. When it’s enabled, Arcjet temporarily retains session data – such as prompts, tool call details, and analysis findings – while the session is active and for up to 24 hours after. That window lets you resume a session and lets administrators review a locked session. Arcjet then deletes the data automatically.
Geographic processing
Section titled “Geographic processing”Arcjet runs its API in multiple regions, across several platforms, to keep response times low. Arcjet aims to process each request in the same region as your application, but redundancy and failover can route a request to another region.
If you need processing to stay in a specific region, regional processing controls are part of the Enterprise plan. For more information, see Arcjet pricing.