Security
Ironspire applies multiple layers of security to protect your system while agents operate autonomously. These protections run in the background and require no configuration.
Content Security Policy
Ironspire enforces a strict Content Security Policy (CSP) that controls what code can execute inside the application. The policy is defined in the main process and applied to all renderer windows.
Key restrictions
| Directive | Policy | Effect |
|---|---|---|
| script-src | Restricted to application bundles only | No inline scripts, no remote script loading |
| eval() | Blocked | eval(), new Function() and similar dynamic code execution are prohibited |
| style-src | Application styles + inline (for Tailwind) | No remote stylesheet loading |
| connect-src | Allowed for LLM API endpoints and GitHub API | Agents can make API calls; all other outbound connections are blocked |
| frame-src | Restricted | No arbitrary iframe embedding |
Violation monitoring
CSP violations are captured and logged to the developer console. If a violation occurs (e.g., an MCP server attempts to inject a remote script), it is blocked silently and the violation is recorded for debugging.
The CSP is enforced at the Electron level, not just in the renderer. Even if malicious code somehow reaches the renderer process, the CSP blocks execution of unauthorised scripts.
File conflict detection
When multiple agents work on the same project, they may attempt to modify the same files simultaneously. The File Conflict Service monitors your project directory and detects these conflicts before they cause problems.
How it works
- Filesystem watching: the service monitors the project directory for file changes
- Change attribution: each file change is associated with the agent that made it
- Overlap detection: when two or more agents modify the same file within a short window, a conflict is flagged
- Debounce: a 5-minute debounce window prevents rapid successive changes from generating duplicate conflict alerts
The service also runs a periodic sweep every 60 seconds to catch any changes that the filesystem watcher may have missed (e.g., during high I/O load).
Severity levels
Conflicts escalate in severity over time:
| Level | Trigger | Action |
|---|---|---|
| Warning | Two agents modify the same file within the detection window | Badge appears on both agent cards; toast notification shown |
| Critical | The conflict remains unresolved after the next periodic sweep | Badge colour changes to red; conflict appears in the Activity Timeline |
Visual indicators
File conflicts surface in three places:
- Agent cards: a conflict badge appears on the cards of all agents involved in the conflict. The badge shows the number of active conflicts for that agent.
- Toast notifications: a notification appears when a new conflict is detected, identifying the file and the agents involved.
- Activity Timeline: conflict events appear as system messages in the Activity feed, with the file path, agent names and severity level.
File conflict detection is informational. Ironspire does not automatically resolve conflicts or prevent agents from writing to contested files. Use the notification as a prompt to pause one agent or coordinate the work.
Resolution
Conflicts are resolved when:
- One of the involved agents stops or is reassigned to a different task
- You manually resolve the file conflict (e.g., by merging changes)
- The conflict ages out after no further overlapping modifications are detected
Once resolved, the conflict badges are removed from the agent cards and the Activity Timeline entry is updated.
IPC safety
Ironspire's inter-process communication (IPC) layer follows strict safety rules:
- No git state modification: IPC handlers never modify your repository's git state. No
git add,git init,git commitor similar commands are executed from the main process. All git operations are performed by agents through their terminal sessions, giving you full visibility. - Idempotent reads: IPC handlers that read external state (filesystem, git, Docker) are idempotent and side-effect-free. Calling the same handler multiple times produces the same result without changing anything.
- Channel validation: all IPC channels are statically defined in a shared type file. The preload bridge only exposes channels that are explicitly registered, preventing arbitrary main-process function calls from the renderer.
Credential storage
Sensitive values (API keys, Personal Access Tokens) are stored using Electron's safeStorage API:
| Platform | Backend |
|---|---|
| Windows | DPAPI (Data Protection API) |
| macOS | Keychain Services |
| Linux | libsecret (GNOME Keyring or KWallet) |
Credentials are encrypted at rest and decrypted only when needed. They are never written to plain-text configuration files, logs or state snapshots.
Agent permission model
Agents operate under a configurable permission model that controls how much autonomy they have:
| Mode | Behaviour |
|---|---|
| Plan | Agent proposes actions but cannot execute them without your approval |
| Normal | Agent executes most actions but pauses for tool approvals on sensitive operations |
| Full access | Agent executes all actions without pausing for approval |
The permission mode is set per agent in the Reconfigure modal. You can change it at any time; the new mode takes effect on the next message.
For details on how tool approvals work, see Tool Approvals.
Defence in depth
These protections complement each other:
| Layer | Protects against |
|---|---|
| CSP | Code injection, remote script execution, eval-based attacks |
| File conflict detection | Simultaneous file modifications causing data loss or merge conflicts |
| IPC safety | Unauthorised main-process access, unintended git state changes |
| Credential storage | Plaintext credential exposure on disk |
| Permission model | Agents executing sensitive operations without oversight |
| Docker sandboxing | Filesystem and network access beyond what the agent needs |
No single layer is sufficient on its own. Together, they provide reasonable protection for a desktop application managing autonomous AI agents.
Local-first architecture
Ironspire processes all data locally on your machine. Your code, agent conversations, memory entries, analytics and credentials never leave your device unless an agent explicitly makes an outbound API call (e.g., to an LLM provider or GitHub).
There is no Ironspire cloud service that receives telemetry, usage data or file contents. The only network traffic Ironspire initiates is:
- LLM API calls: sent to the provider you configure (Anthropic, OpenAI, etc.) when agents send messages
- GitHub API calls: sent when GitHub Sync is active, using your PAT
- Update checks: periodic requests to check for new Ironspire versions (can be disabled in Settings)
- Paddle: licence validation calls for subscription management
This local-first design means your intellectual property stays on your hardware. Even if you lose internet connectivity, Ironspire continues to function for all features that do not require an external API.
Reporting security issues
If you discover a security vulnerability in Ironspire, please report it privately by emailing support@ironspire.dev with the subject line "Security Report". Include a description of the vulnerability, steps to reproduce and any relevant logs or screenshots. Do not open a public GitHub issue for security reports.