Question 1

What is Arca Sentry?

Accepted Answer

Arca Sentry is a kernel-level agent that enforces your GPU governance policy on the host itself. It attaches in the Linux host kernel via an eBPF runtime, intercepts the NVIDIA driver boundary, and scores every GPU operation against the compliance persona you choose — your operator-set threshold decides allow, alert, or block, before bytes leave the host. Every decision is sealed into a tamper-evident audit ledger on disk. Nothing leaves the machine: no telemetry, no cloud round-trip, no third party in the trust path. It is white-glove deployed by Arca.Vision engineers, not a self-serve install.

Question 2

Who is Arca Sentry for — and who is it not for?

Accepted Answer

Arca Sentry is for organizations that control the kernel of the machine doing the compute: owned hardware, or dedicated / bare-metal rented instances (CoreWeave, Lambda, and the like) where you get host-level access to attach kernel probes. It is not for anyone calling a hosted inference API (OpenAI, Anthropic, Bedrock, Vertex endpoints), or running on a serverless / shared-GPU platform where the tenant never touches the host — there is no kernel to attach to. Rule of thumb: if you can SSH to the box and load an eBPF program, Sentry fits; if your GPU access is an API call, it does not.

Question 3

How is this different from Wiz, Sysdig, or DCGM-based GPU monitoring?

Accepted Answer

Those tools operate at a different layer. Cluster-security platforms like Wiz and Sysdig watch containers, cloud configuration, and network flows — they do not see the CUDA / NVIDIA driver boundary or enforce policy on individual GPU operations. GPU-health monitors like DCGM (and profilers like CUPTI / Nsight) read hardware counters and SM-level telemetry for performance, but they do not attribute driver-boundary intent, score exfiltration, or seal a regulator-grade audit ledger. Arca Sentry is the policy-enforcement and audit layer at the ioctl / libcuda boundary: it correlates four host signals into one attributed record, applies your persona policy in real time (allow / alert / block), and proves every decision in the ledger. Run it alongside those tools, not instead of them.

Question 4

What exactly is the Ledger?

Accepted Answer

The Ledger is not a separate product — it is the tamper-evident output every Sentry produces automatically. It is an append-only, kernel-grade record on disk (/var/lib/arca-sentry/ledger.jsonl): every observation, every policy decision, and the operator-set persona threshold that produced each outcome, written where userspace cannot rewrite it. The arca-sentry report subcommand renders a signed PDF compliance certificate from it on demand, pre-mapped to FedRAMP, STIG, CMMC, and HIPAA controls. Per-host with a single Sentry; rolled into one signed fleet artifact when you add Arca Nexus. The Ledger does not decide; it proves.

Question 5

Who decides when to kill?

Accepted Answer

Your operator does. The persona is the policy: a compliance cartridge (DoD Sentinel, HIPAA Guardian, or a Custom LoRA you co-design) scores each suspect event and returns a 0–100 risk rating with a reason. Your operator-set threshold — not us, not our SLM — decides whether that score becomes allow, alert, or block. Default policy is alert-only; enforcement is opt-in, operator-armed, and sticky (the Sentry will not silently re-arm itself after a config change). Every decision is sealed in the ledger as proof of whose policy made the call.

Question 6

Is the SLM verdict the decision?

Accepted Answer

No. The verdict is advisory. The persona threshold — set by your operator — is the decision boundary. The Sentry enforces the policy you wrote against the score the SLM produced. We've kept the engine a policy-enforcement engine, not a policy-decision engine, on purpose: the operator owns the call, the ledger records both the score and the operator-set threshold that turned it into an outcome.

Question 7

What if your thresholds are wrong for our workload?

Accepted Answer

We assume they are, on day one. The recommended deployment is staged: (1) Observe — no enforcement, just read the ledger and confirm coverage; (2) Tune — alert mode, adjust persona thresholds, allowlist confirmed false-positive PIDs; (3) Shadow — the engine evaluates as if armed but takes no action, so you diff its would-be outcomes against your intent; (4) Canary — kill mode on a small subset of the fleet with the blast-radius circuit breaker armed; (5) Fleet — roll out fleet-wide. Each stage names its own acceptance criteria. The published rollout playbook is what your change-management process should paste into its runbook.

Question 8

How do you make sure the Zombie Sentry doesn't kill the wrong process?

Accepted Answer

Two kernel-side safeguards run before any SIGKILL is dispatched, and both have dedicated Prometheus counters so you can audit how often they fired. (1) PID-recycle guard: if the kernel has reassigned the PID between detection and decision, the kill is suppressed and arca_kills_suppressed_pid_recycled_total increments. (2) Kernel-diversity guard: if the launch fingerprint diversified between detection and decision (i.e. the process resumed normal work), the kill is suppressed and arca_kills_suppressed_kernel_diversity_total increments. On top of those, PID 0, PID 1, the Sentry itself, and any operator-listed protected PIDs are hard-coded as un-killable. Default policy is alert-only; SIGKILL only fires when the operator explicitly arms enforcement.

Question 9

Can you see what's actually running on the GPU?

Accepted Answer

Not at the SM level, and we don't claim to. Arca builds a host-observable model of GPU behavior by correlating four signals: (1) ioctl(2) tracepoints against /dev/nvidia*, FD-filtered; (2) libcuda uprobes on cudaLaunchKernel and cudaMalloc with kernel symbol resolution; (3) NVML device state (per-PID VRAM, attachment); and (4) /proc/<pid> process metadata. That's the request stream and the host-side intent, correlated into one continuously-attributed record. What we don't see — and explicitly don't claim to — is hardware command-queue state below the syscall layer, SM-level execution traces, L1/L2/memory-controller telemetry, or GPU-side firmware activity; those require GPU-vendor instrumentation (CUPTI, Nsight Systems, DCGM) and are orthogonal to the security, compliance, and cost use cases this product addresses. Operators who need SM-level timing should run those tools alongside the Sentry, not instead of it.

Question 10

Why is host-observable enough for the use cases you sell?

Accepted Answer

Because each use case is sufficient from host-side signals: (1) Zombie kernel detection — zombies present as a syscall pattern on the host (>1000 identical launches in a sliding window); hardware state is unnecessary. (2) Exfil interception — data crossing the host→device boundary is exactly what ioctl size and cudaMalloc capture, before it leaves the box. (3) VRAM cost auditing — NVML anchors the topology to what the driver allocated; cudaMalloc gives per-PID attribution. (4) Compliance / audit ledger — every persona decision and outcome is in the ledger with the source signals attached. We are not a kernel profiler (use Nsight / CUPTI) and not a hardware-level monitor (use DCGM). We are the policy-enforcement and audit layer that sits between the workload and the regulator.

Question 11

What is the actual measured overhead of the Nvidia hook?

Accepted Answer

Each eBPF probe is sub-microsecond and the 4 MiB ioctl ring buffer absorbs ≥1M events/s without back-pressuring. These are the figures we measure on our integration rigs and publish in the engineering DEMO doc. The hot path is small: an Aya uprobe on libcuda.so:cudaLaunchKernel and a syscalls:sys_enter_ioctl tracepoint, each writing a fixed-size POD into a per-program ring buffer. Customer-specific overhead percentages are produced during the integration window on your actual workload and shared in the integration report.

Question 12

How does Arca avoid the verifier-stall problem most eBPF tools hit on hot syscalls?

Accepted Answer

The probes are intentionally minimal: they read a small set of fixed offsets, build a POD struct, and submit one ring-buffer entry per event. That keeps the BPF programs short and easy for the in-kernel verifier to accept on every supported kernel. No dynamic codegen, no third-party verifier fork.

Question 13

Does the hook ever drop events under load?

Accepted Answer

The hot path is non-blocking: ring-buffer reservations that fail (because the consumer is behind) are skipped rather than blocking the probe. Inside user space, the heuristic gate forwards qualifying ioctl events to an async SLM worker over a bounded channel; if that channel is full, events are dropped and the arca_exfil_events_dropped_total counter increments. Zombie detection uses kernel timestamps from the original event, so it remains accurate even when the SLM channel is shedding load.

Question 14

What kernel and hardware do I need?

Accepted Answer

Linux 5.10 LTS or later with standard tracing primitives, plus an Nvidia GPU and CUDA 11.4+ for the libcuda.so uprobe. Bare metal, AWS EC2, GCP GCE, and private cloud are all first-class anywhere you run a Linux host. ARM64 support is in flight with our enterprise customers; today's deployments target x86_64.

Question 15

Is Arca.Vision patent-pending?

Accepted Answer

Yes. Arca.Vision is a proprietary, patent-pending governance layer. Filings cover the kernel-side interception pattern, the on-host SLM gate at the GPU memory boundary, and the integration tooling our engineers use to deploy and tune it. Filing references are shared under NDA.

Question 16

Are you trying to patent eBPF itself? That feels broad.

Accepted Answer

No. eBPF is upstream Linux. Aya is upstream Rust. Both prior art. Our filings are on the specific composition: GPU-driver observer plus non-invasive attach plus on-host SLM gate at the cudaMemcpyDeviceToHost boundary. The novelty is the cascade and the deployment pattern, not the underlying primitives.

Question 17

Will customers be exposed if competitors challenge the patents?

Accepted Answer

No. Customer rights to run Arca.Vision on their fleet are contractual and decoupled from patent status. Even if a filing is narrowed, your deployment continues. Indemnification terms are part of the master services agreement.

Question 18

Do you publish anything?

Accepted Answer

We publish at the level of executive summaries, deployment briefs, and customer reference architectures. Architectural deep-dives, threat models, and the engineering brief are available under NDA. We do not ship source code.

Question 19

When the gate inspects an ioctl event, does any of that content leave the host?

Accepted Answer

No. Ever. The pipeline is two stages, both on host. Stage 1 is a kernel-side heuristic on the hot path: estimate transfer size from the ioctl args, drop everything below the configured byte threshold, reservoir-sample the rest. Stage 2 hands the survivors to an on-host Phi-3 mini that scores intent against a learned exfil profile and returns a 0–100 risk rating with a reason. No HTTP. No external IPC. Air-gap deployments are first-class.

Question 20

How do you update the model without phoning home?

Accepted Answer

Signed model bundles delivered through whatever channel you already use for OS packages or AI artifacts: your internal mirror, an air-gapped USB rotation, your existing artifact registry. The Sentry verifies the bundle signature against a pinned key our engineers install during deployment, and refuses anything else. We never call out from your fleet.

Question 21

What happens to events the gate flags?

Accepted Answer

Flagged events land in your turn-key Grafana pane and in Prometheus counters on loopback (arca_exfiltration_risk_score, arca_exfil_events_dropped_total, arca_slm_eval_duration_seconds). When policy is set to kill, the Sentry signals SIGKILL to the offending PID, with PID 0, PID 1, the Sentry itself, and any operator-listed protected PIDs excluded. Arca.Vision never aggregates, mirrors, or analyzes customer events centrally.

Question 22

Can the gate itself be a side channel? Could a malicious agent learn anything from flagged-vs-clean?

Accepted Answer

It is the right question to ask. The Sentry is fundamentally an observer plus after-the-fact enforcer: the ioctl tracepoint does not return EFAULT to the caller, so there is no inline block path whose timing you can probe. When policy is kill, the offending PID is signaled out of band; when policy is alert, only a log line is written. The agent's syscall return path is unchanged in both cases, so syscall-boundary timing inference does not apply.

Question 23

Is Arca Nexus required to run Arca Sentry?

Accepted Answer

No. The Sentry stands alone on every host: single GPU host, no networking required, compliance audit via the local signed PDF. Arca Nexus is the optional enterprise fleet tier: one hub per perimeter, rolling many Sentries into one pane. Most customers run the Sentry alone for the first engagement and adopt Nexus when they need fleet-wide audit roll-up or centralized incident review.

Question 24

Does Nexus phone home?

Accepted Answer

No. Sovereign by design. License verification runs offline against a signature baked into the binary; there are no calls to a license server, ever. The fleet dashboard stays local to the Nexus server by default. Once the license file and the binary are on disk, the hub needs nothing from the outside world. Deeper verification steps live in our deployment docs.

Question 25

What's the deployment topology?

Accepted Answer

One Nexus per perimeter. Many Sentries per Nexus. Each Sentry runs a small forwarder daemon (with stricter privileges than the Sentry itself) that reads only the immutable ledger and forwards entries to Nexus over a secured, mutually authenticated stream. Nexus verifies each entry's host identity on the way in, so spoofing fails even if a Sentry host is compromised. Entries land durably, and re-deliveries are de-duplicated automatically.

Question 26

Can I run Nexus in an air-gapped environment?

Accepted Answer

Yes, that's the default supported deployment model. Nexus and every Sentry can live entirely inside your perimeter with no outbound network at all. Operators issue licenses out of band. The Nexus process runs under its own identity with stricter privileges than the Sentry, and hub state lives in a separate place from host state so there's no overlap.

Question 27

Where does the 20% number on the ROI calculator come from?

Accepted Answer

The 20% input is an example modeling rate: a round number we use so the calculator returns a defensible order-of-magnitude figure when you plug in your own fleet. It is not a published guarantee or a measured benchmark. In an actual Efficiency Auditor engagement, the auditor measures compute/stall ratio per-PID before any change and re-measures after the recommended quantization and KV-cache changes; reclaim is reported as the delta in GPU-seconds spent doing math vs. waiting on memory, multiplied by the customer's billable hourly rate. Individual fleets vary widely depending on existing scheduler hygiene, model architecture, and how aggressively quantization is allowed.

Question 28

Does the auditor support vLLM, TGI, SGLang, TensorRT-LLM?

Accepted Answer

All four. The auditor operates at the driver boundary (sys_exit_ioctl + MEMCPY timing), so it is fundamentally serving-stack agnostic. We ship logic gates that recognize the characteristic ioctl signatures of each: KV-cache pre-allocation in vLLM, paged-attention pages in SGLang, the weight-load burst in TensorRT-LLM cold start, and the continuous-batching pattern in TGI. The roofline classification stays accurate across stacks.

Question 29

Quantization risk: how do you know INT4 won't break my model?

Accepted Answer

The advisor is just that: an advisor. It surfaces VRAM headroom and a recommended dtype, and our engineers walk through the perplexity / accuracy regression you should expect from public benchmarks (e.g. Q4_K_M GGUF, AWQ INT8). The auditor never quantizes anything itself. The decision to actually swap the model lives with your ML team, with the audit findings as input. Several customers run a shadow A/B between FP16 and INT4 inference for a week before flipping the switch.

Question 30

Does the auditor work with Tensor Parallelism / sharded models?

Accepted Answer

Yes. The auditor walks the per-PID NCCL collective fingerprint and infers TP degree across multi-GPU nodes. A TP=8 deployment shows up as eight cooperating PIDs with synchronized MEMCPY patterns, not eight independent workloads. Roofline classification is computed per-shard, and the savings PDF reports per-shard reclaimable VRAM. Pipeline parallelism (PP) and expert parallelism (MoE) are also detected.

Question 31

Can I run the auditor without the Sentry deployed?

Accepted Answer

Yes. The Efficiency Auditor is a separate scoped engagement that can land independently of the Sentry in read-only mode for 1–3 weeks while our engineers attach and detach. If you already have the Sentry, the auditor reuses the existing kernel attach and adds the sys_exit_ioctl probe; the engagement is shorter and the report uses your real production traffic instead of an audit window.

Question 32

How does hot-swapping a persona work without downtime?

Accepted Answer

The eBPF probes never detach during a swap. The Persona Switchboard is a Rust-orchestrated control plane that loads cartridge weights into a separate isolated memory space, then atomically flips a pointer the inference gate reads on the next qualifying ioctl event. The two-stage gate keeps running throughout: stage 1 (the kernel-side heuristic on the hot path) is unaffected, and stage 2 (the SLM verdict) services in-flight requests against the old persona until the pointer flip lands. GPU-backed deployments return per-event verdicts in well under a second; the swap itself is a pointer flip and ring buffers stay armed. Customer-specific latency percentiles are produced during the integration window.

Question 33

Which model formats are supported?

Accepted Answer

GGUF via llama-cpp-2 is what ships today: the default, used by Phi-3 mini Q4_K_M, signed and air-gap delivered. LoRA-adapter cartridges (the DoD Sentinel format and the Custom LoRA slot) are on the cartridge roadmap; until then those personas ship as standalone GGUF bundles or are co-designed with our engineering team. ExLlamaV2 support is not in the current release; we re-evaluate per engagement when there's spare GPU headroom that warrants it.

Question 34

Can I run different personas in different namespaces or tenants?

Accepted Answer

Each Sentry instance has one active governance profile: a single active_persona at a time, with an optional SIGHUP reload when you rotate policy. There is no in-process multiplexing that maps different Kubernetes namespaces or tenants to different personas inside one daemon. For isolation you actually control, run one arca-sentry (or one distinct policy profile) per boundary: per node, per host PID namespace, or via a namespace-scoped sidecar pattern your platform team owns. Fleet-wide, use your orchestrator to set active_persona per Deployment (or per Sentry replica) the same way you would any other config. PID correctness: events and kill targets are expressed in the PID namespace the Sentry sees; when the workload lives in another PID namespace, align attach scope or instance placement with that boundary (documented caveat). The Dynamic Compliance & Shielding use case still illustrates governance patterns, but deployment is always one persona per Sentry, not magic sharing across tenants from a single process.

Question 35

How do I build a custom LoRA cartridge?

Accepted Answer

A custom cartridge is a co-design engagement with our engineering team, typically 4–6 weeks. We start from your audit logs (what does an exfil look like in your stack?), your regulator language (which paragraph does each finding map to?), and your domain vocabulary (weapons-system CUI markings, internal patent codes, regulated clinical record formats, whatever applies). We train a LoRA against an open base model, sign the bundle, and deliver it for air-gap installation. Re-training cycles for regulation drift are part of the contract.

Question 36

Is the persona itself a side-channel risk? Can a compromised workload read the SLM weights?

Accepted Answer

No. Each persona runs in a strictly isolated memory space behind the same kernel boundary as the rest of the gate. The Sentry process holds the cartridge weights; a compromised CUDA workload has no read or write path to that memory. The threat model treats the SLM as part of the observer, not the observed. That is the same posture that keeps an attacker in userspace from corrupting the eBPF programs.

Engineering
questions, plainly
answered.

The Basics

Governance & Responsibility

Scope & Limits

eBPF Overhead

Architecture & IP

Local SLM Privacy

Arca Nexus & the Fleet

Memory Efficiency & ROI

Swappable Personas

Got a deeper question?
Ask the engineer who wrote it.

Engineeringquestions, plainlyanswered.

The Basics

01What is Arca Sentry?

02Who is Arca Sentry for — and who is it not for?

03How is this different from Wiz, Sysdig, or DCGM-based GPU monitoring?

04What exactly is the Ledger?

Governance & Responsibility

01Who decides when to kill?

02Is the SLM verdict the decision?

03What if your thresholds are wrong for our workload?

04How do you make sure the Zombie Sentry doesn't kill the wrong process?

Scope & Limits

01Can you see what's actually running on the GPU?

02Why is host-observable enough for the use cases you sell?

eBPF Overhead

01What is the actual measured overhead of the Nvidia hook?

02How does Arca avoid the verifier-stall problem most eBPF tools hit on hot syscalls?

03Does the hook ever drop events under load?

04What kernel and hardware do I need?

Architecture & IP

01Is Arca.Vision patent-pending?

02Are you trying to patent eBPF itself? That feels broad.

03Will customers be exposed if competitors challenge the patents?

04Do you publish anything?

Local SLM Privacy

01When the gate inspects an ioctl event, does any of that content leave the host?

02How do you update the model without phoning home?

03What happens to events the gate flags?

04Can the gate itself be a side channel? Could a malicious agent learn anything from flagged-vs-clean?

Arca Nexus & the Fleet

01Is Arca Nexus required to run Arca Sentry?

02Does Nexus phone home?

03What's the deployment topology?

04Can I run Nexus in an air-gapped environment?

Memory Efficiency & ROI

01Where does the 20% number on the ROI calculator come from?

02Does the auditor support vLLM, TGI, SGLang, TensorRT-LLM?

03Quantization risk: how do you know INT4 won't break my model?

04Does the auditor work with Tensor Parallelism / sharded models?

05Can I run the auditor without the Sentry deployed?

Swappable Personas

01How does hot-swapping a persona work without downtime?

02Which model formats are supported?

03Can I run different personas in different namespaces or tenants?

04How do I build a custom LoRA cartridge?

05Is the persona itself a side-channel risk? Can a compromised workload read the SLM weights?

Got a deeper question?Ask the engineer who wrote it.

Engineering
questions, plainly
answered.

Got a deeper question?
Ask the engineer who wrote it.