Security at ET Ducky

Current status

We want to state this clearly: ET Ducky is not yet SOC 2 audited. Our security whitepaper documents how our controls map to the SOC 2 Trust Services Criteria, ISO 27001 Annex A, NIST CSF, and GDPR Article 32 — but mapping is not certification, and we won't claim what we don't hold.

If you have a procurement requirement that depends on a SOC 2 attestation or signed BAA, contact us — we'd rather have an honest conversation about timelines than oversell what we have today.

Sub-processor certifications we inherit

Some of the controls in our environment are provided by third-party sub-processors that hold their own attestations.

• Identity & SSO: Clerk is SOC 2 Type II certified.
• Infrastructure: DigitalOcean holds SOC 2 Type II, SOC 3, ISO 27001, ISO 27017, ISO 27018, and PCI DSS attestations.
• Edge / WAF: Cloudflare holds SOC 2 Type II, ISO 27001, and PCI DSS attestations.
• Billing: Stripe is PCI DSS Level 1 certified.
• AI processing: Anthropic holds SOC 2 Type II.

Inherited controls reduce our scope but do not replace our own attestation.

Current list

The following third parties process customer data on ET Ducky's behalf as part of the cloud-hosted service. Self-hosted deployments do not transit data through any of these (except Anthropic when self-hosted customers configure Anthropic as their AI provider).

We will update this list when sub-processors change. If you require notification before sub-processor changes for contractual reasons, contact [email protected].

How data flows

Agents collect ETW (Windows) and eBPF (Linux) telemetry on customer endpoints and send sanitized summaries to the ET Ducky API over TLS. Data is stored in managed PostgreSQL on DigitalOcean, isolated per organization with row-level security. When AI analysis runs, the prompt content is limited to ranked event summaries — never raw bulk telemetry — and is sent to Anthropic, or to the customer's own provider when a BYOK key is configured. No parties beyond the sub-processors listed on this page touch customer data.

Backups & recovery

Our primary datastore is DigitalOcean Managed PostgreSQL with provider-managed automated backups. Restore procedures are exercised by the operator. We do not yet publish formal RTO/RPO targets — they are being established, and we'd rather say so than print numbers we haven't validated.

Audit log retention

Operational and audit logs are retained separately from the customer-configurable telemetry retention settings — expiring or purging telemetry does not erase the audit trail. A formal published audit-retention policy is in progress; we will document specific durations here once it is finalized.

Penetration testing & code review

Internal security reviews and AI-assisted code audits are performed continuously as part of an ongoing hardening program. Independent third-party penetration testing has not yet been commissioned. As with our certification status, we'd rather state that plainly than imply coverage we don't have.

Personnel & production access

ET Ducky is a small team, and we say so plainly. Production access is limited to named operators and secured by SSH keys and provider-level MFA. As noted in the overview, there is no global in-product admin view of customer data.

Dependency & code scanning

Dependencies are pinned and updated deliberately rather than automatically. When a known-vulnerable transitive package is identified, we override it with a patched version explicitly. We do not currently run an automated SAST/SCA pipeline, and we won't claim one until we do.

Agent credentials

Each agent authenticates with a bearer token that it receives once, when it registers. ET Ducky stores a hash of the token, not the token itself. No API returns the stored hash. The agent list in the dashboard and API returns no credential hashes, hardware fingerprints or certificate material.

Organization API tokens

Organization API tokens give read-only access to one organization's agents, alerts and fleet summary through the public API and the MCP endpoint for AI assistants. See Public API and MCP server for how to create and use one.

• Who can issue them. Organization admins and owners create and revoke tokens for the organization that is active in their session.
• Storage. A token starts with etd_api_ and is shown once, when it is created. ET Ducky stores only its SHA-256 hash.
• Scope. A token can read but cannot change anything, and it reads only the organization it was issued for.
• Revocation. A token stops working when it is revoked or when its expiry date passes. Creating and revoking a token are recorded in the audit log.
• Limits. Each token is limited to 120 requests a minute, and each client address to 600 requests a minute across the public API and the MCP endpoint. See API rate limits.
• Browser requests. The MCP endpoint refuses any request that carries a browser Origin header.
• Tool list without a token. The MCP endpoint answers initialize and tools/list without a token so MCP directories can list it. Those answers carry no organization data, and calling a tool needs a token.

Automation webhook secrets

Automation webhook URLs, headers and body templates can hold credentials. They are visible only to organization admins and owners, and no member privilege grants access to them. Other members see the URL's host and a placeholder. Configuration exports leave them out, and AI-drafted imports leave them blank. Run History records only the scheme and host of the URL a webhook action called.

AI drafts

Organization admins and owners on a paid plan can draft a configuration from another tool's files, and an automation rule from a description, with AI. A configuration draft sends the uploaded files, their names and any pasted text to the AI provider. An automation draft sends the description with the names of the organization's scripts, agent tags and alert channels and the part of each member's sign-in address before the @ (the whole address when two members share that part). The AI provider is the organization's or workspace's own AI key when one is set, otherwise ET Ducky's AI provider, which also makes the draft when the organization's own key refuses or fails it. When the organization's own key refuses a PDF file, ET Ducky instead reads the PDF's text on the server that holds the upload and sends that text with the same key; ET Ducky's provider does not take over. ET Ducky does not store the uploads or the description. The ET Ducky server that receives them keeps them in memory only until the draft is finished, and if that server stops first the draft fails and the files are gone. The finished draft holds only what passed ET Ducky's checks. It is kept for an hour so the dashboard can show it to the admin who started it, then deleted. The audit log records counts and, for automation drafts, the trigger and action types, never file names, file contents, descriptions or drafted text.

Revoking access

Rotating, deactivating or deleting an agent's token, or moving the agent to another organization, stops the old token on its next request. Removing a member from a workspace in the dashboard stops that member's access on their next request.

Remote command screening

Every command sent to an agent is screened before it reaches the endpoint. The screen checks the exact text that will run. Sending a reference to a saved script with different text does not change what is screened. Platform-provided Default Scripts pass only when the text is exactly the published script.

A security reviewer can approve one exact command from a review ticket. Two categories have no remote override, and no approval lets them run:

• Reads of credential, key and secrets files.
• Changes that weaken Microsoft Defender.

Microsoft Defender changes

A script or shell command may harden Microsoft Defender. It can add attack surface reduction rules in Enabled mode, add protected folders, remove exclusions and allowed applications, set a -Disable* setting to $false, turn on controlled folder access, network protection or PUA protection, raise the cloud protection level, and set scan and signature update schedules.

The following are refused: adding an exclusion, turning a protection off, any Defender preference that cannot be shown to harden, writing Defender registry policy, stopping a Defender service or process, changing Defender preferences through WMI, and removing Defender definitions or the Defender feature. Make those changes through Intune, Group Policy or the Microsoft Defender portal. Keep Defender Tamper Protection on; it is the control on the device itself.

Data in transit

Agents may send uploads compressed with gzip. The server refuses any other content encoding and accepts a compressed body only from an authenticated agent. It bounds the size of every agent upload before the request is processed: heartbeats are limited to 2 MiB and event uploads to 16 MiB, and a compressed body is refused once its decompressed size passes the route's limit or, beyond the first 1 MiB, 50 times its compressed size.

ET Ducky's web server compresses API responses when the client asks for it. It does not compress responses that carry a credential: agent enrollment and registration, gateway provisioning, file hub certificates and mount credentials, the agent heartbeat, the response that shows a new organization API token, and the self-hosted license secret and registry pull token when they are regenerated.

Operational metrics

The cloud API records operational metrics: counts and timings such as request durations, authentication results and ingest times. Metric labels never contain an organization id, an agent id or the values in a request path; requests are grouped by route pattern. The metrics endpoint is not published to the internet and is reachable only from the server that runs the API.

Scope

We welcome reports about vulnerabilities in:

• The etducky.com domain and all subdomains
• The ET Ducky agent (Windows Service and Linux systemd unit)
• The ET Ducky desktop application
• The cloud API and dashboard

Out of scope

• Reports against our sub-processors (please report directly to Clerk, DigitalOcean, Cloudflare, Stripe, or Anthropic per their own disclosure policies)
• Social engineering of ET Ducky staff or customers
• Physical attacks against our infrastructure or offices
• Denial-of-service testing — please don't attempt this against production
• Reports about missing security headers without a demonstrated exploit
• Reports about rate limits that don't lead to a demonstrable security impact

How to report

Email [email protected] with:

• A description of the vulnerability and where it lives
• Steps to reproduce (or a proof-of-concept)
• The impact you believe it has
• Your preferred name and contact details for follow-up

PGP encryption is available on request — ask for our public key.

What you can expect from us

• Acknowledgement within 3 business days
• Triage and initial assessment within 10 business days
• Status updates every 14 days until resolution
• Public credit in our security advisories if you'd like it (or anonymous if you prefer)
• No legal action against good-faith research that follows this policy

Safe harbor

If you make a good-faith effort to comply with this policy during your security research, we will not pursue or support legal action against you. We consider research conducted under this policy to be authorized under the Computer Fraud and Abuse Act and similar statutes, and exempt from our Terms of Service to the extent necessary to perform the research.

If something goes wrong

If we detect or are notified of a security incident that affects customer data, here is what happens:

1. Triage & containment — we identify scope and stop further exposure. The agent's network-isolation mechanism is available as a containment tool against compromised endpoints in customer environments.
2. Customer notification — if customer data is affected, we notify the affected organization's admin contacts directly. Our target is notification within 72 hours of confirmation, in line with GDPR Article 33 expectations.
3. Investigation & root cause — we publish a post-incident summary including timeline, scope, and remediation. Public-facing incidents are mirrored on status.etducky.com.
4. Remediation & follow-up — we share what we changed to prevent recurrence.

Automated account actions. When a command a person sent is blocked in a high-risk category, the platform can act on that person's account automatically. A blocked command that an AI proposed during troubleshooting or analysis is recorded against the AI feature, not the technician who started the job. It raises a review ticket only, and it never bans or removes a person.

We have not had a security incident requiring customer notification to date. We will document any future incidents here.

How to reach us

• Vulnerability reports: [email protected]
• General security questions: [email protected]
• Procurement / compliance: [email protected] (ask for our security questionnaire response or current whitepaper)
• Machine-readable: see /.well-known/security.txt (RFC 9116)

More detail

Read the security whitepaper for the full architecture, encryption, isolation, and control-mapping documentation. See Compliance for framework-by-framework documentation covering cyber insurance, HIPAA, SOC 2, GLBA and FFIEC, and public sector procurement. See the Security documentation for product-level details on behavioral monitoring, isolation actions, and operator elevation.