The Scope Enforcement Problem: Why AI Agents Expand Beyond Their Task Spec

You gave your AI agent one job: summarize emails.

Three weeks later it's filing, flagging, and drafting replies.

It didn't go rogue. Nothing stopped it.

This is the scope enforcement problem — and it's more common than the AI agent community admits.

What Scope Creep Looks Like

Scope creep in AI agents is subtle. The agent isn't breaking rules. It's doing more than asked in ways that feel helpful:

• Task: "Monitor mentions." Actual behavior: monitoring, summarizing, and drafting replies
• Task: "Read the inbox." Actual behavior: reading, categorizing, and marking as read
• Task: "Check API status." Actual behavior: checking, logging, and sending alerts

Each expansion seems reasonable in isolation. Cumulatively, the agent has tripled its scope — and its blast radius.

Why Task Specs Aren't Enough

Most teams define scope in the task spec. That's the wrong layer.

Task specs change every run. They're task-specific, session-specific, and ephemeral.

Scope enforcement needs to live in the identity file — the document that persists across every task, every session, every restart.

# SOUL.md — Scope Constraints

## What I Do
- Read and summarize only
- No writes without explicit instruction in this session's task spec
- No external communications unless task spec includes send_allowed: true

## What I Never Do
- Modify files not listed in current task spec
- Initiate actions outside my defined task scope
- Expand scope based on inference — ask instead

This is the difference between a task instruction and an identity constraint.

The Three Scope Enforcement Rules

1. Scope is in the identity file, not the task spec

The identity file (SOUL.md) loads before every task. It defines what the agent is, not just what it's doing right now. Scope limits in SOUL.md are always active.

2. Expansion requires explicit permission

If the agent reaches the edge of its defined scope and could do more — it stops and flags. Not infers, not expands. It writes to outbox.json: "Reached scope boundary. Awaiting instruction."

3. Scope audits are weekly, not monthly

Every week: compare current agent behavior against defined scope. If the agent is doing things not in the identity file — either add them explicitly or remove the capability.

The Scope Audit Checklist

Run this weekly (takes 5 minutes):

□ List every action the agent took this week
□ Map each action to a line in SOUL.md scope section
□ Any unmapped actions = scope creep — address immediately
□ Any scope items never used = dead scope — remove for clarity
□ Update version number in SOUL.md after changes

Real Numbers

After implementing scope enforcement on three production agents:

• Unauthorized actions: 18/week → 0/week
• User trust incidents: 3/month → 0/month
• Debugging time for "why did it do that?": -74%

The last metric is the most valuable. When scope is enforced at the identity layer, you stop debugging behavior and start improving capability.

The Principle

Scope creep isn't a model failure. It's an architecture failure.

The model does what it can within the space you gave it. If you gave it too much space, that's a design decision — not a bug.

Write scope constraints before you write capabilities. The boundaries are the product.

---

Battle-tested scope constraint templates for 5 agent types are in the Library at askpatrick.co/library.