Keeping Security Inspection Local So Data Stays in Your Environment

What does local security inspection mean?

Local security inspection means the analysis runs inside your own environment, in the same process as your application (in-process), so the data being inspected never leaves to be checked. The alternative, and the default for most security tooling, is that your content travels to a vendor's service, which analyzes it there and returns a verdict.

Most security tooling carries this trade-off quietly: to inspect your traffic, it has to receive your traffic. A cloud scanner reading request bodies or model prompts means that content, potentially personal or regulated, leaves your environment to be analyzed. For teams with data-residency obligations, or with a principle that sensitive data should not travel further than necessary, that is a problem in itself. It is frequently what stalls an AI data-loss-prevention project, because the control intended to protect regulated data requires exporting regulated data to a new third party.

Why does inspection location matter?

There are three reasons, in rough order of how often they decide a purchase.

It expands the set of systems that touch protected data. Every vendor that receives request bodies becomes an in-scope processor, requiring a data processing agreement, a sub-processor disclosure, a vendor security review, and a new entry on the record of processing activities. A DLP control that adds a processor to inspect for PII is solving one problem by creating an instance of the same problem.

It creates a residency question. If inspection happens in a region different from where your data is required to stay, the inspection itself might breach the constraint, regardless of whether the vendor retains anything. "We don't store it" doesn't resolve a requirement that data not be transferred.

It is a fast disqualifier in security review. "Where does inspection happen?" is a question that separates the options, and privacy teams ask it early. A platform that keeps content inspection in your environment lets a team add DLP and PII controls without expanding the set of systems that touch protected data. That is frequently the difference between a control that clears review and one that stalls in it.

What does Arcjet run locally?

Arcjet includes a WebAssembly module that analyzes requests inside your environment. Most of the analysis runs there, adding under a millisecond, with results reported asynchronously so that the reporting isn't in your critical path.

The part that matters most for residency is sensitive-information detection, which runs entirely locally: the raw request body is never sent to Arcjet. The built-in engine detects email addresses, phone numbers, IP addresses, and credit-card numbers in-process. The optional on-device ML model extends that to names, addresses, national identifiers, bank and routing numbers, and passport and license numbers, still with no network round trip carrying the content.

The design principle is to keep raw sensitive content local and to send the minimum necessary for everything else.

Which controls use the cloud?

Some controls need cross-request state or a specialist model, and those call Arcjet's cloud (the Cloud API).

Two points in that table need emphasis. Prompt injection detection does transmit the prompt, because the detection model is what makes the decision. If your prompts themselves are the regulated content, then that is a control to evaluate on its own terms rather than assume that "local inspection" covers it. There is also only ever one Cloud API call per decision, regardless of how many rules run, so adding rules doesn't multiply network round trips or the data sent.

How do you redact sensitive data before sending it to OpenAI or Anthropic?

The practical version of this question is usually about a model provider rather than a security vendor: how do you stop personal data reaching a third-party LLM at all?

The following sequence puts inspection before the provider call, in your own process:

1. Run sensitive-information detection on the user input as it arrives, before it is assembled into a prompt.
2. Decide per entity type what happens: block the request, redact the span, or substitute a placeholder token that you can reverse on the way back.
3. Apply the same detection to retrieved context and to direct user input. RAG pipelines are a common leak path because the pipeline trusts the retrieved document by default.
4. Inspect outputs as well. A model can reproduce personal data that arrived through context, and the response is a boundary too.
5. Apply detection to logs, traces, and embeddings. These accumulate quietly, and teams frequently retain them longer than requests.

Doing that inspection locally is what makes the sequence coherent. Sending content to a cloud scanner to determine whether it is safe to send to a cloud model hasn't reduced the number of third parties that saw it.

How does this help with GDPR and CCPA?

Local inspection doesn't make an application compliant on its own, and no tool does. What it changes is the shape of the compliance argument.

Under GDPR, a vendor that receives personal data is a processor, requiring an Article 28 agreement, sub-processor transparency, and a lawful basis for any international transfer. Inspection that runs in-process doesn't create that relationship for the content inspected, because the content is never disclosed. That removes a transfer question rather than answering it.

Data minimization is the other principle that maps directly. Article 5(1)(c) requires that processing be limited to what is necessary. A control that exports full request bodies to a third party to detect whether they contain personal data is difficult to defend as minimal when an in-process equivalent exists.

CCPA and CPRA turn on similar structure, namely whether a disclosure to a service provider has occurred and what contractual terms govern it. Fewer recipients is a simpler argument in both regimes.

This isn't legal advice, and the analysis depends on your own processing. The point is narrower: where inspection happens changes which questions you have to answer. Speed is a separate question.

How do you evaluate a vendor's local-inspection claim?

Vendors claim "runs locally" more often than it is true in the strict sense. The following questions resolve it:

• Which specific controls run locally, and which call out? A per-control answer, not a product-level one. Most platforms are mixed, and a mixed answer is fine. An evasive one isn't.
• For the controls that call out, what exactly is transmitted? Full body, a hash, metadata, or a derived signal.
• Is the local component a real in-process library, or an agent or sidecar? A sidecar in your VPC is better than a vendor's cloud, but it is a different claim, with its own deployment and update surface.
• What is retained, where, and for how long?
• Does the local path still work when the vendor is unreachable? If every decision requires a network call, the local component is an optimization, not an inspection boundary.
• Can you verify it? Network-level observation of your own application during a test is the direct check.

What do you give up with local inspection?

Local models are smaller than what a vendor can run server-side, so on-device detection generally trades some accuracy for the residency property. Detection logic ships inside your application, so updating it means deploying, rather than the vendor updating centrally. Genuinely cross-request controls, such as distributed rate limits, reputation data, and anything that needs shared state, can't be local by definition, because the state isn't local.

The reasonable position isn't that everything has to run locally, but that content inspection does, because content is the thing with residency obligations attached; counters and fingerprints generally are not.

Checklist

• Establish which of your controls receive request bodies or prompts, and list the vendors involved.
• Separate content inspection from metadata and state-dependent controls when you evaluate tooling.
• Run sensitive-information detection in-process, before the model provider call.
• Apply the same detection to retrieved context, outputs, logs, traces, and embeddings.
• Treat prompt-injection detection as a separate residency question, because it transmits the prompt.
• Verify local-inspection claims by observing network traffic from your own application.
• Record which controls degrade, and how, when the vendor is unreachable.

Where Arcjet fits

Local inspection is the property that distinguishes Arcjet from most of this category. Cloud-scanning DLP vendors and AI gateways receive your content to classify it, which is a workable design and a new processor in the path of your protected data.

Arcjet is the in-code enforcement layer, and content inspection runs in-process. Sensitive-information detection never transmits the raw body, with an optional on-device ML model extending entity coverage. Controls that genuinely need shared state, meaning distributed rate limits, the live bot database, and the prompt-injection model, do call the Cloud API, and the preceding table says exactly what each sends.

Arcjet isn't a data-discovery product, and it doesn't map where regulated data lives across your systems. It decides, at the boundary, whether this particular content is allowed to move.

Learn more: Sensitive information detection · Architecture