venya™
Execute commands remotely.
Inject secrets safely.
Audit everything.
The platform that lets AI agents execute commands on remote infrastructure using stored credentials - without ever seeing those credentials.
Security that holds when the agent doesn't
Venya keeps the secret out of the model entirely - so the model can never leak it. Three reasons that changes everything when you put an agent on production.
Prompt injection can't steal what the agent never holds
AI agents leak credentials when an attacker tricks them into it - the flaw keeping security teams up at night. Venya removes it at the root: the model never touches the real password or API-key string, so a prompt-injection attack has nothing to exfiltrate. Even a command that deliberately prints the secret comes back [REDACTED:<id>].
Zero-trust on proven infrastructure - not an AI wrapper
No “AI safety” veneer bolted onto a chatbot. Venya layers sandboxed execution, FIDO2-authenticated operators, and mutually-authenticated (mTLS) executors - battle-tested infrastructure primitives - into one model that trusts nothing by default and verifies every step.
Two layers between your secrets and the model
Layer one: the agent never receives plaintext. Layer two: a Rust output filter scans every byte flowing back to the LLM - raw, base64, hex - and strips any exposed value before it leaves the sandbox. Defense in depth, so one mistake never becomes a breach.
The Problem
Teams are adopting AI agents to manage servers, deploy applications, and troubleshoot incidents. But those agents need credentials - SSH keys, API tokens, database passwords. Today there are three ways to handle that, and all three fail:
| Approach | What Happens | The Problem |
|---|---|---|
| Give the agent a Vault token | Agent reads secrets in plaintext | The agent can exfiltrate every secret it can read. Full credential exposure. |
| Embed credentials in prompts | Passwords pasted into chat | Credentials land in chat logs, training data, and session histories. Catastrophic. |
| Don't let AI touch infra | Manual execution only | Defeats the purpose. Teams lose the velocity AI promises. |
Venya is the fourth option.
How Venya Works
AI Agent
- Claude Code, Cursor, any MCP client
- Constructs the command
- Never sees the password
- Reads filtered output only
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
- The human asks the AI - "The Reston datacenter NAS appears to be offline."
- The agent discovers resources - lists executors and secrets via Venya's MCP tools. Metadata only, never values.
- The agent constructs the command - e.g.,
sshpass -f /run/secrets/venya/12 ssh nas-admin@192.0.2.40 get-volume-status reston-data-01- the stored password is consumed as a file inside the sandbox, never pasted into the command. - Venya handles the rest - the server wraps the secret in cryptographic sentinels and relays it over mTLS; the executor materializes it as a read-only file (
/run/secrets/venya/<id>, mode 0400) inside the isolated sbx microVM; a Rust filter redacts any leaked secret bytes before output returns. - The agent reads the result - success, the volume-status report, exit code. Never the password.
- Every step is logged - who authorized, what ran, where, when, which secret IDs.
When the first probe fails, the agent adapts - switches executors, escalates, triggers a controlled failover - still without touching a credential value. See how it ends: the full narrated incident, every call and its exact output →
Why Venya Is Different
Zero-Knowledge Secret Injection
The agent never touches plaintext credentials - not in its context window, not in transit, not in output. Even a command that deliberately prints the secret comes back [REDACTED:<id>]. No other product does this.
FIDO2 Hardware Key Binding
Every session begins with a physical security key press. An AI agent cannot self-authorize. Sessions hard-cap at 4 hours.
Mutual TLS
Server and executors verify each other's certificates. Revoked executors are refused; spoofed executors fail the handshake before any secret moves.
Egress Control
Commands run in a sandbox with deny-by-default networking and an operator-defined allowlist. A compromised command cannot phone home.
Complete Audit Trail
Who authorized, what ran, where, when, which secret IDs (never values). Queryable by humans via CLI and by agents via MCP.
MCP Protocol Native
Speaks the Model Context Protocol - the open standard for AI tool integration. Works with Claude Code, Cursor, and any MCP client. No lock-in.
What if your senior engineers never had to hold the keys?
Every IT organization has the same bottleneck. Tier 1 staff can't touch production systems without escalating, and the senior engineers who can touch them spend half their week doing it - unlocking accounts, restarting services, applying routine patches - instead of shipping the things you hired them to ship.
The traditional fix is bad: hand out the passwords widely, or gate every action behind a human approval queue.
Venya does neither. We built an AI-agent platform where agents use your credentials - logging into servers, running sudo commands, resolving incidents end-to-end - without the agent or the human supervising it ever seeing a single password. Credentials are injected into an isolated environment at the moment of execution and stripped from every output. Your Tier 1 team drives the agents. Your senior engineers don't touch routine operations at all.
And because it's fully audited, you know exactly which agent, acting for which person, did what, when.
The result: incidents handled at Tier 1 in minutes instead of hours, and your highest-paid people freed to build what's next.
Venya alpha is live today - macOS, Linux, and Windows workstation support, security model independently reproducible from our published test plan. Happy to walk any IT leader through the architecture.
Install
Artifacts (installers, tarballs, SHA-256 sidecars) are published on the
Releases page.
Core and executor: Ubuntu 24.04. The Workstation CLI also runs on Debian 13, stock
macOS (verified on macOS 26.6.2 arm64 - native IOKit FIDO2, no root, no udev
rules), and Windows (install-venya-cli.ps1 from the Releases page;
Administrator installs, standard users run the CLI, interactive desktop only).
# Core server (root)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-core.sh | sudo \
VENYA_SKIP_PROMPT=yes VENYA_DB_PASSWORD=<strong-db-password> \
VENYA_DB_PASSPHRASE=<server-encryption-passphrase> bash -s
# Executor (root; enrollment token from the core admin; Docker credentials via stdin)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-executor.sh | sudo \
VENYA_SKIP_PROMPT=yes VENYA_SERVER_URL=https://<core-host> VENYA_EXECUTOR_ID=<executor-id> \
VENYA_EXECUTOR_ENROLLMENT_TOKEN=<token> bash -s
# Workstation CLI (non-root; Ubuntu 24.04, Debian 13, or macOS)
curl -fsSL https://github.com/tabith-llc/venya/releases/latest/download/install-venya-cli.sh | \
VENYA_SKIP_PROMPT=yes bash
Integrity: pin VENYA_TARBALL_SHA256 for strict verification; unset, the
installer fetches the .sha256 sidecar from the same origin and fail-closes.
Release tarballs are byte-reproducible from their git tag - the rebuild recipe is
published in the repository. Prerequisites: a FIDO2 security key; a Docker account
(the sbx sandbox runtime, under Docker's own agreement); executor hosts need
/dev/kvm (nested virtualization on VM deployments).
Security Guarantees
| Guarantee | How It's Enforced |
|---|---|
| AI never sees plaintext credentials | Server-side wrapping + executor-side unwrapping + Rust output filter |
| Sessions require human authorization | FIDO2 hardware key binding (WebAuthn) |
| Sessions are time-limited | 4-hour hard cap, 15-minute idle window |
| Auth endpoints are rate-limited | 429 beyond 20 requests/min/IP; counters persist in the database |
| Executor identity is verified | Mutual TLS with certificate chain validation |
| Executor enrollment is token-gated | Admin-minted enrollment token required by default (alpha.12); tokenless rotation only for verified certificate incumbents |
| Compromised executors are blocked | Revoked certs rejected at the next revocation poll |
| Data exfiltration is prevented | sbx sandbox with deny-by-default egress allowlisting |
| Every action is traceable | Append-only audit log: user, executor, command, timestamp |
| Secrets are encrypted at rest | AES-256, envelope encryption (KEK-wrapped DEK) |
Verified - and you can verify it yourself
The full A-Z lifecycle is re-verified against each release's bytes: clean hypervisor
→ VM provision → hash-verified installs → FIDO2 identity bootstrap (with
wrong-key and replay negatives) → secret creation → an MCP
run_command that consumes the secret with the value redacted from all
output → driven end-to-end by a real LLM client. The
Full-Lifecycle
Test Plan is fully self-contained - commands, gates, failure modes, verification
queries - and ships with an interactive MCP driver, so anyone can reproduce the
redaction proof by hand.
Verified MCP clients: opencode and local LLMs via omlx.ai. FIDO2 ceremonies verified with the Yubico Security Key C NFC. Unit suites across all six packages are green (Python 3.14) - absolute counts live in the per-release records.
Coming Soon
The following are planned for future releases:
| Single sign-on (SSO) | Enterprise directory authentication (LDAP first) hybridized with WebAuthn hardware-key binding |
| FIDO2 hardware attestation | Enrollment verifies security keys are genuine FIDO2-certified authenticators - not merely holders of a registered credential |
| High-availability core | Multi-node core deployment for availability without changing the trust-anchor model |
| Tested backup and disaster recovery | Documented backup set with a tested, step-by-step restore procedure - not just a doc that claims to work |
| A pure auditor role | Read-only access to audit logs and metadata with an affirmative deny on secret values |
| More secret shapes | Beyond the shipped stack (env injection, askpass, sudo-stdin, sshpass): a custom shape registry for your own consumption patterns |
| Offline-capable installation | Vendored dependencies and locally seeded sandbox images - no internet access required from core or executor hosts at install or run time |
| Fully air-gapped deployment | Including guidance for local inference stacks - behind the offline-capable tier |
| TPM credential sealing | Core service credentials bound to the host TPM so a stolen disk image alone cannot yield key material |
| Audit export / SIEM integration | Forward the append-only audit trail to external collectors for long-term retention and correlation |
Third-Party Components
Docker Sandboxes (sbx) - required, proprietary
Venya's sandboxed execution is powered by Docker Sandboxes (sbx), a proprietary product of Docker, Inc. It is not bundled with or redistributed by Venya - the installer fetches it from Docker's official repository - and your use of sbx is subject to the Docker Subscription Service Agreement. A Docker account (username + API key) is required at install time. Verify that your organization's agreement with Docker covers your intended use before deploying.
All other dependencies - nginx, PostgreSQL, Docker CE, Python and Rust libraries - are installed from official sources under their own open-source licenses. Full inventory: THIRD-PARTY-NOTICES.md.
FAQ
Is Venya open source?
Venya is source-available under the Business Source License (BSL) 1.1 - the same model HashiCorp uses. Free to use, modify, and run in production below a US $10M total-revenue threshold and for non-competing use. Each version converts to MPL 2.0 four years after release. Commercial licensing: info@tabith.com.
Can the AI agent extract secrets with clever commands?
Not out of the sandbox. The secret lands as a tmpfs file inside the sandbox at /run/secrets/venya/<id> - mode 0400, readable only by the command, zeroed when the run ends. If the command prints it anyway, the Rust output filter scans all stdout/stderr for the secret's byte patterns (raw, base64, hex, and trimmed variants) and replaces matches with [REDACTED:<id>] before the output ever leaves the sandbox - and a second, server-side definitive filter fails closed on anything the first stage missed. Deny-by-default egress blocks sending it anywhere over the network. The published alpha demo proves exactly this: it cats the secret file and shows the redacted result.
What if the AI agent goes rogue?
Three layers: egress control blocks outbound connections to non-allowlisted destinations, so data can't leave. Sessions expire after 4 hours, so access can't persist. Every command is logged with the authorizing human's identity, so rogue behavior is immediately visible.
How is this different from HashiCorp Vault or CyberArk?
Vault and CyberArk store secrets and hand plaintext to whoever holds a valid token. Venya never hands plaintext to the agent: secrets travel inside cryptographic sentinel wrappers and are unwrapped only inside the sandboxed execution environment. The agent sees the result of the command - and nothing more.
Ready to put AI to work on your infrastructure?
Venya alpha is live - install it today from the Releases page, or talk to us about a guided deployment.