ii-agent-harness is currently in beta. Only the latest 0.1.x release line receives fixes. We do not backport to earlier pre-releases.

Please report issues privately. Do not open a public GitHub issue for vulnerabilities.

Email: security@intelligentiterations.com

Include:

• A description of the issue and the impact you observed
• Steps to reproduce, ideally a minimal proof of concept
• Affected version or commit hash
• Any suggested mitigation

We aim to acknowledge reports within 3 business days and to provide an initial assessment within 10 business days. Coordinated disclosure timelines are agreed with the reporter on a case-by-case basis.

In scope:

• The Slack-to-tmux dispatch path
• Sandbox profile enforcement and repo allowlist bypasses
• Audit log integrity
• Authentication and admin escalation paths
• Unintended leakage of agent output into Slack

Out of scope:

• Issues in upstream dependencies — please report to the relevant upstream
• Self-inflicted misconfiguration (e.g. running with sandbox disabled, granting admin to untrusted Slack users)
• Issues that require pre-existing host compromise
• Vulnerabilities in tmux, Node.js, or operating-system components

A detailed threat model and the required controls are documented in docs/SECURITY_MODEL.md. That document is currently a draft and is pending human review; treat it as such.

Operators running ii-agent-harness are responsible for:

• Restricting HERO_ALLOWED_REPO_ROOTS to the repos the agent should be able to touch
• Keeping HERO_ADMIN_USER_IDS minimal
• Rotating Slack credentials when staff change
• Monitoring the audit DB for unexpected dispatches
• Running with the most restrictive sandbox profile that still allows the required workflow

• Run as a dedicated, non-privileged user account
• Keep .env out of version control (it is gitignored)
• Treat the audit DB as append-only; do not expose write access
• Review session logs before sharing them externally