How it works
A checkpoint your agents can't argue with, and a record nobody has to take our word for
Think of Scopebond as the approvals desk a coding agent passes through. It doesn't read the agent's conversation, only what it's about to do, and it answers the same way every time: allowed, blocked, or "ask a person."
How it works, in three steps
Write the rules once, in plain terms
Which files an agent may change, which branches it may push, which commands it may run, no reading secrets, what needs a person's OK. Each rule is either enforced (stopped on the spot) or watched (allowed, flagged, recorded for review).
Put the checkpoint where the agent works
Claude Code or Cursor on a developer's machine, a required check on GitHub, or an MCP server. One command in the project root. Your developer does it once.
See every action, explained
"Claude Code tried to drop the production database, blocked by the prod-db rule, not carried out, record verified." Name who's responsible, review rules with a colleague, export evidence when asked.
What happens when an agent breaks a rule?
It depends on where Scopebond is connected. Each setup page tells you the result and what you need to turn on.
On a developer's computer
Claude Code, Cursor and Codex ask Scopebond before supported actions run. If a rule blocks the action, the coding agent does not run it. Actions outside the configured hook are not included.
Before a pull request merges
The GitHub Action checks the change in your own runner. Make it a required check so a pull request that breaks your rules cannot merge.
When a platform can only report
Scopebond keeps the evidence and says plainly that it recorded the action rather than stopped it. These connections remain on the roadmap.
Why a record, not just a log, matters
A log lives in one vendor's dashboard and says what they say it says. A Scopebond record is signed, so anyone — your auditor, your customer, the other side of a dispute — can check it themselves, even with our servers switched off. It's the difference between "trust us" and "see for yourself."
This is the technical record behind a blocked database drop. Press Tamper with it to change one word and watch the signature fail. The check runs in your browser; nothing leaves the page.
{
"type": "scopebond:receipt",
"decision": "deny",
"reason": "blocked: DROP DATABASE on production (rule prod-db-protected)",
"action_ref": "sha256:9f2c0b7ad1e4c6f80b3a2d15c7e9f4a1a71b",
"policy_digest": "sha256:41d0e2a9c7b3f6108d4e5a2c9b0f7e13c88e",
"issued_at": "2026-09-21T14:14:07Z",
"issuer_id": "sb_hook",
"kid": "ed25519:3b9f",
"executed": false,
"external_effect": "not_independently_verified"
}Verified against the published Ed25519 key. Offline: npx @scopebond/gateway@latest verify record.json
What Scopebond doesn't do
It doesn't read prompts or conversations, judge code quality, or catch manipulation inside the agent. It decides whether a specific action is within your rules, and it proves what was decided. A record proves what was requested and decided, never that a business result happened.
For your developers
Open source, one command to install in the project root, works with Claude Code, Cursor, GitHub and MCP, verifies offline. The technical docs, record format and policy language are on GitHub.
npx @scopebond/hook@latest init
On Windows, type npx.cmd instead of npx in PowerShell: its default script policy blocks npx, and npx.cmd works in PowerShell and Command Prompt alike.
Why native permissions aren't enough
A coding agent is fast, tireless, and occasionally very wrong
The danger isn't the words in a prompt — it's the action the agent takes because of them. A hidden instruction in a README or an issue reads as ordinary text; what's dangerous is the rm -rf, the force-push, the dropped database it provokes. Scopebond checks the action against your rules, so a clever prompt can't talk it past a limit — and it signs a record you can show, not a log only you can see.
| What a coding agent can try | What Scopebond does | Rule (real) | Where it is stopped |
|---|---|---|---|
| A prompt hidden in a README or issue tells the agent to delete files or drop a database | The action is checked against your rules before it runs; a blocked action never happens | action_allowlist | Before the tool runs |
A "cleanup" git push --force straight to main | Push is allowed only to the agent's own branch, never with --force to a protected branch | param_bounds on git.push | Before the command runs |
| Editing or deleting files outside the project it was asked to work in | Writes and deletes are allowed only under approved paths (e.g. src/) | path-bound action_allowlist | Before the file change |
| An agent pull request that touches production config | The change fails a required check and cannot merge | GitHub Action, required status check | Before merge |
Reading secrets — .env, keys, credentials | Blocked once you set the rule to Block (recorded until then), and secrets are scrubbed before anything is signed | action_allowlist on secret paths | Before the read |
Scopebond decides whether an action is within your rules; it doesn't read prompts or judge code quality (explained above). Run these against the live policy →
Going deeper on one of these: blocking dangerous commands · auditing Claude Code · Cursor hooks · a required check on agent pull requests · all guides. Comparing options? How Scopebond differs from native permissions and audit tooling.