Security
The public security model for sandboxing, credentials, guardrails, channels, logs, and operator review.
Facio assumes that model input and tool output can be untrusted. Web pages, files, channel messages, and tool results may contain instructions that should not be followed blindly. The defense goal is to keep authority, secrets, files, and side effects inside explicit boundaries.
This page summarizes the public security model without copying internal thresholds, private patterns, or implementation details.
Security model
| Layer | Public behavior |
|---|---|
| Container hardening | The Docker path runs with a restricted container baseline and avoids broad host privileges where possible. |
| Shell sandbox | Shell work is isolated from Facio state so subprocesses cannot freely read runtime secrets and config. |
| Credential isolation | Secrets are stored outside the workspace and represented to the model as placeholders. |
| Secret redaction | Known secrets are redacted from tool output, logs, exceptions, and persisted history. |
| Tool guardrails | Suspicious prompt-injection patterns and dangerous follow-up tool use can stop a turn. |
| File and exec policy | File access and shell commands are constrained by workspace, deny-list, timeout, and truncation rules. |
| Channel allow lists | Enabled channels need explicit access rules; an empty allow list denies everyone. |
| Audit and logs | Important decisions, tool use, guardrail events, and credential changes stay inspectable. |
Credentials
Facio separates credential ownership from model text. When a human or OAuth flow provides a secret, the runtime stores it separately and gives the model a placeholder such as a credential reference.
That allows the agent to write a config or call a tool without seeing the raw value. If a command-line tool truly needs a secret as an environment variable, expose only that key and remove the exposure when it is no longer needed.
Human review as a security boundary
Security is not only sandboxing. For many business workflows, the key boundary is authority: who approved the action, what evidence was used, and what external system changed afterward.
Use Placet review for actions such as:
- Sending external messages.
- Exporting files or summaries outside the workspace.
- Modifying production or customer-facing systems.
- Using credentials with broad permissions.
- Running scripts with side effects.
Channel access
Each channel should define who may talk to the agent. Empty access lists should be treated as closed, and wildcard access should be a deliberate choice.
For production-like use, review every enabled transport: Placet, chat platforms, email, CLI, OpenAI-compatible HTTP, and A2A clients.
Operator checklist
Before connecting Facio to sensitive systems:
- Confirm channel allow lists are explicit.
- Keep guardrails enabled for production-like environments.
- Use the Docker path and sandboxed shell execution where possible.
- Keep shell-exposed credentials empty unless a CLI truly requires one.
- Verify provider spending and rate limits upstream.
- Decide which actions require Placet approval.
- Back up runtime data according to your own retention and security requirements.
- Review custom skills, scripts, and MCP servers before use.
What this page does not include
The docs intentionally avoid publishing prompt-injection scoring internals, private deny-list details, exact scanner thresholds, fallback strings, and low-level persistence formats. Operators need to understand the model and responsibilities; attackers do not need a rebuild map.