Security & Compliance Whitepaper

Executive Summary

ET Ducky is a cross-platform endpoint monitoring and behavioral-security platform with first-class agent support for Windows and Linux. The Windows agent uses Event Tracing for Windows (ETW); the Linux agent uses eBPF programs attached to scheduler and syscall tracepoints. Both feed identical event shapes into the same correlation pipeline and the same AI-powered root cause analysis, providing deep visibility into system health, performance, and security events. The platform is designed for SMBs and Managed Service Providers (MSPs) as an alternative to full-stack RMM solutions. Every architectural property described in this document applies to both operating systems unless explicitly noted.

This document covers the platform's security architecture, authentication model, data handling practices, infrastructure hardening, and compliance posture. It is intended to provide the technical detail required for security review and organizational approval.

Architecture Overview

ET Ducky operates as a three-tier SaaS platform consisting of a cross-platform agent (Windows and Linux), a cloud API, and a web-based management dashboard.

Data Flow

Authentication & Access Control

Agent Authentication

Agents authenticate to the cloud API using per-agent bearer tokens, a system designed to eliminate shared secrets and ensure each agent has a unique, revocable credential.

Registration Token Flow (Initial Onboarding)

New agents are onboarded using short-lived registration tokens created by organization administrators in the dashboard. These are distinct from bearer tokens:

• Registration tokens are AES-256-GCM encrypted, may have expiration dates and max-use limits, and are used only during the initial POST /api/agents/register-with-token call.
• Upon successful registration, the server issues a permanent bearer token to the agent and the registration token is consumed.
• Registration tokens can be revoked at any time via the dashboard.

User Authentication (Dashboard)

User authentication is handled entirely by Clerk, a third-party identity provider. ET Ducky does not store passwords, manage sessions, or handle MFA directly.

Multi-Tenancy & Role-Based Access

ET Ducky is a multi-tenant platform with a two-level isolation model and defense-in-depth at both the application and database layers.

Workspaces (subdomains) and organizations

• Workspace — the outer isolation boundary, materialized as a subdomain on etducky.com (e.g. acme.etducky.com). The terms “workspace” and “subdomain” refer to the same entity from the user-facing and infrastructure-facing perspectives respectively; the database column is SubdomainId and the user-facing label is “Workspace.” Workspaces are auto-provisioned at sign-up with a random readable slug (e.g. etd-x7q3p2) and can be renamed by their owner from Settings → Workspace. Renames are FK'd by SubdomainId, not slug, so every binding (org membership, agent registration, integration config) is preserved; the previous slug remains active as a grace-period alias for a configurable window so in-flight bookmarks, invite links, and agent SSE connections continue to function during the cutover. The *.etducky.com wildcard certificate is centrally managed; customers do not configure DNS or TLS for the default URL.
• Clerk Organizations — the inner isolation boundary. One workspace can host multiple Clerk organizations (typical for MSPs managing several client tenants). Agents, events, alerts, scripts, tickets, and integrations are scoped per Clerk organization within a shared workspace. The dashboard's organization picker switches the active scope; the URL stays the same.
• Custom domains — optionally, a customer can map their own domain (e.g. app.acme.com) to their workspace. Verification is via DNS TXT record; certificates are issued automatically from Let's Encrypt and renewed on a 90-day rotation.

Workspace membership cascade

To prevent inconsistencies between “the user belongs to my workspace” and “the user can actually see anything in it,” ET Ducky enforces a server-side membership cascade between the two layers:

• User joins a workspace — the WorkspaceMembershipFanoutService adds the user to every Clerk organization that already lives in the workspace. The fan-out is invoked from the workspace invite acceptance path, the Clerk webhook handler for org membership creation, and the org-binding admin endpoint, so every code path that creates a workspace membership ends in the same fan-out.
• New organization is created in the workspace — all existing workspace members are added as members of the new organization. This means an MSP onboarding a new client doesn't have to re-invite each of their own analysts to the new client org.
• User is removed from a workspace — the cascade reverses, removing them from every Clerk organization in the workspace. A user cannot retain access to organizations in a workspace they no longer belong to.

Per-organization invites at the organization's URL (rather than at the workspace URL) bypass the cascade by design: this is the path used for granting client-only access (e.g. a customer's IT contact who should see their own organization but not other clients in the MSP's workspace).

Cross-workspace enumeration safety

A user can be a member of multiple workspaces. To prevent organization names or membership lists from one workspace leaking into another's UI, every organization picker in the dashboard sources its options from a single server-side endpoint, GET /api/organizations/in-current-subdomain, which returns the organizations belonging to the workspace identified by the request's host header.

• Server is the source of truth. The dashboard does not enumerate organizations from the user's Clerk session (which holds memberships across all workspaces). All dropdown options come from the workspace-scoped endpoint.
• RLS bypass is explicit and bounded. The endpoint runs inside RootTenantContext.UseAsync for the lookup of organizations bound to the current subdomain — necessary because the Organizations RLS policy is scoped to the active organization, not the active workspace. The result set is then re-filtered against the workspace's SubdomainId in code before being returned.
• Active-org recovery. If the dashboard detects that the user's Clerk-active organization is not in the current workspace's org list (a common case after switching workspaces), it intersects the user's Clerk memberships with the workspace org list, calls Clerk.setActive() with a valid org, and reloads — rather than letting the user issue requests that would 403 against the workspace.

Database-layer isolation

• PostgreSQL Row-Level Security (RLS) — every tenant-scoped table has a policy of the form bypass_rls = 'on' OR Id = app_current_org(). Per-request GUCs (app.bypass_rls, app.current_org, app.current_subdomain) are emitted by an EF Core command interceptor before every database command. Policies are enforced by the database itself, independent of application code — a query that omits the tenant filter or runs with the wrong context returns zero rows.
• Application-layer filters — EF Core HasQueryFilter applies on the same tenant-scoped entities as a second line of defense. A query that escapes EF's filter is still rejected by the database's RLS policy.
• Bypass scopes are explicit — only background services, webhook handlers, and bootstrap auth lookups (e.g. validating an agent bearer token before tenant context is set) run inside RootTenantContext.UseAsync. These call sites are static-analyzed by an in-tree Roslyn analyzer that flags any DbSet read missing a documented bypass justification.

Subscription & quota

• User-scoped licenses (Option B) — a Clerk user holds a single License row carrying their tier and Stripe subscription metadata. Subscriptions and seats follow the user across whatever organizations they belong to.
• Org-pooled quotas at runtime — AI query quota for an organization is the sum of its members' active license quotas. This makes seat-stacking work for teams (your members' subscriptions add up) without coupling subscription ownership to a specific tenant.

What we do NOT do

• No global admin view across customers. Anthropic / ET Ducky staff have no in-product way to see one customer's data while logged in. Admin endpoints are restricted to localhost on the API server (no exposed paths) and gated by an additional shared secret.
• No SQL access path that bypasses RLS by accident. The interceptor emits bypass_rls='off' by default; explicit opt-in via RootTenantContext is required. Misconfigured PgBouncer (transaction pooling instead of session pooling) would break GUC propagation, so we run PgBouncer in session-pool mode and the connection string explicitly points at the session-mode listener.

Encryption

Data Collection Scope

ET Ducky collects system telemetry only. The platform is not designed to and does not collect personal user data, browsing history, keystrokes, file contents, or employee activity.

Data Retention

ET Ducky offers configurable per-agent data retention with automatic purging enforced by a background service.

Data purging runs as a scheduled background task that deletes telemetry older than the configured retention window. Purged data is permanently deleted from the database; no archival copies are maintained unless configured by the customer at the infrastructure level.

Data Residency

All ET Ducky infrastructure is currently hosted in DigitalOcean's US regions. Data does not leave the United States for storage or processing, with one exception: AI analysis requests are sent to Anthropic's API (see AI Integration).

Hosting & Infrastructure

Network Security

• AllowedHosts: API configured to only accept requests with Host: etducky.com header, preventing host header injection attacks.
• CORS Policy: Strictly limited to https://etducky.com. No localhost or wildcard origins permitted in production.
• Database Access: PostgreSQL accessible only via DigitalOcean's private VPC network and trusted IP sources. No public internet exposure.
• SSH Access: Hardened SSH configuration with key-only authentication and password login disabled.
• Docker Networking: API container ports bound to localhost only; external traffic routed through reverse proxy with TLS.
• Admin Endpoints: Administrative API endpoints restricted to localhost-only access (127.0.0.1/::1), not reachable from the internet.

Secrets Management

All sensitive credentials are managed via environment variables injected at runtime through Docker Compose and .env files with restricted permissions (chmod 600). No secrets are stored in application configuration files, source code, or container images. Migration to Docker Secrets (file-based injection via /run/secrets/) is planned to eliminate secrets from process environment visibility.

Agent Installation & Deployment

Windows Agent

The Windows agent is deployed as a Windows Service installable via a self-extracting installer or MSI package.

Linux Agent

The Linux agent is deployed as a systemd unit via .deb, .rpm, or universal .run packages, or via the install.sh one-liner enrollment flow.

Operator-Driven Privilege Elevation (Linux)

The Linux agent does not run with standing root authority. When an AI live session generates a privileged command (sudo apt install, sudo systemctl ..., etc.), the agent does not execute it directly. Instead, it posts an elevation request to the cloud API; the dashboard pops a modal for the responsible operator with the command summary; the operator types the host's sudo password; the cloud API forwards the password to the agent over the same authenticated SSE channel that delivers commands; and the agent runs the command via sudo -S with the password fed in over stdin. Each elevation produces an immutable audit row capturing:

• The Clerk user id of the authenticating operator
• The source IP and user agent of the dashboard request
• The command summary and the full command text
• The full lifecycle timestamps (pending, granted, executed, completed)
• Exit code and any error summary

Passwords are never stored. They cross the wire as part of the SSE grant payload encrypted in transit, are zeroed in agent memory after use, and never appear in any log. A narrowed /etc/sudoers.d/etducky-rmm drop-in grants NOPASSWD only for read-only diagnostics (smartctl, dmidecode, lshw, journalctl, dmesg) and the systemctl restart etducky-agent self-management command. Everything else routes through the operator-elevation flow.

The result is that compromise of the agent does not equal compromise of root. An attacker who pivots into the etducky service account can exfiltrate the agent's bearer token (which only authenticates to one specific organization on the cloud API) but cannot run privileged commands without convincing a real operator to type a password into the dashboard.

Agent Resource Footprint

The agent is designed for minimal system impact:

• Health-Only Mode (default): Collects only system health metrics (CPU, memory, disk, network) with negligible overhead. ETW event tracing is disabled by default and enabled on-demand from the dashboard.
• Bandwidth Optimization: A correlation engine aggregates and summarizes ETW events before transmission, achieving approximately 99.95% bandwidth reduction compared to raw event forwarding.
• Memory Optimization: On-demand ETW collection control reduces memory usage by approximately 98.9% when ETW is not actively needed.
• Local Buffering: Events are buffered in a local SQLite database (events.db) to survive network interruptions. Buffer is capped at a configurable max size (default: 10,000 events) with automatic cleanup.
• Configurable Intervals: Collection and transmission intervals are tunable (default: 60 seconds each).

Agent Communications

The agent never opens inbound ports or listens for incoming connections. All communication is initiated outbound by the agent to https://etducky.com.

TLS Certificate Pinning: The agent validates the server's TLS certificate against a set of SPKI SHA-256 pin hashes compiled into the binary, in addition to standard OS certificate chain validation. This prevents MITM attacks even if a rogue certificate authority is trusted at the OS level. A two-slot rolling pin rotation is supported: the server pushes a "next" pin via the heartbeat response so pins can be rotated without an agent update.

File transfer path policy (agent-enforced)

Bidirectional file transfers between the dashboard and the agent are constrained by a hardcoded path allow-list inside the agent itself, not negotiated server-side:

• Push (dashboard → agent): the agent always writes pushed files to C:\ProgramData\ETDucky\Agent\Downloads\<filename>. The destinationPath field in the API request is intentionally ignored on the agent side — a comment in FileTransferService.cs documents this: "server-provided destinationPath is intentionally ignored to prevent arbitrary writes." A compromised dashboard or stolen Clerk session cannot land files in arbitrary locations on the agent host.
• Pull (agent → dashboard): source paths must resolve to a location under C:\ProgramData\ETDucky\Agent\. Anything else is rejected with the literal string "Source path not allowed by agent policy." The agent treats the dashboard request as an untrusted hint and applies its own allow-list before opening any file.
• Chunk integrity: all transfers happen in 1 MB chunks. Chunks are transmitted as base64 over HTTPS, with SHA-256 file-level integrity verification once reassembly completes.

The effect is that the agent treats the dashboard as a directing authority, not a trusted commander. Even if our cloud were fully compromised, the agent cannot be coerced into reading or writing outside its own data directory.

Behavioral Security Monitoring

ET Ducky's behavioral security layer has two parts. On Windows, an always-on ETW behavioral monitor runs a dedicated kernel session and triggers automatic network isolation on high-confidence detections (described first below). On both Windows and Linux, a cross-platform rule engine subscribes to the same kernel-event stream the diagnostic pipeline uses and fires named-rule detections that surface in the dashboard with the actual triggering events attached as evidence (described second).

Windows ETW Security Monitor

The Windows agent runs a dedicated ETW kernel session (ETDucky_Security) entirely independent of the on-demand diagnostic session. The monitor observes a narrow slice of system activity, file renames, process spawning, and registry writes, and feeds it through four specialized detectors. No events are ever persisted to disk by this subsystem; data is evaluated in-memory and discarded.

A per-detection-type cooldown (default: 60 seconds) suppresses alert floods during a single attack burst. Each alert includes a human-readable evidence summary and full raw evidence in the ticket body.

Automatic Network Isolation

When a detection meets or exceeds the configured minimum confidence (default: High), the agent automatically applies network isolation by setting the Windows Firewall default outbound action to Block across every profile (Domain, Private, Public) and adding explicit Allow rules prefixed ETDucky-Isolation-. The combined effect is that all outbound traffic is denied except:

• The ET Ducky agent process — a program= allow rule on the agent executable so the agent keeps reaching the cloud regardless of cloud-side IP rotation
• The ET Ducky API endpoint (etducky.com) — a backup IP-based allow rule using addresses resolved at isolation time
• DNS resolution — UDP/TCP port 53 from the Windows DNS Client service (svchost.exe), required because hostname resolution on Windows happens in a separate process from the calling agent
• Loopback (127.0.0.0/8). IPv6 loopback is permitted implicitly by Windows Firewall's default loopback handling.
• Operator-configured vendor allowlist (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, etc.) via SecurityMonitoring.IsolationAllowedHosts

Isolation is idempotent. The agent persists its isolation state to %ProgramData%\ETDucky\isolation.state on every transition; on startup it reconciles persisted state against rules-on-disk so legitimate isolation survives reboots, accidental leftovers from a crashed prior run are cleaned up, and a stuck default-block with no rules is restored to the operator's pre-isolation outbound policy. A ticket is submitted to the organisation's connected ticketing system with the full alert details, including a note that isolation was applied.

Why profile-default-block rather than an explicit Block-Outbound rule. Windows Firewall evaluates rules in the order [authenticated bypass → block → allow → default action]. A block rule with program=Any wins against any allow rule regardless of specificity, so the seemingly natural "block everything, allow the agent" pattern can never let the agent through. Setting the profile-level default to Block and relying on Allow rules to punch through is the Microsoft-documented quarantine pattern and the only model that lets specific-program allows function correctly.

Hardening: Restricted Operations While Isolated

When an agent is in any non-normal isolation state (isolating, isolated, or unisolating), the cloud refuses admin-initiated commands that could be used to bypass the dual-party lift flow. This is the primary defense against a compromised dashboard admin account using ET Ducky's legitimate command surface to push system-level activity onto a quarantined endpoint. The agent itself also refuses the same set of events (defense-in-depth) when NetworkIsolationService.IsIsolated == true.

Blocked while isolated: shell command execution (interactive sessions and ad-hoc), script execution (single-agent and multi-agent — isolated targets skipped from a fleet run with a per-agent error), live troubleshooting sessions (single and multi-agent), live-session query submission, remote desktop sessions, file push to agent, file pull from agent, ETW collection start (collection stop remains allowed for cleanup), configuration push, remote agent restart, configuration reset to defaults, and agent uninstall.

Still allowed: heartbeats and reporting, isolation lift commands themselves (the dual-party flow), session/transfer cleanup operations, isolation-state reads by the dashboard. The agent remains visible, reachable, and recoverable; only the system-level command surfaces a compromised admin would need to undermine isolation are gated.

Isolation Lift

Isolation removal uses a dual-approval model: an authenticated request from the dashboard is necessary but not sufficient — a user physically present at the device must independently approve the request before firewall rules come down. This design ensures that a compromised dashboard account, stolen session cookie, or malicious insider with valid credentials cannot silently de-isolate a device. The on-device operator is always notified and must consent.

Two paths satisfy the dual-approval requirement:

• Local lift (HMAC-TOTP code): an org admin generates a one-time code in the dashboard and a user with physical access to the device enters it in LiftIsolationForm. The code is HMAC-TOTP-signed against a hash of the agent's bearer token, valid within a 10-minute TOTP window (the agent accepts the current window ± 1, giving up to ~20 minutes of effective validity to absorb clock skew), single-use, and verified entirely on-device. Possession of either factor alone does nothing — the dashboard can't lift without the user, and the user can't lift without a freshly-issued code.
• Remote lift (dashboard-initiated, on-device approval): an authenticated dashboard operator pushes an agent.unisolate command via the SSE channel. The agent generates a single-use nonce, spawns UnisolateApprovalForm in the active console session via session-0 cross-session launch, and waits up to 5 minutes for the user to click Approve. Only after explicit on-device approval does the firewall rule come down. If no console session exists, the form fails to launch, the user clicks Deny, or the 5-minute timer expires — the lift is denied and the host stays isolated.

Every lift event — approved, denied, or timed out — is recorded in the per-tenant audit log with the requesting dashboard user, the on-device approver (if any), timestamp, and source IP, so security teams can reconstruct any incident's full chain of authorization.

Three paths exist depending on the device state:

• Remote lift with device approval (primary path): An authenticated administrator sends an agent.unisolate command via the SSE channel. The agent spawns an approval dialog on the active interactive desktop (the logged-in user's visible screen) using WTSQueryUserToken + CreateProcessAsUser to cross the Session 0 isolation boundary. The dialog displays a security alert, a 5-minute countdown, and ET Ducky support contact details. The user must explicitly click Approve; closing the window or timeout auto-denies. Only on approval does the agent remove all ETDucky-Isolation-* firewall rules.
• No interactive session (permanent rejection): If no user is logged in when the command arrives, the agent permanently rejects the request. It reports back to the cloud via POST /api/agents/{id}/isolation/unisolate-rejected, which broadcasts an agent.unisolate.rejected SSE alert to all org dashboard connections. The only resolution is to delete the agent from the org dashboard and re-install it after physical access to the device is restored.
• Local lift code (offline endpoints): If the endpoint cannot reach etducky.com, a technician physically present at the machine can enter a one-time code generated from the dashboard. The code is an 8-character Crockford Base32 string derived as follows:

window  = unix_time() / 600                      # 10-minute TOTP-style window
key     = SHA-256(bearer_token)                  # server stores this; agent derives it at runtime
data    = "etducky-isolation-lift-v1:{window}"
hmac    = HMAC-SHA256(key=key, data=data)
code    = CrockfordBase32(hmac)[0:8]

Isolation Threat Model

The isolation feature is designed against a specific set of threats with explicit defenses, and explicitly acknowledges one residual gap that no endpoint security product can fully close. The honest disclosure here helps customers reason about what the feature can and cannot do.

The local-SYSTEM row is the residual gap that no Windows-based endpoint security tool can fully close: an attacker who has already escalated to SYSTEM owns the firewall stack and can disable any rule it wants. ET Ducky's design property is that the cloud-side state cannot be modified by a local SYSTEM attacker — isolation status in the dashboard remains accurate even if local enforcement has been bypassed. An operator reviewing the dashboard against ground truth on the host will see the discrepancy. This is consistent with the security model of every comparable product (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint, etc.) — once SYSTEM is conceded, local controls are advisory; only the cloud's record of isolation status is authoritative.

The hardening described in §Restricted Operations While Isolated additionally ensures that even a compromised dashboard admin cannot use ET Ducky's command surface (shell, scripts, sessions, remote desktop, file transfer, config push, uninstall) to drive a compromised-SYSTEM-on-host into a "both factors compromised" state without independent consent from the on-device user.

Kill Switch

The security monitor can be disabled entirely by setting SecurityMonitoring.Enabled = false in AgentConfig.json. This is a graceful kill switch that stops the ETW session without requiring an agent restart. The setting is also configurable remotely via the standard config.change SSE command.

Cross-Platform Rule Engine

In addition to the Windows-specific ETW security monitor, the agent runs a cross-platform behavioral rule engine that subscribes to the same kernel-event stream the diagnostic pipeline uses (ETW on Windows, eBPF on Linux). Rules are defined once and fire on either operating system from a single definition. Five rules ship today:

Each detection is persisted to the per-organization AgentBehavioralDetections table with the rule id, severity, the process the rule pinned the match to, and the actual triggering events as evidence (capped at 10 entries per detection). Detections push to the org's dashboard within seconds of observation via Server-Sent Events. Acknowledgement is operator-attributed and idempotent. Rules are versioned with the agent today; database-backed rule definitions with hot-update are on the near-term roadmap.

The cross-platform rule engine and the Windows ETW security monitor coexist. The ETW monitor's automatic network isolation on encryption sweeps and shadow-copy deletion remains the highest-confidence Windows-only response; the cross-platform rules surface earlier-stage indicators before automatic isolation criteria are met.

Per-Process False-Positive Suppression

Several legitimate workloads pattern-match against the behavioral rules: AI coding assistants legitimately read many files for context analysis (trips Mass File Access); backup agents do the same; some build systems use curl | sh as an install bootstrap (trips Suspicious Exec Chain). To suppress these without disabling the rule for any other process, organization admins maintain a Behavioral Detection Allowlist — a per-organization list of (process name, rule id) tuples. The list is edited on the Integrations page and exposed at /api/organizations/{clerkOrgId}/behavioral-allowlist.

Enforcement happens server-side before a detection is persisted: the cloud API loads the allowlist into a hash set keyed by (process, rule), scans incoming detections, and drops matches. Suppressed counts are logged but never stored, so an attacker cannot use the allowlist UI to mask an attack and then have the suppression itself be audit evidence. Agents fetch their organization's copy from /api/agents/me/behavioral-allowlist at startup and on configuration polls; future agent versions self-filter so the suppressed bytes never leave the host.

Exemptions are scoped per-rule. Allowing claude.exe on Mass File Access does not exempt it from Suspicious Exec Chain or any other rule. Only organization admins can edit the list; member-role users can read it (so unprivileged agent fetches and dashboard reads still work). The recommendation is to keep entries narrow — broad exemptions weaken the protection model.

Data Minimisation & Event Upload Policy

ET Ducky agents do not continuously stream raw kernel events to the cloud. By default, only the following crosses the wire:

• Aggregate health metrics (CPU, memory, disk, network, hardware health) on the heartbeat cadence (default 60 seconds).
• Inflection-bracketed evidence: when a metric anomaly fires, the agent attaches the kernel events from the surrounding window so the cloud can show "what was happening when CPU spiked" without rejoining against an event store.
• Behavioral detections: each rule firing carries its hand-picked triggering events, capped at 10 per detection, as evidence.

Raw kernel events stay on the endpoint. They are kept in a bounded local buffer that ages out under a configurable retention policy (default 60 seconds for the in-process working set, longer for the on-disk SQLite buffer if events would have shipped but the network was down).

When an operator opens a live session or issues an explicit collection command from the dashboard, a reference-counted upload gate opens for the duration of that work. While the gate is open, the full kernel-event stream from that agent ships to the cloud. When the operator closes the session or the collection command's window expires, the gate closes and the agent returns to minimised upload mode. The result is that quiet hosts transmit very little; hosts under investigation transmit the full stream the operator asked for, and only those.

An on-agent significance filter further curates what flows even while the gate is open: shared library loads, locale catalog opens, /proc reads from system daemons, and other high-volume noise are dropped or deduplicated locally. This applies on both operating systems and means that "we have eBPF/ETW running" does not translate to "we ship 10k+ events per heartbeat" the way an unfiltered firehose would.

Dynamic ETW Diagnostic Sessions

When an operator opens a guided troubleshooting session, ET Ducky now runs an AI-driven diagnostic ETW session alongside the always-on baseline. Instead of either capturing the full firehose or asking the operator to pick providers manually, the AI picks the ETW providers for each round of the investigation, observes what arrives, and decides which providers to enable next. The architecture is the substantive product differentiator: nobody else (that we're aware of) is orchestrating the ETW session layer with an AI in the loop.

Each investigation creates its own engine instance on the agent. The AI plans a round at a time: it sees the host's tier-filtered provider catalog (Tier 1 well-known plus Tier 2 recently-active, roughly 200 providers out of the 1,500–2,500 the typical Windows host registers), the currently-enabled providers, the most recent evidence snapshot (counts only — see below), and the engine's remaining budget headroom. It returns a structured plan: which providers to enable, which to disable, how long to capture before the next round. The loop applies, captures for the bounded window, snapshots, and re-plans, until the AI concludes or the round cap fires (default 5, hard ceiling 10).

Raw events from diagnostic sessions stay on the host. The engine counts events into a per-(provider, event id, task, opcode) tally; only that counts-only summary travels back to the cloud. Tear-down at the end of the investigation purges the diagnostic session's event buffers and disposes both underlying TraceEventSession objects. The data-stays-local invariant the agent has always held for baseline telemetry continues to hold for AI-driven dynamic diagnostics: the conclusion travels (which providers fired, how often, what the AI concluded); the evidence stays on the endpoint.

One narrow addition to the round-summary payload: alongside the counts-only breakdown, the agent ships any pre-classified verdicts emitted by a local rule engine that runs against the round's events before tear-down. Each verdict is a fixed-vocabulary record — severity, a known rule identifier (e.g., AadConditionalAccess, TlsUntrustedRoot, KerberosSpnUnknown), the rule's pre-authored explanation text, and a pre-authored suggestion. No raw event payloads, file paths, IP addresses, hostnames, or process identifiers are included in the verdict. The rule engine reads the events; the verdict carries only the verdict. The local in-session sample the rules consulted (bounded at 1,000 events) is discarded with the rest of the diagnostic session's raw buffers in the tear-down step, so the data-stays-local invariant is preserved: derived findings travel, raw evidence does not.

The dashboard does not expose a manual provider picker for the diagnostic session. The live-session UX stays AI-orchestrated end-to-end — the operator describes the issue in natural language, the AI handles provider selection. Operators who want to think about ETW providers directly reach for the standalone ETDucky Provider Explorer (the OSS sister tool), not the production dashboard.

Engine-Enforced Budget Caps

The AI is constrained by the engine, not trusted to behave. Per-investigation budget caps are enforced inside the dynamic capture engine itself; the AI cannot bypass them, override them, or negotiate around them. A request that would exceed a cap is refused at the API boundary with a structured error the AI must re-plan around.

When in-flight throughput exceeds a session cap (the cost catalog's estimate was wrong, or the host is busier than projected), the engine triggers emergency scale-back: the most-recently-enabled provider is automatically disabled and a structured event is raised so the AI can re-plan rather than retry blindly. Concurrent investigations per host are also capped (default 4) and any diagnostic session that goes 15 minutes without a command from the cloud is reaped by an on-agent sweeper, so a cloud orchestrator that loses track of an investigation cannot leave engines pinned indefinitely.

Remediation Script Handoff

When an investigation concludes with a known-fix pattern, the AI generates a remediation script (PowerShell on Windows, Bash on Linux) that is pushed through the existing Process Automations approval gate — the same org-admin review flow that protects recorder-generated scripts. The script row is created with ApprovalStatus = "pending_review" and an associated review ticket is filed in the org's ticketing system; no remediation runs until an organization administrator approves.

Two execution modes:

• Live guided-troubleshooting session, operator attending: the script is created with auto_run_eligible = true. After approval, the operator can run it immediately in-session through the existing Process Automations execution path (which itself enforces command security policy).
• Background / scheduled / dashboard-initiated investigation, no operator: the script is created with auto_run_eligible = false and stays as analysis-only. A human picks it up, reviews, and decides whether to run.

The product claim that ET Ducky does not take unauthorised actions on customer hosts remains intact: the approval gate, the per-command security policy, and the org-admin role-check apply equally to AI-generated remediation scripts and to scripts written by humans. AI-generated remediations are tagged with Origin = "process_automation" and a CreatedBy = "dynamic-etw:<jobId>" marker so the audit trail makes the source unambiguous.

AI Integration Security

ET Ducky uses Anthropic's Claude API for AI-powered root cause analysis, natural language querying, and smart reporting.

Third-Party Service Dependencies

Supply Chain & Dependencies

• Agent (Windows): .NET 10 self-contained build with no runtime dependencies on the target system. Package dependencies sourced from NuGet with deterministic builds.
• Agent (Linux): .NET 10 self-contained build packaged as .deb, .rpm, and universal .run. The eBPF kernel programs are compiled with Clang as part of the build pipeline; CO-RE relocations let the same binary run across distributions and kernel versions, with BTFHub providing the BTF data on older kernels that lack /sys/kernel/btf/vmlinux.
• API Server: ASP.NET Core 10 running in official Microsoft Docker base image. NuGet packages for Clerk SDK, Stripe SDK, Npgsql (PostgreSQL driver).
• Frontend: React SPA built from npm packages. Static assets served via CDN.

Logging & Auditing

• Structured Logging: All API server logs use Serilog structured logging with timestamp, request path, response code, and timing data.
• Agent Connection Tracking: SSE connection/disconnection events are logged with agent ID, organization ID, and connection IDs.
• Authentication Events: All authentication attempts (bearer token and legacy) are logged. Failed authentication returns 401 with no information leakage about valid agent IDs.
• Webhook Audit: Clerk webhook events are signature-verified and logged for audit trail.
• Alert Rule Evaluation: Alert evaluations are logged per-agent with timestamps for compliance traceability.
• Script Audit: Every script creation and modification is logged with user identity, organization, timestamp, and SHA-256 content hash for tamper detection.
• Command Security Audit: Every command execution — both ad-hoc and script-based — is risk-scored and logged to ShellCommandSecurityLogs with risk score, matched indicators, user identity, target agent, command hash, and execution decision. High-risk commands (score ≥60) generate elevated warning logs for security review.

Incident Response