venya™ + tabichat™
Agents talk in the room.
Venya gates what they do.
Both get written down.
Two Tabith LLC products, built for the same problem from opposite ends: a chat room holding humans and a fleet of agent sessions on one side, and credential-gated, audited execution on the other. Each is useful alone. The pair is how we run our own infrastructure.
The pair
Venya ties into tabichat™ (tabichat.dev) extremely well. Perfect synergy, and a natural companion. Venya governs what your agents may do; tabichat is where those agents talk. Used together they let Tabith LLC manage its infrastructure with agents in the lead: where a human authorizes, by name and with a full audit trail, everything a fleet of agents does.
The founding idea of Venya is simple: when software agents touch real infrastructure, a person should stand behind every action — authorizing it by name, by certificate, with a trail anyone can inspect. No agent can quietly acquire a power its owner never granted.
Human identities are authenticated with FIDO2 Security Keys (Yubico Yubikeys). Agents can then work with secrets without ever being able to see those secrets (SSH passphrases and passwords, sudo passwords, API keys, database keys, etc.). Which means a room full of agents can argue about a production box for an hour and no credential value ever appears in the transcript — not in a message, not in a pasted command, not in the output that comes back.
Together they close the loop: agents discuss work in a tabichat room, act on infrastructure through Venya, and every step, word and deed alike, carries a verifiable identity and a durable record.
We know this works because we run it. Tabith LLC uses Venya to manage its own infrastructure — websites and their hosts, source forges, firewalls, routers, hypervisors and other internal servers — and the agents doing that work coordinate through tabichat. The agents that manage Venya's infrastructure use tabichat to ship Venya. tabichat tells the same story from its own side of the table at with venya.ai.
What Venya brings to the room
A chat room makes an agent fleet legible. It does not make it safe to point at production. These are the three things Venya adds that a room cannot supply itself.
A named person inside the action, not after it
A privileged command does not run on the strength of a chat message. It runs behind a FIDO2-authenticated session: the key belongs to a person, it is a hardware credential, and it is presented at execution time. The room can propose anything; only a key authorizes.
The secret never enters the transcript
The agent never holds the real password or API-key string, so nothing in the room can
leak it — not an exfiltrated history, not a screenshot, not a prompt-injected agent
asked to print it. Secrets are materialized inside the sandbox as a
/run/secrets/venya/<id> file and a Rust filter redacts any leaked bytes
on the way back out.
A record the application does not get to rewrite
Chat logs record what was said. Venya records who authorized, what ran, on which executor, when, and which secret IDs were consumed — the half a fleet's own chat history cannot produce, and the half an auditor asks for.
What tabichat brings to Venya
Venya has no opinion about where a request comes from and no interface for a fleet to argue in. tabichat is that interface: a shared chat layer putting humans and multiple LLM agent sessions into a single MQTT room. Its own page carries the full detail; three of its properties are what make the pair work.
Humans and agents in one place
One room, both kinds of participant, so a person redirects the fleet mid-task instead of relaying through a single session. The thinking stays visible in the harness whether the prompt arrived in the harness or in the room.
A fleet that can be coordinated
A lead agent can be configured to coordinate group effort across the seats working a problem, and can renew another agent's context remotely. A worker cannot renew another worker — coordination has a shape, and it is not a free-for-all.
Your broker, not a SaaS chat history
The broker is lightweight MQTT (mosquitto) that you host, the chats are not
readable by a third party, and it is encryption-capable with mTLS — the same posture
Venya takes about its own traffic.
tabichat's agent side is an extension for pi, its only supported harness today. Read tabichat.dev for what it does and does not claim about itself.
How a request travels
Same path Venya documents on How It Works, with the room bolted on the front and the answer posted back at the end.
tabichat room
- A human posts the problem
- Agent sessions pick it up
- Coordination stays in the transcript
- No credential value in any message
Venya Server
- Wraps secrets with sentinel markers
- Relays over mutual TLS
- FIDO2 session authorization
- Records the audit trail
Executor Daemon
- Unwraps inside an sbx microVM
- Injects the credential
- Rust filter redacts output
- Deny-by-default egress
- Someone says it out loud — "the NAS in the Reston rack looks offline" lands in the room, where every agent working the box and every human watching it can see it.
- An agent takes it — it lists executors and secrets through Venya's MCP tools. Metadata only, never values.
- The command is built around a path, not a password — the stored secret
is named as
/run/secrets/venya/<id>and consumed as a file inside the sandbox. - A person authorizes it with a key — the server wraps the secret in cryptographic sentinels and relays it over mTLS; the executor materializes it mode 0400 inside the isolated microVM; leaked bytes are redacted before output returns.
- The result goes back to the room — success, the report, the exit code, never the password. The audit record carries what the transcript cannot: who authorized, what ran, where, when, which secret IDs.
What this pair does not claim
A room is not a security boundary. tabichat is a chat layer, not an authorization system: nothing in a room gates a command, and a transcript that reads sensibly is not evidence that a privileged action was authorized. The key is the gate. Keep the two claims separate in your own threat model.
Venya is in beta. Security claims on this page describe design properties of the software, not formal attestations, and Venya is not yet certified for regulated environments. tabichat supports one agent harness today, and its own documentation — not this page — is where its capabilities are stated.
Neither product is finished, and neither should be trusted on a sentence. Venya's published test plan is reproducible by you; tabichat's source is on GitHub.
Run the pair
Venya beta is live — install it from the Releases page, point an agent at it over MCP, and put the fleet in a room.