Security

Overview

ET Ducky is built with security as a core design principle. Every layer of the platform — from agent authentication to data storage to AI processing — is engineered to protect your organization's data and minimize your attack surface. This page covers the security controls most relevant to IT administrators and security reviewers. For a comprehensive technical deep-dive, see the Security & Compliance Whitepaper.

Agent Authentication

Every agent is issued a unique, cryptographic bearer token during registration. This token is the agent's sole credential for all API communication.

Property	Detail
Token Strength	256-bit entropy (32 random bytes), generated server-side using a cryptographically secure random number generator
Server Storage	Only the SHA-256 hash of the token is stored. The plaintext token is never retained on the server.
Agent Storage	The token is saved to the agent's local configuration file, protected by NTFS file system permissions
Issued Once	The plaintext token is returned only during initial registration. It cannot be retrieved again.
Revocation	Administrators can instantly revoke an agent's access by deactivating it from the dashboard

New agents are onboarded using registration tokens created by organization administrators. These are short-lived, usage-limited tokens used only during initial registration. 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 from the dashboard. Agents use their bearer token for all subsequent API communication — no shared secrets or organization-wide credentials.

User Authentication

Dashboard authentication is handled entirely by Clerk, a dedicated identity provider. ET Ducky does not store passwords, manage sessions, or handle MFA directly.

Multi-Factor Authentication (MFA) — Configurable via your organization's Clerk settings (TOTP, SMS, passkeys)
Single Sign-On (SSO) — SAML and OIDC enterprise SSO supported through Clerk
Session Management — Configurable session lifetime and idle timeout
Role-Based Access — Admin and Member roles managed through Clerk Organizations

Encryption

Layer	Standard	Detail
In Transit	TLS 1.2+	All agent-to-cloud, dashboard-to-API, and WebSocket connections are encrypted
At Rest	AES-256	Database encryption at rest with automated encrypted backups
Registration Tokens	AES-256-GCM	Encrypted before storage with keys managed as environment variables
Bearer Tokens	SHA-256	Only hashes stored server-side; plaintext exists only on the agent
Installer Signing	EV Code Signing	Production installers are signed with an EV certificate issued to ET Ducky LLC, verified by Windows SmartScreen and UAC
Update Verification	SHA-256 + Authenticode	The SHA-256 hash of each signed installer is anchored in the version manifest at build time and re-verified by the update API on every request. As of agent 2.4.0.3 and desktop 2.3.4, downloaded updates must also pass the hash check, Authenticode validation (`WinVerifyTrust`), and a pinned signing-certificate thumbprint check before install. Any failure rejects and deletes the installer; the running agent is unaffected (fail-closed).

Remote Desktop Helper Architecture

Remote desktop sessions are handled by a separate process, ETDucky.RdpHelper.exe, launched into the interactive user's session by the agent service. The helper exists as its own binary precisely so the security boundary around screen capture and input injection can be made narrow, auditable, and independently signed.

Signed, Located, and Privilege-Limited

Control	Detail
Authenticode Signature	The helper is signed with the same EV code-signing certificate issued to ET Ducky LLC that signs the installer. Signing is performed once per release by a server-side pipeline using SSL.com's CodeSignTool; agents verify the signature via `WinVerifyTrust` before caching the binary locally.
Secure Install Location	The signed helper is cached under `C:\Program Files\ETDucky\Agent\RdpHelper\<version>\`. Windows treats Program Files as a “secure location” for the purposes of `uiAccess=true` manifest enforcement. An unsigned or relocated binary requesting `uiAccess` cannot be launched at all: `CreateProcessAsUser` fails with `ERROR_ELEVATION_REQUIRED`, which would take the whole session down rather than degrade it.
Explicit Service Privilege Whitelist	The agent service runs as `LocalSystem`, but when its required-privileges list is configured (via `sc privs ETDuckyAgent…`) it is set explicitly to `SeChangeNotifyPrivilege`, `SeAuditPrivilege`, `SeImpersonatePrivilege`, `SeTcbPrivilege`, `SeAssignPrimaryTokenPrivilege`, `SeIncreaseQuotaPrivilege`, `SeDebugPrivilege`, and `SeShutdownPrivilege`. Setting any explicit list strips every privilege not named from the service's process token at start — the service cannot, for example, take ownership of arbitrary files or load kernel drivers. `SeShutdownPrivilege` is a persistent member of this list: it is required so the patch loop can reboot the host natively (via the Win32 `InitiateSystemShutdownEx` API) after an update that needs a restart. If an older install’s list omitted it, the agent self-heals by appending `SeShutdownPrivilege` to the existing list (effective on the next service restart) rather than reverting to the unrestricted default.
UIPI Bypass Scope	The helper manifest declares `uiAccess=true`, which lets it capture and inject across the User Interface Privilege Isolation boundary within a desktop: it can drive an elevated application's window on the user's own desktop. It grants no file system, registry, network, or token privilege, and the helper runs at the interactive user's integrity level, not elevated. It also does not extend to the Windows secure desktop, which is a separate desktop object whose access control list admits `SYSTEM` only. See Secure Desktop below.
Helper Lifecycle	The helper process is launched on remote-desktop session start and terminated on session end. There is no persistent helper process when no session is active.

Capture and Input Paths

Screen capture of the user's interactive desktop uses DXGI Desktop Duplication (hardware-accelerated, low CPU overhead). Captured frames are encoded locally (WebP today, H.264 on supported hardware) and streamed over the same agent-to-cloud WebSocket relay used for all other agent communication.

Input injection uses SendInput from the helper process, which re-attaches its injection thread to the current input desktop before each batch so clicks and keystrokes land where the operator is looking. On the user's desktop this covers elevated windows, because of the UIPI bypass above.

The Windows secure desktop is a different matter entirely, with its own opt-in and its own process. It is described next.

Secure Desktop (UAC, Ctrl+Alt+Del, lock screen)

When Windows raises a UAC prompt, the Ctrl+Alt+Del screen, or the lock screen, it switches the input desktop to one owned by Winlogon. That desktop object's access control list grants SYSTEM only. A process running as the interactive user cannot read its framebuffer, cannot inject into it, and cannot even read its name: the OpenInputDesktop call fails outright. uiAccess=true does not change this, because it lifts UIPI within a desktop rather than adding the caller to another desktop's access control list. This is why Windows ships atbroker.exe, which relaunches an accessibility tool on the secure desktop instead of letting the one on the user's desktop follow it there.

Session 0 isolation closes the other obvious route. The agent service runs as LocalSystem, but window stations are per-session objects, so the service cannot reach the interactive user's desktops at all. Being SYSTEM is necessary and not sufficient; being in the session is necessary and not sufficient.

Viewing and controlling the secure desktop therefore requires a process that is both, and ET Ducky creates one only when an administrator has explicitly enabled it. The design is as follows.

Control	Detail
Off by default, two switches	`EnableSecureAttentionSequence` permits the agent to raise the Ctrl+Alt+Del screen on request. `EnableSecureDesktopInput` permits an operator to see and control the secure desktop. Both default to off, both are per-agent configuration, and the second does nothing unless the first is also on. No part of this is enabled by installing the agent.
The injector process	With both switches on, a remote-desktop session launches one additional process: the agent's own binary, as `SYSTEM`, into the interactive session, via `CreateProcessAsUser` with a duplicated service token retargeted at that session. It is the only component that touches the secure desktop. It captures it with GDI BitBlt, injects operator input into it with `SendInput`, and reports whether one is displayed.
Lifetime	It exists for the length of the remote-desktop session and no longer. It is started when the session's channel opens and exits when that channel closes; ending the session ends the process. Nothing `SYSTEM`-level persists between sessions, and a host with no active remote-desktop session has no such process at all.
Channel ownership	The agent service creates the named pipe and the injector connects to it, never the reverse. If the injector created the name, another local process could create it first and be handed sign-in keystrokes and images of the sign-in screen. The pipe's access control list grants `SYSTEM` alone; the session-facing pipe additionally admits the interactive user, and nothing wider, not `Everyone` and not `Authenticated Users`.
Per-session token	The helper authenticates to that pipe with a token minted for its launch and handed over in a file rather than on the command line, where any local process could read it out of WMI or Task Manager. A token is minted only when the capability is actually usable, so a host with the feature off never has one on disk.
Checked per frame, latched nowhere	A secure desktop closes the instant the user picks something. Both the service and the injector re-check that one is displayed before every relayed input frame, so a stale decision cannot leave an open path to `SYSTEM`-level input on the ordinary desktop.
Nothing is logged	Input on the secure desktop is keystrokes on a sign-in screen, and the captured frames are images of it. The agent log records counts and outcomes only: how many frames were forwarded, how many refused, how many captured. No key, no code, no frame content, at any log level.

The Ctrl+Alt+Del Registry Change

Windows will not let software raise the secure attention sequence unless the machine policy SoftwareSASGeneration permits it. Enabling EnableSecureAttentionSequence therefore makes one change outside the agent's own files: the agent sets HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\SoftwareSASGeneration to 3 (services and Ease of Access applications). This is a documented Windows policy value, not a workaround, and the agent is a service, so a value that excludes services will not work.

The change is reversible and the agent reverses it. Before writing, it records the previous value, or the fact that there was none, in sas-policy-previous.txt beside the agent's configuration. Turning the switch back off restores exactly that value, or removes the policy entirely if it was absent beforehand. The log records both the change and the restoration, with the old and new values.

What the Helper Cannot Do

Read arbitrary files outside the operator's screen capture scope
Modify the registry or installed software
Persist beyond the lifetime of the remote-desktop session
Bypass any access control other than UIPI (which is a UI-layer isolation, not a security boundary)
Authenticate to any system service as the user (it does not impersonate; it injects input the user could have produced themselves)
See or touch the Windows secure desktop. That belongs to the separate SYSTEM process described above, which exists only while an administrator has enabled it and only for the length of a session
Raise the Ctrl+Alt+Del screen. The helper asks the agent service to do it, over the same authenticated pipe, and the service refuses unless the capability is enabled

Defense in Depth Against a Compromised Helper

If an attacker were to replace the helper binary in the cache directory with an unsigned or malicious copy, the agent's update path would refuse to launch it: WinVerifyTrust rejects unsigned or untrusted-publisher binaries, and Windows refuses to honor uiAccess=true on a binary that fails Authenticode validation. The fallback install-directory helper is also signature-verified at launch. The signing-server credentials (SSL.com CodeSignTool TOTP secret, credential ID) live only on the cloud API host's environment variables and are not embedded in any released binary.

Linux Agent Privilege Reduction

On Linux the agent runs as an unprivileged etducky system user. It holds no broad sudo grant; the /etc/sudoers.d/etducky-rmm drop-in allows only a narrow, enumerated set of commands (read-only diagnostics, an etducky-agent-only systemctl restart, the constrained package and repository units below, and network-isolation rules). The file lists each grant with the reasoning behind it, and any rule can be deleted to disable that capability on your hosts. General privileged operations use operator-driven elevation, where an operator authenticates in the dashboard and the resulting audit row records who authorized what.

Constrained package operations

All privileged package-manager operations — third-party app install / remove / upgrade and the agent’s own self-update — run through a single constrained path rather than a direct sudo apt / sudo dnf grant:

The package-related grant is starting one systemd template unit: sudo systemctl start --wait etducky-pm@<op>.service. There is no direct package-manager grant.
That unit invokes a fixed-argv helper, etducky-pm-op.sh, which reads the requested operation from a request file and validates it against a hard allowlist: manager ∈ {apt, dnf, zypper, snap, flatpak} × operation ∈ {install, remove, upgrade}, with the package name syntactically validated. The package name is passed as a single argv element, never through a shell.
Because the request is validated against this fixed argv mapping, the one privileged capability the agent has here — starting that unit — can never be turned into running an arbitrary command as root, even though the agent chooses the instance id.
Deleting that sudoers rule hard-disables all Linux package operations (patching, app deployment, and self-update); the host then updates out of band.
Registering a host with the ET Ducky package repository runs through a second, separate unit, etducky-subscribe.service. It takes no instance id, no request file and no arguments at all — the repository URL is compiled into the script rather than supplied by the agent, so nothing about what it does is reachable from the agent process. Deleting its rule means hosts are subscribed by hand instead.
Both are units rather than plain sudo calls for the same reason: the agent service runs with ProtectSystem=strict, and a sudo child inherits that read-only view of the filesystem. Running them as separate systemd jobs is what lets the constraint on the agent stay strict.

See the Linux Agent Guide for installation and sudoers detail.

Multi-Tenant Isolation

ET Ducky enforces a two-level isolation model with defense-in-depth at every layer:

Workspace (outer boundary) — Each customer team gets a dedicated workspace bound to a subdomain on etducky.com. Workspace membership controls who can sign in at the URL and which organizations are visible from it. Org enumeration on every dashboard page is sourced from a workspace-scoped API endpoint, so a user signed into one workspace can never see organization names from another, even if they're a member of both.
Organization (inner boundary) — Inside a workspace, each Clerk organization is its own data tenant. Agents, alerts, scripts, tickets, and integrations are scoped per-organization.
Database-Level — PostgreSQL Row-Level Security policies, evaluated by the database itself, reject any query that lacks an explicit tenant context. EF Core query filters apply the same predicate at the application layer as a second line of defense.
Agent-Level — Bearer tokens are scoped to a single agent within a single organization. A compromised token cannot access other agents or organizations.
Billing-Level — Subscription quotas, agent seats, and data retention are pooled at the workspace level; per-organization usage attribution is shown on the Billing page.
No Cross-Tenant Admin Access — There is no global admin view that spans workspaces or organizations from inside the product.

Data Collection & Privacy

ET Ducky collects system telemetry plus limited connection metadata — the source IP an agent connects from, used for security and abuse prevention. The platform does not collect end-user personal content, browsing history, keystrokes, file contents, or employee activity.

What Is Collected

Health Metrics — CPU, memory, disk, and network utilization
Kernel Events — Windows ETW kernel and user-mode trace events and Linux eBPF events (process, file I/O, registry, network, services) — configurable per-agent, disabled by default
System Identity — Hostname, OS version, agent version

What Is NOT Collected

User credentials or passwords
File contents or document data
Browser history or keystrokes
Email, chat, or personal communications
Screenshots (remote desktop frames are relayed in real time and never stored server-side)

AI Data Handling

AI-powered features (root cause analysis, Smart Reports, alert enrichment) use Anthropic's Claude API by default, or your own BYOK provider (Anthropic, OpenAI, or Azure OpenAI). Key safeguards:

User-Initiated Only — No telemetry is sent to AI providers automatically. Analysis is always triggered by a user action.
Aggregated Data Only — Only summarized telemetry (CPU trends, event patterns, error summaries) is sent. No PII, credentials, or raw file data.
No AI Training — Anthropic does not train on API data per their commercial terms of service.
Server-Side Only — AI requests originate from the cloud API, never from the agent or browser.

Strict Data Residency (Distribution Hub)

When an organization requires a distribution hub, patch and application installs are fail-closed: agents install only from hub-resident sources and refuse any direct-download or cloud-script fallback. In this strict mode a deploy that has not been seeded to the hub (or provided as a hub folder bundle) is rejected rather than silently pulled from the internet or the ET Ducky cloud, and package-manager (winget / apt / dnf) installs — which fetch from public sources — are refused. This keeps installer content within your own distribution infrastructure.

See the Distribution Servers and Patch Management docs for configuration detail.

Network Requirements

By default the ET Ducky agent requires only outbound HTTPS (TCP 443) to etducky.com, and no inbound ports need to be opened on the endpoint.

Works behind NAT, proxies, and standard corporate firewalls
By default the agent does not open inbound listeners or accept incoming connections
All routine communication is agent-initiated over HTTPS
If your firewall requires explicit allowlisting, allow outbound TCP 443 to etducky.com
The one exception: an agent an operator explicitly designates as a distribution server (hub) opens an inbound HTTPS/TLS listener (WebDAV and blob transfer, default TCP 8443) to serve installer content to other agents, authenticated via a cloud-validated mount credential or short-lived cloud-signed grant token. This role is opt-in and off by default — see the Distribution Servers documentation.

Self-Hosted (Local-First) Deployments

The Local-First tier runs the same server on your own infrastructure with cloud-only surfaces removed from the application model entirely and no vendor-side secrets on your hosts. Entitlement comes from an Ed25519-signed license that degrades gracefully (grace, then collection-only — data is never deleted) and, in releases after 1.0.13, resists clock rollback via a persisted high-water clock. Stored secrets are column-encrypted, with the key ring itself encrypted by an instance-generated certificate kept outside the database (releases after 1.0.13), so a database dump alone cannot decrypt them. Outbound egress is a short documented list, enforced by a compile-time analyzer over every outbound HTTP call site; health telemetry is opt-in and off by default. Images are cosign-signed with per-customer revocable pull credentials. Full detail: the security whitepaper and the Self-Hosted Deployment docs.

Incident Response

On high-confidence evidence that a host executed malicious activity, ET Ducky automatically network-isolates that specific host — a firewall quarantine that preserves the authenticated management channel for remediation, scoped to the implicated endpoint (never fleet-wide) and gated on the IsolateOnHighConfidence policy. Each incident raises an evidence report and a review ticket. Commands deemed dangerous are blocked before execution, so a blocked attempt is handled as an identity-level review rather than a host action.

Compromised Agent Token

If an agent or its bearer token is suspected to be compromised:

Network-isolate or deactivate the agent from the dashboard — isolation quarantines the host while keeping it manageable; deactivation immediately revokes all API access
Investigate using the agent's historical telemetry for anomalous behavior
Reinstall the agent with a fresh registration token to issue a new bearer token

Credential Rotation

All platform credentials are rotatable via their respective provider dashboards without application downtime.

Compliance

ET Ducky's security controls map to common compliance framework requirements:

Control Area	Relevant Frameworks
Access Control (per-agent tokens, RBAC, org isolation)	SOC 2 CC6.1, ISO 27001 A.9, NIST AC
Encryption (TLS in transit, AES-256 at rest)	SOC 2 CC6.7, ISO 27001 A.10, NIST SC-8/SC-28
Audit Logging (auth events, connections, alert evaluations)	SOC 2 CC7.2, ISO 27001 A.12.4, NIST AU
Data Minimization (system telemetry plus connection IP for security; no end-user content; configurable retention)	GDPR Art. 5(1)(c), SOC 2 P6.1
Secrets Management (environment variables, no hardcoded secrets)	SOC 2 CC6.1, NIST IA-5

For the full compliance matrix including vulnerability management, incident response, and third-party risk controls, see the Security & Compliance Whitepaper.

Dynamic Diagnostic ETW Sessions

ET Ducky now runs an AI-driven diagnostic ETW session when an operator opens a guided troubleshooting flow. This is a separate concern from the always-on behavioral security monitoring described below — same underlying ETW infrastructure, totally different lifecycle and purpose.

Diagnostic session vs. behavioral session

The behavioral security session runs continuously on every agent, evaluates cross-platform rules (mass file access, suspicious execution chains, reverse shells, shadow-copy deletion, and other ransomware kill-chain indicators), and fires detections that flow to the alerts pipeline. It's the security tripwire.
The diagnostic session spins up only when an investigation starts. It uses a separate TraceEventSession pair with a unique per-investigation name — never the always-on baseline session. The two share no state. A bug or misconfiguration on the diagnostic side cannot drop, mute, or modify behavioral telemetry.

Engine-enforced budget caps

The AI plans which providers to enable each round, but the agent's capture engine enforces hard limits the AI cannot bypass: at most 16 concurrent providers per session, 25,000 events/sec per session, 50,000 events/sec across all diagnostic sessions on the host, 64 MiB in-flight buffer, 5 default / 10 hard ceiling rounds per investigation, 10–120 second per-round capture windows, and 4 concurrent investigations per host. Requests that would exceed a cap are refused with a structured error; observed-rate excursions trigger automatic emergency scale-back (most-recently-enabled provider disabled). Investigations that go 15 minutes without a command from the cloud are reaped by an on-agent sweeper.

Data handling

Raw events captured during a diagnostic session never leave the host. The engine counts events into a per-(provider, event id, task, opcode) tally on the agent; only the counts-only summary is uploaded. Tear-down purges event buffers and disposes both underlying TraceEventSession objects. The conclusion travels (which providers fired, what the AI concluded, the proposed remediation); the evidence stays local. This is the same invariant the agent has always held for baseline telemetry, now explicitly extended to the AI-driven dynamic case.

See the Security & Compliance Whitepaper for the full architecture and the AI Diagnostics page for operator-facing detail.

Shell Command Security

All shell commands sent to agents via Live Sessions, Fleet Tools, or Automations are evaluated by the Command Security Engine before they are queued. Commands are checked against hard-block patterns and a risk scoring system. Scripts the AI-driven diagnostic agent proposes as remediations go through this same engine as part of the Process Automations approval flow — the AI cannot bypass command security policy any more than a human operator can.

Hard Blocks

The following patterns are always rejected regardless of context or score:

Category	Examples
Known malicious domains/IOCs	Commands referencing domains or IPs flagged in prior incidents
Executable downloads to disk	`Invoke-WebRequest -OutFile *.exe/msi/zip`, `certutil -urlcache` to executables
Remote access tool installation	ScreenConnect, AnyDesk, TeamViewer, RustDesk, ngrok, and similar by name
Hidden window execution	`Start-Process -WindowStyle Hidden`
Registry uninstall tampering	Modifying `UninstallString` or `SystemComponent` keys to hide software
Credential theft tools	mimikatz, sekurlsa, procdump targeting lsass
Encoded PowerShell	`-EncodedCommand` with Base64 payload ≥50 chars
Persistence via URL tasks	`schtasks /create` pointing to an HTTP URL
Destructive operations	`format C: /Y`, recursive deletion of `C:\Windows`

Risk Scoring

Commands that pass hard-block checks are scored 0–100 based on risk indicators including external URLs, download utilities, temp directory usage, obfuscation patterns, and lateral movement techniques. Commands scoring 60 or above are blocked. Commands scoring 1–59 are allowed but logged as elevated risk. Commands scoring 0 pass silently.

Scripts stored in the organization's script library and approved by an ET Ducky admin bypass the score threshold. System scripts are always trusted.

Rate Limiting

Each user is limited to 30 shell commands per hour per organization to prevent automated abuse.

Execution Identity

On Windows, a shell command runs as the agent service by default, which is LocalSystem. Every surface that sends one — the live session shell, the multi-agent session, Fleet Tools, and the remote desktop session's shell panel — offers a Run as logged in user option that runs it as the account signed in at the console instead. That is the less privileged of the two, and it is the right choice for anything that needs the user's profile, mapped drives, or per-user application state, none of which LocalSystem can see.

It is a different identity rather than simply a lower one, and worth choosing deliberately: a command running as the signed-in user acts with that person's access to their own files, mail profile and network shares, and anything it does is attributable to them on the systems it touches.

If nobody is signed in, the command fails and says so. It does not quietly run as LocalSystem instead. An operator can act on “nobody is signed in on this host”; a silent substitution to the more privileged identity is not something they would have any way to notice.

On Linux the option is not offered. The agent there already runs as an unprivileged service account rather than as root, and it has no mechanism to become the desktop user; commands needing elevation use sudo in the command body, subject to the operator elevation flow described elsewhere on this page.

Gateway Token Security

Gateway tokens (etd_gateway_ prefix) follow the same cryptographic model as agent bearer tokens but are provisioned differently and scoped exclusively to gateway operations.

Property	Detail
Token Strength	256-bit entropy (32 random bytes)
Prefix	`etd_gateway_` — distinct from agent tokens (`etd_agent_`) for auth middleware routing
Server Storage	SHA-256 hash only; plaintext never retained
Issued Once	Shown once at provisioning; rotate via dashboard if lost
Scope	Single gateway, single organization. Cannot be used for agent API endpoints.
Rotation	Admins can rotate the token from the token management page. Old token is immediately invalidated.

Gateway tokens cannot execute shell commands, start live sessions, or access Windows health metrics. They are scoped exclusively to the gateway WebSocket connection, lease acquisition, and OOB relay credential consumption.

Agent Deployment (push to unmanaged hosts)

From Systems → Network Discovery, an operator can push the ET Ducky agent to an unmanaged Windows or Linux host over the OOB gateway, authenticating to the target with credentials the operator supplies. This is deliberate, admin-initiated remote code execution against a host on the client LAN — it runs an installer as an administrator on the target — so it is gated, credential-minimising, and fully audited.

Prefer pull-based enrollment. The recommended way to onboard a host is an enrollment link the host runs itself: it installs an outbound-only agent with no inbound service, no open port, and no admin credentials crossing the network — nothing is added to the target's attack surface. Push (described here) is the fallback for hosts you can't run a one-liner on; it is a lateral-movement-shaped operation, so use it deliberately and with the safeguards below.

Target credential handling

The operator's target admin credentials are never stored durably and never reach the gateway inside the command itself. They pass through a one-time, encrypted relay:

Property	Detail
At rest	Encrypted (AES-GCM) in a single-use relay record; the plaintext password is never persisted, and the durable command record and audit log store a redacted payload only.
In transit	Delivered to the gateway once, over TLS, only when it consumes the relay to run the install. The password is never carried in the queued command and never written to logs.
Lifetime	One-time use; the relay expires after 15 minutes and is consumed exactly once. The gateway holds the credential only for the single install and wipes it from memory immediately afterward.
Enrollment	The freshly-installed agent enrolls with a scoped, revocable registration token — not a standing secret.

Authorization & isolation

Gated. Requires a paid out-of-band subscription and the Operator role (or higher); read-only members cannot initiate a deploy.
Tenant-isolated delivery. Deploy commands are queued per gateway and pulled by the gateway over an agent-bearer-authenticated, organization-scoped channel — a gateway only ever receives its own organization's commands, and delivery never depends on a push socket that could mis-route to a stale connection.
Audited. Every deploy is recorded (operator, target, gateway, time, outcome) with the password redacted, so who pushed what and where is always answerable.

Operator responsibilities

The install path requires WinRM (5985/5986) on Windows or SSH (22) on Linux plus a local-administrator account on the target — enabling those is an explicit operator action on the target, never something ET Ducky does silently.
On Windows the WinRM channel is always encrypted, with no target configuration: plain 5985 uses NTLM/SPNEGO message encryption (the same sealing the built-in Windows remoting tools use), and 5986 uses TLS when the target exposes an HTTPS listener. A default host (AllowUnencrypted = false) works as-is; enabling AllowUnencrypted is neither needed nor wanted (it makes WinRM refuse the encrypted channel). The one-time encrypted credential relay additionally protects the operator's password, independent of the transport.
Because this is remote code execution with administrative rights, use purpose-scoped accounts and validate against a lab host before pointing it at production. The gateway validates the credentials against the target before installing, so bad credentials fail fast rather than part-installing.

Agent Security Policy

Systems → Security. ET Ducky includes built-in behavioral detection and response. The Security tab lets you tune it with an organization-wide default plus optional per-agent overrides.

Scope

Use the Scope selector at the top of the page to choose what you are editing — Organization default (applies to every agent without its own override) or a specific agent. Editing an agent creates an override; remove the override later to fall back to the org default.

Detection rules

Enable or disable individual behavioral-detection rules for the selected scope. Disabling a rule stops it firing for that scope only. Rules cover patterns such as backup sabotage, mass file encryption, mass file access, suspicious execution chains, reverse shells, crypto miners, and other ransomware kill-chain indicators.

Response actions and tuning

Each rule carries its own response actions and its own thresholds. Click Tune beside a rule to set whether it isolates the host, whether it raises an alert, whether it opens a ticket, and any numeric thresholds it exposes — for the kill-chain rule that includes its correlation window and its sensitivity. A badge on the button counts what is set at the current scope.

Each action has three states. Inherit takes the value from the scope above and names in brackets what that currently resolves to, so an unset control still tells you what will happen. On and Off pin the decision here.

The panel also reports whether an automation is already routing that rule's detections, and links to Systems → Automations with the trigger and the rule already filled in. Detections do not flow into the metric alert-rule engine; the security_detection trigger is the supported way to route one onward to a ticket, a webhook or a chat channel.

Actions and thresholds save from inside the panel. The Save policy button applies the rule on/off toggles.

Isolation stays subject to two agent-side guards that no dashboard setting can override: a minimum-confidence floor, and a simulate-only switch that is deliberately not settable from the cloud. Arming a rule here does not bypass either.

Behavioral allowlist

Some legitimate tools trip detection rules (for example, a backup agent doing mass file access). Use Manage allowlist → to exempt a specific process from a specific rule so it no longer fires for that combination. The allowlist lives under Integrations → Security.

Provider coverage

When you connect third-party EDR/XDR providers (CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint) on the Integrations → Security tab, the Provider coverage card reports which agents each provider covers — so you can see where ET Ducky’s behavioral detection complements or fills gaps in your existing endpoint protection.