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 |
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, which is a precondition for capturing the Windows secure desktop (UAC, Ctrl+Alt+Del, lock screen). An unsigned or relocated binary cannot satisfy this check. |
| Explicit Service Privilege Whitelist | The agent service runs as LocalSystem but its required-privileges registry value is set explicitly to SeChangeNotifyPrivilege, SeAuditPrivilege, SeImpersonatePrivilege, SeTcbPrivilege, SeAssignPrimaryTokenPrivilege, SeIncreaseQuotaPrivilege, and SeDebugPrivilege. Privileges not on this list are removed from the service's process token at start — the service cannot, for example, take ownership of arbitrary files or load kernel drivers. |
| UIPI Bypass Scope | The helper manifest declares uiAccess=true, which lets it capture and inject across the User Interface Privilege Isolation boundary. This bypass is scoped to UI operations only — it does not grant the helper additional file system, registry, network, or token privileges. The helper runs at the interactive user's integrity level, not elevated. |
| 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 uses DXGI Desktop Duplication for the user's interactive desktop (hardware-accelerated, low CPU overhead) and switches to a GDI BitBlt fallback bound to the Winlogon desktop while a UAC prompt, Ctrl+Alt+Del screen, or lock screen is on display. The transition is automatic and based on a poll of the current input desktop. 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. The helper re-attaches its input-injection thread to the current input desktop before each batch, so operator clicks and keystrokes land on the secure desktop when UAC is active and on the user's desktop otherwise. The same UIPI bypass that allows secure-desktop capture also allows input injection into UAC prompts.
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)
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.
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 only. The platform does not collect personal user data, browsing history, keystrokes, file contents, or employee activity.
What Is Collected
- Health Metrics — CPU, memory, disk, and network utilization
- ETW Events — Windows kernel and user-mode trace 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. 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.
Network Requirements
The ET Ducky agent requires only outbound HTTPS (TCP 443) to etducky.com. No inbound ports need to be opened on the endpoint.
- Works behind NAT, proxies, and standard corporate firewalls
- Agent never opens inbound listeners or accepts incoming connections
- All communication is agent-initiated over HTTPS
- If your firewall requires explicit allowlisting, allow outbound TCP 443 to
etducky.com
Incident Response
Compromised Agent Token
If an agent or its bearer token is suspected to be compromised:
- Deactivate the agent from the dashboard — 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 only, no PII, 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 (executable downloads, credential-theft patterns, persistence attempts, etc.), 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
TraceEventSessionpair 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.
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.