Security and Reporting

Security and Reporting

Report a vulnerability privately

Please do not open a public issue for a security problem.

Email ironvise@ectospace.com with SECURITY in the subject. Include:

• the version or commit
• your configuration: ledger backend, build features, guard on or off
• the smallest steps that reproduce the problem

A sample certificate, ledger file or session export helps more than a description of one.

What to expect

Step	Target
Acknowledgement	within 5 working days
Initial assessment (is it a vulnerability, how severe)	within 10 working days
Fix or mitigation plan	agreed with you before anything is disclosed

Credit is given in the release notes unless you prefer otherwise. IronVise has one maintainer, so these are targets, not a contractual SLA. The policy itself is SECURITY.md.

Supported versions

Version	Supported
0.8.x	Yes
0.6.x and older (EctoLedger)	No. Upgrade the server and both SDKs to 0.8.x.

Security fixes ship as 0.8 patch releases. Older lines are not patched.

Scope

In scope: the ironvise binary and Observer API, the guard worker, the ledger backends, the sandbox crates, the .elc certificate format and its verifiers (CLI and browser), the Python and TypeScript SDKs, the agent hooks and the MCP proxy. Anything that makes a verifier accept evidence it should reject is especially welcome.

Out of scope:

• attacks that need write access to the ledger database itself (see the threat model)
• the insecure-by-design demo configuration (docker-compose.demo.yml)
• resource exhaustion against an endpoint you are already authenticated to call

Status and honest limits

• Prototype, not independently audited.
• IronVise only governs what runs through it. An agent or attacker that acts outside the IronVise loop is invisible to it.
• The ledger is tamper-evident, not tamper-proof. Rewrites by someone with database access are detectable, and externally provable once the tip is anchored. Detection assumes you know the session's public key independently; anchoring, not signing, defends against a re-signed ledger.
• The deterministic guard layers have documented bypasses (encodings, word splitting, semantic rephrasing). No model-based check is absolute: the semantic guard raises the cost of prompt injection, it does not eliminate it.
• On macOS, Seatbelt denies network access to sandboxed commands as a whole, with no per-domain allowances.
• Certificates and credentials are supporting evidence for your compliance process, not a legal guarantee.

What it catches and what bypasses it, layer by layer: docs/reference/threat-model.md.

The demo is insecure by design

The published container and docker-compose.demo.yml run with the semantic guard off, dev mode on and the dashboard bound to every interface. The server logs WARN INSECURE DEMO MODE while it is in that state. Do not expose it beyond your own machine. For real use, follow Configuration: Running securely.

Hardening checklist

• GUARD_REQUIRED=true with GUARD_LLM_BACKEND and GUARD_LLM_MODEL set (preferably a different model from the agent's)
• ECTO_DEV_MODE unset, ECTO_BIND_HOST=127.0.0.1, and TLS plus a reverse proxy if you must expose the dashboard
• ECTO_SANDBOX_PERMISSIVE unset, and an isolation tier configured (see Sandboxing)
• An issuer key (ironvise issuer-key init) with its public key published to your auditors
• Certificates verified with --expected-key (see Verification and Certificates)
• Webhooks signed per receiver (WEBHOOK_HMAC_SECRET, ironvise webhook-key)
• ironvise verify-ledger --strict --all in CI or on a schedule

Commercial use

The server is licensed under the Business Source License 1.1: free for non-production use, with a commercial licence required for production deployments. Running the verifier is not Production Use. Contact ironvise@ectospace.com for commercial licensing or support.