Security

Security Model

Creor's security is built on the principle of defense in depth. No single layer is expected to catch everything -- instead, multiple overlapping controls work together to minimize risk. The agent can only do what you allow it to do, and each action passes through several checkpoints before execution.

Sandbox

The sandbox provides OS-level isolation for shell commands executed by the agent. It uses platform-native security mechanisms to restrict what a command can access, even if the command itself tries to break out of its intended boundaries.

macOS (Seatbelt)

On macOS, the sandbox uses Apple's Seatbelt framework (sandbox-exec) to create a restricted execution environment. Each bash command runs inside a sandbox profile that defines exactly what the process can and cannot do.

• File read access is limited to the project directory, /usr, /tmp, and explicitly allowed paths.
• File write access is limited to the project directory and /tmp.
• Network access can be fully blocked or restricted to specific hosts.
• Process execution is allowed but constrained to the sandbox rules.
• Access to sensitive directories (~/.ssh, ~/.aws, ~/.gnupg) is blocked by default.

Linux (seccomp + namespaces)

On Linux, the sandbox uses seccomp-bpf to filter system calls and Linux namespaces to isolate the process's view of the filesystem and network.

• System call filtering blocks dangerous operations (e.g., mount, ptrace, reboot).
• Filesystem namespaces limit the visible directory tree.
• Network namespaces can isolate or block network access.
• PID namespaces prevent the process from seeing or signaling other processes.

File Permissions

File permissions control which paths the agent can read from and write to. By default, the agent can access files within your project directory. Access to paths outside the project requires explicit permission.

Default Access Rules

External Directory Access

The external-directory tool lets the agent access files outside your project root. This requires explicit approval and is used when the agent needs to read configuration files, reference other projects, or access shared resources.

# The agent requests access to an external directory
external-directory path="/Users/you/other-project/src/shared"

# A permission card appears for you to approve or deny

Network Policies

Network policies control whether the agent can make outbound connections. This affects web tools (websearch, webfetch), package managers that download from the internet, and shell commands that access external services.

Policy Options

Network policies interact with the sandbox. When sandbox mode restricts network access, shell commands cannot bypass the restriction even if the tool permission is set to allow.

Configuration

Git Secret Scanner

The git secret scanner automatically inspects staged changes for accidentally committed secrets before they reach your repository. It detects a wide range of secret patterns including API keys, tokens, private keys, and connection strings.

Detection Patterns

What Happens on Detection

• The scanner blocks the commit from proceeding.
• A detailed report shows which file, line, and secret type was detected.
• The agent suggests removing the secret and using environment variables or a secrets manager.
• False positives can be dismissed, but the decision is logged.

Permission System

The permission system is the primary user-facing security control. It determines whether each tool call runs automatically, requires your approval, or is blocked entirely.

Permission Levels

Configuring Permissions

Permissions are set in creor.json at the project root. You can configure permissions per tool or set a global default.

Permission Prompts

When a tool has "ask" permission, a permission card appears in the chat timeline showing the tool name, parameters, and a description of what the tool will do. You can approve the action, deny it, or approve it for the rest of the session.

Best Practices

Start with Ask, Relax as Needed

Begin with the default "ask" permission for all tools. As you build trust with the agent's behavior on your project, selectively switch frequently-used tools to "allow".

Keep Secrets Out of Source Files

• Use environment variables for all secrets and API keys.
• Add .env files to your .gitignore.
• Never hardcode secrets in source files, even in comments or test fixtures.
• Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, etc.) for production secrets.

Review Agent-Generated Code

The agent writes code that works, but always review it for security implications. Check for proper input validation, SQL injection prevention, authentication checks, and secure defaults.

Use Sandbox Mode in CI/CD

When running the agent in automated pipelines, enable sandbox mode with the strictest settings appropriate for your environment. Limit filesystem access to only the necessary paths and block unnecessary network access.

Audit Permissions Regularly

• Review your creor.json permissions when onboarding new team members.
• Tighten permissions when working on security-sensitive code.
• Check that no tools are set to 'allow' that should require approval for your threat model.
• Consider different permission profiles for different branches or environments.