Security by design

The worker's claim is never the evidence.

Skep isolates coding agents, independently verifies their work, and gives you the final say before anything lands in your repository.

Local-first Open source No cloud required

THE SKEP SECURITY MODEL

Sandbox

The agent runs in an isolated worktree with controlled filesystem and network access.

Execute

The agent works, runs commands, and produces changes plus an event log.

Verify

Skep re-runs the project's pinned verify command on a fresh copy, independently.

Approve

You review the patch and evidence. Only then does it land on a dedicated branch.

The agent cannot modify your repository, push, or bypass approval.

1. Sandboxing

Everything the agent can do is intentionally constrained.

Skep uses OS-level sandboxing to limit what the agent can reach. Each run happens in a disposable Git worktree, isolated from your main repository.

The sandbox mounts the root filesystem read-only and binds back only the intended writable roots: the workspace, the results directory, and task-specific temp locations.

WHAT'S RESTRICTED

Writes outside the worktree Git push, pull, and fetch Outbound network by default Environment secrets and tokens Modifying Skep's own configuration Committing to your repository

WHAT'S ALLOWED

Read and write inside the worktree Run allowlisted commands Use approved tools and MCP servers Network to approved domains Write to the results directory Request more permission at a gate

Sandbox backends: macOS Seatbelt (sandbox-exec) / Linux bubblewrap (bwrap). Reads are not fully confined — the env allowlist closes secret exposure.

2. Independent verification

Verify every claim. Independently.

Skep never trusts the agent's claim. It runs the project's pinned verification command on a clean copy of the worktree.

$ uv run pytest
========== test session starts ==========
platform linux -- Python 3.12
collected 142 items
......................... [100%]
142 passed in 18.4s
=========== 142 passed ===========

Fresh copy Pinned command Real results

3. Approval gates

You control what happens next.

Skep asks for permission when needed and before landing changes. Allow once, remember, or deny.

Permission requested network.access

registry.npmjs.org

Install the package pinned in package-lock.json

Scope: this run only

npm install axios@1.6.7

4. Git protections

Your repository stays safe. Always.

Workers cannot push, pull, fetch, or change your Git history — no permission grant overrides that. Approved work lands on a dedicated branch, never on main.

Cannot push Cannot pull or fetch Cannot checkout or switch branches Cannot commit to your repository Cannot modify .git or Git config Approved patch lands on skep/<id>

main skep/7d31f9c2

Security limitations

Skep makes agents safer. It's not a silver bullet.

No system is perfect. These are the limits, stated plainly.

Agents still make logic mistakes

Verification helps, but it isn't foolproof.

Local machine risks remain

Malware or a compromised OS is out of scope.

Dependencies can be malicious

Skep cannot control what you install.

Secrets in your repo are still at risk

Don't commit secrets. Use env vars.

Verification command trust

If your command lies, Skep can't detect it.

Human decisions matter

Approval is the final safety net.

Report a security issue

Skep is a security-posture project — a hole in any layer is a security bug even if no data was touched. Please report privately rather than opening a public issue.

anmolnoor59@gmail.com— subject tag [skep security] GitHub Security Advisories

Include your skep version (skep --version), sandbox backend (skep doctor), the boundary affected, and reproduction steps. You'll get an acknowledgment within a week.

See SECURITY.md for details

Secure by default. Transparent by design.

Open source, auditable, and built for developers who take safety seriously.

Install skep Read the docs