Skip to main content

Advanced 14 - Security verification

Digitorn's security boundaries were verified directly against a running daemon - not just read from the source. Here's what that verification found, and what it means for you as an app author.

What's verified solid​

Path confinement. An agent's filesystem access is confined to its session workdir - a script can't write outside it by passing an absolute path or a ../.. traversal. Both were tried directly against the daemon's tool dispatch (bypassing the LLM, so the test is about the runtime's own enforcement) and both were rejected:

text
write to "/tmp/outside-the-workdir.txt"
→ denied by workdir policy: path escapes the workdir

write to "../../../../../../tmp/outside.txt"
→ denied by workdir policy: path escapes the workdir

See Workdir Sandbox for the full mechanism.

Cross-user session isolation. A session belongs to exactly one user. Every session-scoped endpoint checks the caller's identity against that owner before doing anything - a different user gets a clean 403 Forbidden, never access to someone else's session or conversation.

Tool result framing. File content, MCP server output, and every other tool result reach the model tagged with the tool role - structurally distinct from system and user messages, not just a convention in the prompt text. MCP results additionally carry an explicit marker noting they're external, untrusted content. This is the runtime's structural contribution to resisting prompt injection via tool output.

Writing your own behavior rules well​

If you write a security.behavior.rule_definitions rule to block a dangerous pattern, prefer param_matches (a regex) over param_contains (a plain substring check) for anything you actually want to hold up: a substring check only catches the one exact spelling you wrote, and command-line syntax has a lot of equivalent ways to say the same thing.

yaml
condition:
  param_matches:
    param: command
    pattern: "(?i)\\brm\\b\\s+-?[rRfF]+\\s+(/|~|\\*)"

You don't have to remember this yourself - the compiler warns you automatically (at digitorn lint time if you have the dev CLI, or at digitorn install time either way) if a block rule leans on param_contains:

text
warning[DGT-W0010]: rule "no_rm_rf" blocks on param_contains, a plain
case-insensitive substring check — a reordered or split variant of
the blocked text slips through undetected. Prefer param_matches
with a regex for anything meant to actually stop a dangerous
pattern, not just its one exact spelling

For the strongest guarantee, skip pattern-matching altogether: grant only the specific shell commands an agent actually needs instead of letting it compose arbitrary bash and trying to filter dangerous patterns after the fact.

Going further​

  • The behavior engine reference covers param_matches (regex) and how to compose conditions with all / any / not: behavior module.
  • The path-confinement mechanism verified above: Workdir Sandbox.
  • The audit log captures every tool call (denied or executed), useful for reviewing your app's behavior over time: Security 7 - Audit.