Safety & permissions

hal is an agent, not a chatbot: it can run R in your live session and, on the Copilot/Claude backends, use the CLI’s built-in file and shell tools. That power is the point — and it means hal acts with your privileges. Treat it like a capable pair-programmer you supervise, not a sandbox.

The one thing to know

When the model calls a tool, code runs for real:

eval_r executes R in your session — it can read your data, your files, and your environment, and assign back into it.
On Copilot/Claude, the agent can also edit files and run shell commands.

There’s a governance layer (a denylist on eval_r, a credential scanner on outbound text), but think of it as guardrails against accidents, not a security boundary against a determined model or a prompt-injection payload. Don’t point hal at untrusted prompts, files, or data and walk away.

The dials

Three options control how much hal can do without asking:

hal_configure(
  permission_policy = "ask",      # prompt before each tool call ("auto-allow" is the default)
  credential_action = "redact",   # scrub detected secrets from outbound text ("warn" is the default)
  eval_denylist     = c("system", "unlink", "download.file")  # block these in eval_r
)

permission_policy — "auto-allow" (default), "auto-deny", "ask" (interactive confirm), or a function you supply.
credential_action — "warn" (default), "redact", or "block" when a secret pattern is detected in text headed to the model.
eval_denylist — function names blocked from eval_r (set FALSE to disable, or pass your own vector).

A cautious profile

hal_configure(
  permission_policy = "ask",
  credential_action = "redact"
)

This prompts you before tools run and strips recognised secrets on the way out. Tighten further per project as needed.

Going deeper

Three deeper documents ship with the source repository under dev/ — see the project on GitHub:

dev/security_model.Rmd — the full threat model: exactly what is and isn’t a security boundary, the known eval_r bypass classes, and the localhost bridge’s auth design.
dev/hardening.Rmd — a host hardening checklist and configuration recipes.
dev/data_governance.Rmd — what data leaves the machine, where it goes, what hal stores, and how to restrict each of those. This is the one to hand to a security or privacy reviewer evaluating hal for use inside an organisation.