Trust and compliance

Customer Security Pack

Name: InnerWarden
Author: InnerWarden

Security posture overview for procurement reviewers: what InnerWarden is, how it is built, what it guarantees at runtime, and how to verify it.

Customer Security Pack

For: procurement reviewers and security buyers who need a posture overview in about 10 minutes, with deep links to the evidence.

This is the single page to skim before a security review. It tells you what InnerWarden is, how it is built, what it guarantees at runtime, what it sends where, and how to verify the claims yourself. Each section ends with a pointer into a deeper page.

Product: InnerWarden, a self-hosted Linux defence agent and AI-agent guardrail. Current release: v0.16.0. License: InnerWarden Source-Available Licence across the workspace (proprietary source, provided to licensed customers to audit). The DDoS shield module is BUSL-1.1; the Execution Gate and DNS Guard arming tools are a separate paid Active Defence layer. Source: available to licensed customers under the Source-Available Licence; public signed binaries at https://github.com/InnerWarden/innerwarden-releases

A. What it is, in one paragraph

InnerWarden is a self-hosted defence agent for Linux servers with two jobs: it defends the host like an EDR you do not need a SOC team to run, and it puts a safety layer around the AI agents running on that host. It is a deterministic collection layer (eBPF, log readers, native network capture), an interpretive layer that triages incidents and can take autonomous response actions, and a CLI for install, hardening, scanning, and operator control. Triage runs on-device by default through the local Warden model (an ONNX classifier distilled from a fine-tuned security language model), or routes to an external AI provider of your choice. Everything runs on your host. The only data leaving the box is what you opt into. See Architecture.

B. Architecture at a glance

Two services and a CLI on one host. There is no vendor-controlled central control plane.

host                                  optional external (all opt-in)
+---------------------------------+   +------------------+
| sensor (eBPF + logs + network)  |   | AI provider      |
|   v                             |   | (you pick)       |
| events / incidents              |   +------------------+
|   v                             |   | Telegram / Slack |
| agent (triage, AI, skills)      |   | / Discord / hook |
|   v                             |   +------------------+
| response + dashboard            | < | mesh peers       |
|   v                             |   | (optional)       |
| audit chain (hash-chained)      |   +------------------+
+---------------------------------+

Deeper: Architecture, What It Detects.

C. What we guarantee at runtime

InnerWarden's safety story is written as a catalogue of plain-English promises, each backed by a test: Trust and Safety Invariants. The highlights:

Default-deny posture. A fresh install is observe-only and dry-run. It takes no autonomous block action until you explicitly arm it.
Circuit breaker. Autonomous blocks are rate-limited per hour, so one false positive cannot cascade into a mass-block.
Never-blind allowlist. Trusting a source requires the observe, verify, propose, confirm workflow; a typed proof-gate refuses an allowlist-driven block-bypass without a valid token. See Safe Observe and Allowlist.
No silent dismissal. Ambiguous alerts wait for your decision rather than being dropped; High and Critical incidents re-notify until acted on.
Live-verified containment. A block is checked against the live firewall, never assumed from an internal record, and re-applied if reality drifts.
Tamper-evident audit. Every action is dual-written to SQLite and a hash-chained JSONL trail you can verify independently.
Signed updates. Release binaries are Ed25519-signed; the installer and upgrade path reject unsigned or mis-signed artefacts.
Local-first. With the default config nothing leaves the host beyond release-update polls.
It will not sever the AI agent it guards. A verified, co-located managed agent is recognised and not cut off, while detection stays on.

D. Threat model summary

A full threat model (THREAT_MODEL.md) lives in the source repository and is available to licensed customers. Quick orientation:

Assets we protect: event and incident data, the audit chain, the autonomous-response capability, AI configuration secrets, the release signing key, the classifier model, and mesh trust state.
Adversaries we model: a local unprivileged attacker on the monitored host, a remote authenticated dashboard user, a malicious AI provider, a malicious mesh peer, a supply-chain attacker against the release pipeline, and a malicious classifier-release artefact.
Out of scope by design: root-level kernel compromise of the monitored host (the sensor's root of trust is the kernel), a state-actor zero-day against eBPF, and side channels in the AI provider you chose.

E. Build and supply chain

The release path is signed end to end:

Built on ephemeral GitHub Actions runners, for x86_64 and aarch64 Linux.
Each artefact is SHA-256 hashed, Ed25519-signed against the release key published in the releases repo's SECURITY.md, and attested with Sigstore (SLSA build provenance attached to the release).
The aggregate checksum file is GPG-signed.
innerwarden upgrade verifies the Ed25519 signature before swapping the binary, and aborts on a mismatch. The installer embeds the public key and verifies fresh installs the same way.
Dependency policy enforces allowed licences and advisory checks in CI; an audit of dependencies runs in CI.

Known gaps we acknowledge: a CycloneDX SBOM is not yet generated in CI, and detailed signing-key custody and rotation documentation (moving toward keyless signing) is still on the roadmap. The signing chain itself is verifiable today.

The trust-chain guarantees here are tested as part of Trust and Safety Invariants.

F. Vulnerability disclosure

We accept private reports via GitHub Private Vulnerability Reporting or email, with a published SLA: 48-hour acknowledgement, 30-day triage, 90-day fix for Critical and High. Full policy, scope, severity tiers, and safe-harbour language: Vulnerability Disclosure.

If you find an InnerWarden deployment that looks misconfigured (for example a dashboard exposed to the internet with no auth), report it to us and do not interact with it. We may know the operator.

G. Incident response

If the project itself is compromised (a signing-key leak, an account takeover, a malicious PR, a tampered classifier artefact), we follow a documented project-level runbook with containment steps, comms templates, and severity classification. Runtime incident response for an operator handling an incident on their own host is a different problem, covered in Responding to Incidents.

H. Data handling

InnerWarden runs locally and never calls home. The full data-flow table, the canonical retention schedule, and the data-subject-rights commands live in Privacy and GDPR. A quick classification:

Class	Examples	Default retention	Storage
Local-only operational	event and incident logs	30 days, configurable	host filesystem, optional Redis
Audit	dashboard auth events, executed responses	90 days, hash-chained	host SQLite plus JSONL
Configuration secrets	AI keys, chat tokens, signing key, TOTP secret	per-operator	host filesystem, restrictive permissions
Optional egress	data to an AI provider, mesh peers, alert channels	depends on your channel	not retained by InnerWarden once sent

There is no telemetry channel reporting installations back to the project. The one connection you may see to a project endpoint is the operator-configured update check.

I. Source-availability posture

InnerWarden Source-Available Licence across the workspace; full source provided to licensed customers to audit (the shield DDoS module is BUSL-1.1).
Source available to licensed customers under the Source-Available Licence; public signed binaries at github.com/InnerWarden/innerwarden-releases.
Community ATR (Agent Threat Rules) and Sigma rules are vendored, with their upstream licences.
Source and contributions are handled through the licensed-customer channel; the core repository is not open for public forks or PRs.
Anchor tests are committed and visible to licensed customers in the source repository: the same regression tests we rely on to keep the security-sensitive paths honest. See Trust and Safety Invariants.

J. Self-assessed compliance posture

This is not a certification claim. It is an honest snapshot of where we stand against common frameworks.

Framework	Self-assessed readiness	Notes
ISO/IEC 27001	Early	13 Annex A controls mapped in ISO 27001 Mapping; the full ISMS policy stack is not yet drafted.
SOC 2 Type II	Not yet pursued	The audit-chain primitives exist; formal procedures are pending.
NIST SP 800-218 (SSDF)	Partial	Strong on the secure-build and signing practices; gaps in process and review documentation.
SLSA	Partial	Build-level components in place (signed builds, provenance); full attestation-chain documentation pending.
OWASP ASVS L1	The dashboard auth model passes the core controls; a full L1 review is pending.
UK NCSC CAF	Pre-engagement; useful for self-assessment, not pursued for accreditation.
Common Criteria	Not pursued today.
EU CRA	Tracking the regulation; relevant if sold as an important entity, CE-style marking pending.

For a yes/no on a specific control, open a GitHub Discussion and we will point you at the evidence we have.

K. What this pack does NOT include yet

We deliberately do not ship placeholder versions of these; they will be added when they exist:

A CycloneDX SBOM.
A signed independent pen-test report.
A SOC 2 or ISO 27001 audit letter.
A cyber-insurance attestation.
A subprocessor list (there are no production subprocessors today; this stays N/A until a managed service exists).
A provider-by-provider AI data-handling matrix.

L. How to verify what we say

Do not take our word for any of it. The public releases and their signatures let anyone verify the supply chain, and licensed customers can audit the full source and CI logs directly.

Reproduce the release signing. Pull a release artefact and its signature; verify against the published Ed25519 fingerprint in the releases repo's SECURITY.md.
Inspect the audit chain. A live agent's chain can be verified end to end via the dashboard's Compliance tab (see ISO 27001 Mapping).
Read the source for each guarantee. Every promise in Trust and Safety Invariants points at the code path that enforces it.
Run the agent's own checks. innerwarden system doctor and innerwarden system scan report posture without sending anything externally. See CLI Reference.

M. Contact

Security reports: see Vulnerability Disclosure.
Procurement and compliance questions: open a GitHub Discussion, or email maicon.burn@gmail.com with [InnerWarden Compliance] in the subject.
General product questions: GitHub Discussions or the docs.

Trust and Safety Invariants: the runtime guarantees, each backed by a test.
ISO 27001 Mapping: the control-by-control mapping and audit-trail verification.
Privacy and GDPR: data flows, the retention schedule, and data-subject rights.
Vulnerability Disclosure: how to report an issue, with the SLA.
Architecture: how the pieces fit together.
Responding to Incidents: operator runtime incident response.