---
title: "Safety & permissions"
output: rmarkdown::html_vignette
vignette: >
  %\VignetteIndexEntry{Safety & permissions}
  %\VignetteEngine{knitr::rmarkdown}
  %\VignetteEncoding{UTF-8}
---

```{r, include = FALSE}
knitr::opts_chunk$set(
  collapse = TRUE,
  comment = "#>",
  eval = FALSE
)
```

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:

```r
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

```r
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](https://github.com/ArcLite-Red/hal):

- `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.
