Riven Exec

The execution layer for agents: runs tool calls in isolated sandboxes with an audit trail, so an agent can act on the world without being trusted blindly.

An agent that can only talk is safe and limited. An agent that can act needs somewhere to act *inside* — bounded, observable, and revocable. Exec is that boundary: every tool call an agent makes runs here, not in the surface that requested it.

What it provides#

• Isolation — each run gets an ephemeral sandbox with its own filesystem, destroyed afterwards. Nothing persists between runs unless it was written to a deliverable.
• Scoped credentials — secrets are injected at call time from Keymaster and scoped to the run, so an agent never holds a long-lived key.
• Egress control — network access is default-deny with an allowlist per tool, which is what stops a compromised tool from becoming exfiltration.
• Resource limits — CPU, memory, and wall-clock ceilings; a runaway loop is killed rather than left to burn budget.
• Audit — every call, argument, and result is recorded and attributable to a run, a key, and a user.

Approval gates#

Not every action should be autonomous. Tools are classified by reversibility, and irreversible ones — sending an email, moving money, deleting records — can require explicit human approval before Exec will run them. This is what makes plan-first mode in Computer meaningful rather than decorative.

Where tools come from#

Tool definitions are supplied by Riven Cortex, which speaks MCP. Cortex describes *what* a tool is and how to call it; Exec decides *whether and where* it runs. Keeping definition separate from execution is what allows a tool to be added without widening the trust boundary.