venya™
Execute commands remotely.
Inject secrets safely.
Prove it to your auditor.
The platform that lets AI agents execute commands on remote infrastructure
using stored credentials - without ever seeing those credentials.
Governance, engineered in - not bolted on. Phishing-resistant FIDO2 access,
database-enforced append-only audit, zero-knowledge disclosure.
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.
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 sandboxed execution, FIDO2 and mTLS - not an AI wrapper
No “AI safety” veneer bolted onto a chatbot. Venya layers sandboxed execution, FIDO2-authenticated operators, and mutually-authenticated (mTLS) executors - established 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 every match before it leaves the sandbox. Defense in depth, so one mistake never becomes a breach.
Control status at a glance
Fourteen controls, one status each. Ships today means the mechanism is in
product source and its cite resolves; it does not claim every one has been seen behaving on a
served fleet. Planned means the product does not do it yet, and the detail sits
in Coming Soon below. Not enforced today means the
capability appears somewhere in our material but no code enforces it - said here rather than
left implied. Statuses are transcribed from the control mapping in this repository
(sales/control-mapping.md, product tree at 802bbbd) - a tree older
than current development, so a status here can lag the code in either direction. That table
is being re-derived row by row and its full version will get its own page here. The fourteen
controls below map to SOC 2 CC6 and CC7 criteria and to NIST SP 800-53, and we are
pursuing a SOC 2 Type II. As everywhere on this page: this is
alignment, not certification.
| Control | Status | What it is |
|---|---|---|
| FIDO2-only human authentication | Ships today | Sign-in runs on hardware-key assertions; failed logins are recorded as audit events |
| Per-value hardware-key elevation | Ships today | An elevation token is consumed atomically - one key touch authorises one retrieval |
| Role-gated disclosure | Ships today | The auditor tier cannot read secret values, and an attempt is denied and logged rather than silently narrowed |
| Zero-knowledge execution path | Ships today | Secret material reaches the command over file descriptors; the audit record carries environment names, never values |
| Zero-knowledge disclosure control | Ships today | Values are masked by default and executor output is redacted on the way out |
| Sandboxed command execution | Ships today | Commands run in the sandbox, and the executor refuses rather than degrading when the sandbox binary is absent |
| Deny-by-default egress allowlisting | Ships today | Sandbox egress is filtered against an operator-maintained allowlist; a missing or empty file fails closed |
| Self-hosted perimeter | Ships today | The mapping found no outbound vendor service call in product source - the https addresses that do appear are documentation and install hints |
| Tamper-evident, append-only audit | Ships today | A migration revokes UPDATE and DELETE on the audit table from the application role, so that path cannot rewrite or drop records |
| Separation of duties | Ships today | Admin, operator and auditor are separate tiers, and a mixed auditor grant is refused as a conflict |
| Attributable, granular accountability | Ships today | Each execution emits an event naming the command, the strategy, the descriptor count and the secret ids involved |
| SOC 2 CC6 / CC7 engineered controls | Ships today | Those are the rows above; a Type II attestation is a separate, independent, future event and nothing here says one happened |
| Governance export pack (Professional tier) | Planned | Coming soon |
| Custom CA / PKI integration (Enterprise tier) | Planned | Coming soon |
Coming Soon
The following are planned for future releases:
| Audit export / SIEM integration | Forward the append-only audit trail to external collectors for long-term retention and correlation |
| TPM credential sealing | Core service credentials bound to the host TPM so a stolen disk image alone cannot yield key material |
| Fully air-gapped deployment | Including guidance for local inference stacks - behind the offline-capable tier |
| Single sign-on (SSO) | Enterprise directory authentication (LDAP first) hybridized with WebAuthn hardware-key binding |
| FIDO2 hardware attestation | Enrollment records each key's attestation data today; the verification step that would tell a genuine FIDO2-certified authenticator from the holder of a registered credential is the part that does not ship |
| High-availability core | Multi-node core deployment for availability without changing the trust-anchor model |
| Custom CA / PKI integration | Bring your own certificate authority for service and admin certificates - the Enterprise tier that carries it is itself planned, not sold |
| More secret shapes | Beyond the shipped stack (env injection, askpass, sudo-stdin, sshpass, ssh-key, http-netrc, http-header-file, mysql, ipmi): 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 |
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 →
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 beta 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.
#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.
#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; 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 | Envelope encryption - per-secret DEK wrapped with AES-256-KW; payload ChaCha20-Poly1305 |
#The Auditor Role
Compliance reviewers need to see what happened without being able to change anything - and without ever holding a credential. Venya ships a dedicated permission tier for exactly that: three tiers - read, read-write, and auditor - plus the seeded admin role.
| Tier | What it can do |
|---|---|
| read | Metadata listings and masked secret reads |
| read-write | Reads plus writes: create/delete secrets, create sessions, execute commands |
| auditor | Read visibility across secrets, roles, and executors (metadata) plus the full audit log - with an affirmative deny on secret values |
The value-deny is not a convention - it is enforced at the plaintext chokepoint. An auditor-only caller requesting a secret value gets a 403 even with a valid elevation token, refused before the single-use token is consumed, and every refusal is written to the append-only audit log. Elevation is never issued to auditor-only callers at all, so an auditor cannot self-register a FIDO2 security key - an administrator provisions their credential.
The auditor tier is exclusive by design - separation of duties. Any role grant or tier change that would combine auditor with another tier for one user is refused with a 409 and written to the audit log, so audit independence is enforced by construction, not by convention. The design addresses five NIST SP 800-53 Rev 5 control families: separation of duties (AC-5), audit-record content and failed-access logging (AU-3, PCI DSS 10.2.1), and audit review with attempted-bypass visibility (AU-6), on top of the existing append-only audit log (AU-9/AU-10). Alignment is a design statement, not an attestation - certification requires an assessor.
#Control mapping - SOC 2 and NIST, row by row
Shipped mechanisms mapped to the controls prospects ask about, each
re-cited to product code at a named commit (the full table with every
file:line cite is sales/control-mapping.md in this repo).
This is alignment, not certification: an attestation
needs an independent assessor, and nothing on this page says one
happened.
| Control | Venya mechanism | What it does NOT claim |
|---|---|---|
| SOC 2 CC6 - logical access | Passwordless FIDO2 login (no human password pathway); per-request session validation; admin plane additionally requires a client certificate; server-enforced role scope with an affirmative deny on secret values; deny-by-default command policy and egress allowlist on the executor side. | Not assessed or certified; the listener revocation door is captured across both populations (path specimen 7a19e4c6b3d82f57, width specimen 0D3A4D4EF914DC3F81546B106C46B3224E280102), the dial-out door is code-present and unit-asserted with physical capture pending (see beta-known-limitations, GitLab #676/#597, open at the time of this writing); says nothing about customer-side physical or environmental controls. |
| SOC 2 CC7 - monitoring | Every execution, refusal, denial, failed login, and policy change emits an audit event; rate-limit tiers count hits; executor liveness is heartbeat-derived; local spool protects refusals at mode 0600 when the core is unreachable. | No alerting or SIEM integration ships - the trail is queryable, nothing pages a human; these are Venya's own signals, not an independent monitoring service. |
| NIST AC-5 - separation of duties | Admin / operator / auditor tiers with uniqueness guards; the auditor tier is exclusive by construction - mixed grants are refused and logged, secret values stay denied even with a valid elevation token, and elevation is never issued to auditor-only callers. | Covers duties inside Venya's API, not a customer's procedural separation; no two-person rule ships for destructive operations - the Shamir CA-key split is custody, not dual-control authorization. |
| NIST AU-3 - record content | Audit events carry type, actor, structured fields (command, executor, secret ids, outcome), and a timezone-aware timestamp - never secret values. | Not evidence-grade (no per-record signatures or authority timestamps); the command string itself is recorded unmasked, disclosed not fixed. |
| NIST AU-6 - review and analysis | A dedicated auditor tier reads the full trail - including its own denials - through the API, the venya audit CLI, and the MCP get_audit tool; everyone else is self-filtered server-side. | Query and eyeball only: no analytics or exception reporting ships; revocation-refusal review evidence is captured at the listener door across both populations (path specimen 7a19e4c6b3d82f57, width specimen 0D3A4D4EF914DC3F81546B106C46B3224E280102), and rests on unit assertions at the dial-out door until its physical capture lands (see beta-known-limitations, GitLab #676/#597, open at the time of this writing). |
| NIST AU-9 - audit protection | Database-enforced append-only: the application role keeps broad grants, then UPDATE and DELETE on the audit table are revoked last so the revoke wins - the app path cannot rewrite or drop audit rows at the SQL door. | Guards the application path, not a PostgreSQL superuser with host root; no hash-chain or per-record cryptographic sealing exists - alignment here is access-control-based. |
| NIST AU-10 - non-repudiation | Each record chains to a user_id whose session required a FIDO2 hardware-key assertion and re-validates per request - attribution runs from record to key-touch to named human; machine credentials live in separate tables and never masquerade as people. | Not cryptographic non-repudiation: records are unsigned, so the same superuser-plus-host boundary as AU-9 could in principle forge history; the claim is attribution design, not evidence-grade repudiation resistance. |
#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 Yubico Security Keys. Unit suites across all six packages are green (Python 3.14) - absolute counts live in the per-release records.
#Making Venya Easier to Use
Venya ships locked, and every lock above is why you installed it. But
not every deployment is a regulated enterprise - wanting less friction
is a legitimate choice, and the product supports it deliberately: every
relaxation is a documented door with a named tradeoff, never a hidden
one, and there is no "turn everything off" mode. The full guide - with
exact config locations and worked examples - is in the product
documentation as docs/ease-of-use.md.
The worked example, "allow scp": a sandboxed scp
is stopped by exactly two enforceable layers - the command policy's
dangerous-pattern list (which applies under every preset, including
permissive) and the sandbox's deny-by-default egress allowlist. Opening
it means two intentional edits: replace the pattern list server-side
minus the names you want (propagates to executors in ~30 seconds,
audit-logged), and add your transfer target to
/etc/venya/egress-allowlist.txt on the executor (read at every
sandbox creation - applies on the next command, no restart). What you
give up, stated plainly: file movement - for anything running in the
sandbox, including a misled agent - toward exactly the hosts you
allowed. Unrelaxed, the default stays fail-closed: the run is refused
before it starts, and the refusal lands in the audit log.
| Door | You gain | You give up |
|---|---|---|
| Command policy: preset + pattern list (admin API / CLI) | more commands run without per-command allowlisting - or one exact binary, via the strict allowlist | each guardrail you drop, for every command under that policy |
| Egress allowlist entries (/etc/venya/egress-allowlist.txt) | sandboxed commands reach the hosts you list | exfiltration prevention toward those hosts |
| Session windows (idle, token TTL, hard cap - core env) | longer working blocks, fewer re-authentications | a live session stays usable longer |
| Rate limits (per-endpoint counts, or the whole tier off) | no accidental lockouts, more headroom | brute-force defense, in proportion |
| Executor enrollment without tokens | simplest possible batch enrollment | the gate that stops strangers claiming executor identity |
| Comfort: clock-skew tolerance, timeouts, CORS, log level, body size | typical small-deployment friction removed | named per knob in the guide - most cost little, none are free |
Three things are never ease-of-use knobs: TLS verification, certificate validation, and default credentials. They are load-bearing walls, not furniture - there is no supported production door to turn them off, and this guide's door catalog does not reach them. The sandbox's deny-by-default egress works the same way in spirit: relax it by adding the hosts you need, never by removing the default.
Install
Release status. Venya is in its design-partner beta program, and tagged
beta releases are public: v0.1.0beta2 is current as of 30 October 2026.
Installs run from the releases/latest paths below, which are
version-independent, so they keep working as new betas land. The installer downloads its
Python toolchain and package dependencies at install time, so an install needs an outbound network
path - offline and air-gapped installation is roadmap work, not a present feature.
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_DNS_RESOLVER=<resolver-ip> \
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).
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. We check for dependency vulnerabilities every day, and will attempt to mitigate within one business day. Full inventory: THIRD-PARTY-NOTICES.md.
Beta Program - Design-Partner Slots
Venya is in beta today. Design partners deploy it in production-like environments at founding-partner terms and shape what the production release becomes.
| Term | Beta Partner |
|---|---|
| Price | $7,200/year flat - all-inclusive license + support |
| Executors | 5 included, up to a ceiling of 10 total; additional executors at $500/executor/year. The included allowance is a ceiling, not a requirement. |
| Support | Founder-direct email + phone during US business hours, best-effort response (no contractual response-time SLA) |
| Entitled to | All beta releases; upgrade to the production release at no additional cost for year one; founding-customer pricing when moving to a production tier |
| Partner provides | Monthly feedback session; early access to beta features in a production-like environment; honest bug reports. Case study/logo rights nice-to-have, not required. |
Production Release Pricing
Pricing at general availability: annual license + support per deployment, with a per-executor add-on. Beta partners move to a production tier under the founding-customer terms above.
| Tier | Price (annual) | Support | Response posture |
|---|---|---|---|
| 1 - Standard (planned, GA) | Indicative target: $12,000/year - not open for sale today. 5 executors included (ceiling 10) | Email + 3 phone incidents/year | 2-business-day email target; phone during business hours; no contractual SLA |
| 2 - Professional (planned, GA) | Contact us at GA - 10 executors included (ceiling 25) | Email + business-hours phone, named technical contact | Business-hours contractual response targets determined at upgrade |
| 3 - Enterprise (planned, GA) | Contact us at GA - 25 executors included (ceiling 100) | Adds on-site audit support, custom CA/PKI integration, source-code escrow, roadmap priority | Not open for sale today - support and response terms are published at general availability |
They are not open for sale today - prices and terms for each will be published at general availability. All prices USD, per deployment, annual. Commercial licensing questions: info@tabith.com.
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 re-checks the output against the authoritative values,
failing closed on unrecognized sessions.
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.
Deployment FAQ
How many users can Venya support?
We size by concurrent sessions, not users. A single core server is estimated to handle hundreds of enrolled users (the ceiling is not load-tested), and the core is measured not to be the bottleneck on the serial path (~0.1 CPU-s per relayed command). Each executor runs one command at a time (~7.2 s per warm command, ~8.3 commands/min); add executors to scale linearly. See the Deployment Sizing Guide for measured figures.
What does "serial execution" mean, and will queueing cause delays?
Each executor runs one command at a time - a deliberate isolation property (secrets and execution contexts never interleave). For single-session workflows it is imperceptible. Queueing appears only when concurrent sessions exceed executors; the 300-second relay budget is reached at ~41 queued commands on one executor, which is the signal to add another (online, no downtime).
What happens if the core server fails?
Commands ride the core relay over mutual TLS. If the core is unreachable, new commands cannot be relayed (fail-closed); the executor's audit trail buffers locally and reconciles automatically when the core returns. High-availability core redundancy is on the roadmap.
Where do secrets live, and who can access them?
Secrets are encrypted at rest (envelope encryption - per-secret DEK wrapped with AES-256-KW; payload ChaCha20-Poly1305). At runtime a secret is never in shell arguments, logs, or agent-visible output; plaintext exists only transiently inside the executor's sandbox-injection path - a documented trust boundary - and output is redacted. Access is role-gated and every session requires a FIDO2 hardware-key touch; even administrators cannot view plaintext without a separate permission plus a key touch, and it is audited.
Can Venya meet compliance requirements (SOC 2, etc.)?
Venya's controls are engineered to satisfy the SOC 2 CC6 / CC7 control families and are mapped to NIST SP 800-53 security controls - the row-by-row version is on the Security page, and we demonstrate the specific controls during procurement reviews. We are pursuing SOC 2 Type II - engagement planned following our beta program, prioritized by our design partners' compliance requirements. Ask us for our control-architecture mapping. Pursuing an attestation is not holding one: this is alignment, and nothing here says a Type II audit has happened.
Can an admin delete the audit log?
Not from the application. A migration revokes UPDATE and DELETE on
the audit table from the application role, and revokes them last so the revoke wins: the
application's own path cannot rewrite or drop records. Two boundaries we state rather than round
off - a PostgreSQL superuser with host root is a different threat, and there is no hash chain or
per-record cryptographic sealing, so this protection is access-control-based, not cryptographic.
What infrastructure do I need?
Two Ubuntu 24.04 VMs minimum (one core, one executor). Core: 2 vCPU / 4-8 GB, 10 GB disk class. Executor: 2 vCPU / 5 GB, 60 GB provisioned disk (~7 GB used post-install, warm sandbox template included), hardware-virtualization access (/dev/kvm). We handle networking, TLS certificates, and integration during onboarding.
Do I need internet access?
Initial installation does - for package downloads and the sandbox-template pull. Offline-capable installation is on the roadmap; no release for it has been scheduled.
How long does installation take?
Measured: core ~45 seconds, executor ~3-5 minutes (network-dominated - the warm-template pull). Total fresh deploy ~4-5 minutes on a typical link. Onboarding adds hands-on assistance and verification testing.
Will my configuration carry forward to production?
Yes - your deployment architecture, enrolled users, and secret inventory persist through the transition. Any GA configuration changes are documented in advance.
Ready to put AI to work on your infrastructure?
Venya beta is live - install it today from the Releases page, or talk to us about a guided deployment.