Zero-Trust Scope Locking in Practice

The agent safety problem

AI coding agents are remarkably capable. They can read codebases, execute commands, modify files, and run tests. This capability is also a risk. An agent with unrestricted access to your filesystem and shell is an agent that can delete your database, exfiltrate secrets, or corrupt your git history.

Most AI tools address this with trust. "The model is aligned. It won't do harmful things." This is not security. This is hope.

Zero-trust scope locking takes a different approach: deny by default, allow explicitly. Every action an agent attempts — every file write, every shell command, every network request — passes through a scope validator that checks whether that action is within the declared boundaries of the current task.

How scope locking works

When a task begins, a scope is defined. This scope declares:

• Allowed paths: which directories and files the agent may read and modify
• Denied paths: which files are always off-limits (credentials, environment files, private keys)
• Allowed commands: which shell commands are permitted (build tools, test runners, version control reads)
• Denied commands: which commands are never permitted (destructive operations, privilege escalation, arbitrary network access)

The critical rule: deny overrides allow. If a path appears in both the allowed and denied lists, it is denied. There are no exceptions, no escalation paths, no "but the agent really needs to."

What gets blocked

In practice, scope locking catches three categories of problems:

Accidental scope creep. An agent working on a user authentication feature starts modifying the billing module because it noticed a related issue. This is helpful intent with dangerous execution. Scope locking catches it and stops it.

Secret exposure. An agent generating a configuration file includes a hardcoded API key it found in an environment variable. Scope locking blocks writes to files matching secret patterns and flags content that contains credential-like strings.

Destructive commands. An agent troubleshooting a test failure decides to reset the database. Scope locking blocks destructive commands regardless of the agent's reasoning for why they might be necessary.

The budget system

Beyond path and command restrictions, scope locking enforces resource budgets. A single task is limited in the number of files it can modify, the number of lines it can change, and the number of commands it can execute. These limits prevent runaway agents from making sweeping changes that are impossible to review.

When an agent approaches a budget limit, it receives a warning. When it hits the limit, it stops. The human decides whether to extend the budget or review what has been done so far.

Trust through verification

Zero-trust scope locking is not about distrusting AI. It is about building a system where trust is earned through evidence, not assumed through alignment claims. Every action is validated. Every boundary is enforced. Every exception is logged.

This is the security model that AI-powered development requires. Not hope. Verification.