Security overview

Report a vulnerability

If you find a security problem in the AIDR software, this website or the hosted dashboard, please tell us privately and give us a chance to fix it before you share it more widely.

• Where: the security contact. Machine-readable details are in security.txt.
• Include: what you found, steps to reproduce, affected versions, and the impact you expect.
• Please do not: access other people's data, degrade the service, or publish details before we have responded.
• Scope: the AIDR source and connectors, threat rules, distributed artifacts, this website and the hosted dashboard.

Data flow

Detection runs where the agent runs. Data leaves the machine only through the optional legs below, each of which is off or limited by default.

Full detail, including retention and redaction modes, is in the privacy draft.

How the product is designed

• Detection rules are data. Rules are YAML files, not hard-coded patterns, so they can be reviewed, updated or revoked without a code change.
• Approvals are not agent-callable. When a call is blocked pending approval, no tool is exposed to the agent to approve it. Approval is a human action outside the session, so a prompt-injected agent cannot approve its own block.
• Credential scrub at the boundary. Bearer credentials, API keys, tokens and secret URL parameters are removed before events leave the machine.
• Device authorization. Enrollment uses short-lived, single-use codes approved in the browser by a signed-in user.
• Signed policy and intel. Policy versions and offline intel packs can be signed. When a required managed policy is invalid or unavailable beyond a fixed grace period, the connector blocks instead of dropping to weaker local rules.

Failure behaviour

Failure handling differs by layer. A single detection signal that errors is skipped and logged, and the call is still evaluated on the remaining signals. The connector entry points return a block on an internal error instead of silently allowing the call. Host-side behaviour when a hook is disabled, crashes or times out can still let a call through, which is why each connector lists it as a limit.

How this website and dashboard are protected

• Sign-in and sessions are handled by Clerk; dashboard and control-plane routes require an authenticated session.
• Security headers are set on every response: a content security policy that blocks framing and plugins, HTTP Strict Transport Security in production, no MIME sniffing, a strict referrer policy and a restrictive permissions policy.
• Billing webhooks are verified by signature; internal scheduled jobs require a bearer secret.
• The contact form validates input, uses a honeypot and rate limits, and does not log submitted details.
• Optional browser diagnostics are off unless a visitor allows them, and session replay is not used.

Known gap: the content security policy still permits inline scripts that the framework and Clerk require. A nonce-based policy is planned, not done.

Known limits of the product

AIDR cannot see an action that never passes through the host's hook. A host that has its hook disabled, or that continues after a hook times out, can let a call through. Output inspection runs after a tool has run and cannot undo it. Per-connector limits are listed on the install page, and real-host acceptance is not complete.

Subprocessors

Third parties that can process data for the hosted application. Regions are not yet confirmed. We will give customers notice of changes once a notice process is agreed.