Wirken 0.7.4 is out today.
- Signed Releases
- Fail-Closed Installer
- Session Attestation
Here’s a bit about why those three things landed, to help everyone evaluating agent platforms, as part of a security and compliance program.
Agent platforms are moving from demos into production. Vendors are publishing deployment guides, thinking through sandboxing, walking users through how to connect a messaging channel to a model and run tools against real systems. The conversation has moved past whether agents are useful and into how to operate them responsibly.
Signed releases
Every Wirken release is signed now. The installer verifies the signature before touching the binary. The public key is embedded in the installer itself, not fetched over the network. The installer’s own hash is pinned in the README, and a CI check fails the build if the hash and the file drift apart. A user can verify the installer in one line, printed in the README.
For organizations with the usual software supply chain policy, Wirken delivers.
Fail-closed installer
This one’s for you Bob!
The installer exits non-zero and stops on any verification failure, with a distinct exit code per failure mode, each documented.
Session attestation
Every agent action, every tool call, every model request and response is written to a per-session audit log before execution. The log is a hash chain, signed by a per-agent identity after every turn. Using wirken session verify replays the log offline and confirms nothing was modified, deleted, or reordered.
Perhaps you already have counsel warning you that agent activity is evidentiary. The attestation is reproducible by a third party from the log file alone. The audit trail a compliance program expects now exists by default.
Logs also forward to Datadog, Splunk, or a webhook when configured. Retention is configurable. The audit path does not depend on trusting Wirken at read time.
Different answers to a shared problem
The question of how to run an agent across messaging channels, with tools, against real systems, has more than one reasonable answer. Wirken was for me a quick and light response when some CISOs asked me to helicopter in and make their environments more agent-safe.
Sandbox wrappers around an existing agent framework are one path, but not for me. Per-channel process isolation with compile-time channel separation is more trustworthy. Both respond to the same underlying concern: an agent with tool access is a trust-sensitive piece of infrastructure, and the defaults need to reflect that.
Wirken took the latter path and that’s how we came to a signed release chain, fail-closed installer, and session attestation in 0.7.4.
More to come, and quickly!
Signed releases:
github.com/gebruder/wirken/releases.
Verification in docs/release-signing.md.
Audit chain in docs/architecture.md.
Interesting name for the update. What inspired the term “Agentic Switchboard”?
@Betka Thanks. Wirken is German for “to work, to weave, to have effect.” The name is from Gebrüder Ottenheimer, a weaving mill founded in 1862 in Württemberg. A switchboard is the industrial-era thing that replaced the weaving loom: connecting lines instead of threads, routing signals instead of making cloth. Wirken is the gateway that connects chat channels to an agent, one line at a time, with every call logged. Felt like the right frame for what the software is and does.