Agent and connection
For whoever has to approve it
The Agent connects out. Nothing connects in.
What runs on your servers, what travels on the one connection out, and what stays on the server.
A single Agent, any environment
For whoever has to approve it
An Agent on every server. The fix runs right there.
One service per server, one connection out. That is the whole architecture. The signal leaves on a connection the Agent opens itself, the approved action set comes back down the same connection, and the fix runs inside your own boundary. Nothing listens for inbound traffic, and no cloud provider API sits on the path.
Your environment
Any server — cloud VM · bare metal · on-prem
Virca Agent
collects — and executes
the fix runs right here
not in a console, not through a cloud API
the signal, going out
the approved action set
one outbound TCP connection, opened by the Agent
Virca · US region
Event rules
ActionBooks
built from Builtin Functions — one can chain to the next
Audit log
every run, on the record
reported to team chat, written to the audit log
Agent
On each server, the Agent collects data and runs approved commands over the one connection it opens itself. Credentials stay on your servers, never on Virca's.
One outbound connection
The Agent opens a single outbound TCP connection to Virca. No inbound ports, no VPN tunnel — cloud or on-prem, it is one outbound rule.
ActionBooks
Your engineer names the commands, AI writes the order, and your team approves it. Each one is checked when it is registered, and an event rule can only run an ActionBook that was registered and checked first.
Audit log
Every execution records its trigger, decision, action and outcome.
Integrations are the easy part, and we are not going to dress them up. They change how much Virca can see. They do not change the boundary around what it may run — the part worth reading twice. Reviewing Virca for your company? Send the questions to ask@virca.ai.