FAQ Security and Trust

FAQ: Security and Trust

Common questions about what COI protects against, credential handling, and why COI is trustworthy.

Does COI prevent prompt injection attacks?

No, COI does not prevent prompt injection. What COI does protect against:

• ✅ Credential exposure - Your SSH keys, environment variables, and API tokens are not accessible to AI tools
• ✅ Host system access - AI tools can't access your entire filesystem, only the mounted workspace
• ✅ Lateral movement - Network isolation prevents access to local network resources (in restricted mode)
• ✅ Remote code execution blast radius - Built-in firewalld networking limits access to private networks and metadata services in restricted mode, and allowlist mode can constrain egress to approved domains/IPs, reducing (but not eliminating) data exfiltration and command-and-control risk
• ✅ Persistent damage - Ephemeral containers mean any malicious modifications are discarded
• ✅ Real-time threat detection - Security monitoring detects reverse shells, data exfiltration attempts, and malicious patterns, automatically pausing or killing the container (see Security Monitoring)

What COI doesn't protect against:

• ❌ Prompt injection - Malicious prompts can still trick the AI into generating harmful code, but even if the AI goes rogue, damage is limited to your workspace by filesystem isolation and network controls
• ❌ API key leakage via AI - If you give the AI your API key, it could be prompted to send it elsewhere
• ❌ Insecure code generation - AI-generated code might have vulnerabilities (SQL injection, XSS, etc.)

Best practices:

• Review AI-generated code before committing
• Don't mount sensitive credentials into containers
• Use network isolation (restricted/allowlist modes) to limit data exfiltration
• Enable security monitoring ([monitoring] enabled = true) for untrusted projects
• Review audit logs after sessions: cat ~/.coi/audit/<container-name>.jsonl
• Commit AI changes with git hooks disabled (see Security Best Practices)

What about API key security?

If the API key is for the AI tool itself (e.g., Anthropic API key for Claude):

• Store it in your host ~/.claude/settings.json or similar config
• COI automatically copies essential config files from the host into the container during session setup
• The AI tool uses the key to authenticate, but it's not available to arbitrary commands in the container
• Financial blast radius: For subscription models (e.g., Claude Pro/Max), worst case is exhausting your daily quota. For pay-per-token models, set spending caps on your API key to limit potential abuse

If you're giving API keys to the AI for it to use (e.g., AWS keys for the AI to deploy things):

• Don't do this unless you fully trust the project and AI's capabilities
• COI isolation prevents credential leakage to your host, but a compromised AI could still misuse those credentials
• Use temporary/scoped credentials with minimal permissions
• Prefer explicit mounting of credentials rather than storing them in the workspace

Why should I trust this?

Fair question. Here's what makes COI trustworthy:

Open Source - Full source code at github.com/mensfeld/code-on-incus (MIT license):

• Review the code yourself
• Community can audit and contribute
• No hidden behavior

Transparent architecture:

• Uses standard Linux tools (Incus, tmux, systemd)
• No custom daemons or proprietary components
• Easy to inspect running containers (incus list, incus exec)

Security by design:

• Credentials isolated by default (not mounted unless you configure it)
• Network isolation with firewalld (blocks private networks by default)
• Workspace-only mounting (AI can't access your entire filesystem)

Active development - Regular updates, responsive to issues, community-driven improvements.

Is COI built using AI coding agents?

Yes - partially. COI's development process is partially agentic, not fully automated. Human developers remain in the loop for design decisions, code review, and merging, but AI coding agents assist with implementation, refactoring, and other tasks.

One of the more fitting aspects of this workflow: COI is often built inside COI itself. Developers use COI containers to run AI coding agents while working on COI, which means the tool is continuously dogfooded during its own development. This helps catch real-world issues early and keeps the developer experience grounded in actual use.

Do I need to give COI "full access"?

COI itself doesn't need "full access" to anything. Here's what actually happens:

COI requires:

• Incus permissions (you must be in the incus-admin group)
• Access to your workspace directory (the project you're working on)
• Optional: firewalld sudo for network isolation (you can set [network] mode = "open" in config to avoid this)

What AI tools can access:

• ✅ Your workspace only - The project directory you explicitly mount
• ✅ Container filesystem - Temporary files that get deleted (ephemeral mode)
• ❌ Your SSH keys - Not accessible unless you explicitly mount ~/.ssh
• ❌ Your home directory - Not accessible
• ❌ Your environment variables - Not passed to the container unless explicitly forwarded via forward_env config
• ❌ Your local network - Blocked by default (restricted mode)

You control what gets mounted. By default, COI is locked down.

---

See Also

• Architecture and Security Model - Full explanation of COI's threat model and defense layers
• Security Monitoring - How COI detects and responds to threats in real time
• Security Best Practices - Recommended settings for safe operation
• Network Isolation - Configuring network restrictions
• FAQ - Return to the FAQ index