We take the security of Amika seriously. Amika runs AI coding agents in sandboxes and handles agent credentials on your behalf, so we appreciate the work of security researchers who help us keep it trustworthy.

Please do not report security vulnerabilities through public GitHub issues, pull requests, or discussions.

Email security@amika.dev instead. If you would like to encrypt your report, say so in your first message and we will arrange a channel.

Please include as much of the following as you can:

• The type of issue (for example: sandbox escape, credential disclosure, privilege escalation, command injection, path traversal)
• The affected component and version (amika, amikalog, @amika/sandbox, our hosted cloud services, etc.), plus the commit SHA if you built from source
• Full paths of the source files involved
• Step-by-step instructions to reproduce the issue, including any configuration required
• Proof-of-concept or exploit code, if you have it
• The impact of the issue and how an attacker might exploit it

Reports that include a reproducible proof of concept are easier for us to triage and fix quickly.

These are the timelines we aim for, so you know roughly when to expect to hear from us:

• Acknowledgement that we received your report, typically within 3 business days.
• An initial assessment of whether we consider it a vulnerability and how severe we think it is, typically within 10 business days.
• Updates on our progress roughly every 10 business days until the issue is resolved.
• Credit in the release notes and advisory when a fix ships, unless you prefer to remain anonymous.

These are targets that describe how we intend to work, not a service level agreement or a contractual commitment, and nothing here creates one. We are a small team and occasionally something will slip. If you have not heard from us and think you should have, please follow up on the same thread.

We ask that you give us a reasonable opportunity to fix an issue before disclosing it publicly. We aim to ship a fix or a documented mitigation within 90 days of the initial report, and will tell you if an issue turns out to need longer.

We do not currently run a paid bug bounty program.

Amika is pre-1.0 and moves quickly. We ship security fixes in the latest release of each component and do not backport them to older versions.

Before reporting, please confirm the issue reproduces on the latest release.

In scope:

• The amika CLI and amikalog
• The Go package go/pkg/amika and the internal packages it depends on
• The TypeScript SDK (sdk/typescript/) and @amika/sandbox (js/sandbox/)
• The sandbox image bundle in sandbox-image/
• The installers (install.sh, install-amika-hostd.sh)
• our hosted cloud services

Out of scope:

• Anything under go/labs/, which is explicitly experimental and carries no compatibility or security guarantees
• Vulnerabilities in third-party dependencies, unless Amika's use of them creates an issue that the upstream project does not already track. Report those upstream first.
• Findings that require an attacker to already have code execution as the user running amika, since that user can already control the sandboxes and credentials Amika manages
• Code you supply to an agent running inside a sandbox behaving badly inside that sandbox. Escaping the sandbox, reaching another sandbox, or reading credentials the sandbox was not granted is in scope.
• Reports generated by automated scanners with no demonstrated impact
• Missing security headers, TLS configuration preferences, or similar findings without a concrete attack scenario
• Social engineering, physical attacks, and denial of service against Amika's hosted services

We will not pursue or support legal action against researchers who make a good faith effort to comply with this policy. If you follow it, stop as soon as you have enough information to report an issue, and avoid accessing or modifying data that is not yours, we will treat your research as authorized.

Test against your own sandboxes, accounts, and credentials. Do not access, destroy, or exfiltrate data belonging to other users.

A few things worth knowing when assessing Amika's security posture:

• Rigs receive their coding-agent credentials from the Amika control plane. The amika CLI does not copy credential files from your host into a rig; the --local mode that did was removed. amika secret extract still discovers local credentials (Claude, Codex, OpenCode, Amp), but only on request, and displays them masked; it uploads nothing unless you pass --push. See go/internal/auth/.
• Ports 60899–60999 are reserved inside sandbox containers for Amika services. Both the CLI and the API reject user-specified ports in that range. See docs/sandbox-configuration.md.
• Hosted rigs run in true VMs.

For bugs that are not security-sensitive, please open a regular GitHub issue.