The Permission Creep Problem: Why AI Agents Accumulate Access They Were Never Meant to Have

Source: Dev.to

The Permission Creep Problem

There’s a pattern I see in almost every AI agent deployment that reaches 90 days in production:

The agent started with read‑only access. It needed to write a file. Then send a notification. Then post to Slack. Then trigger a webhook.

Each addition made sense in isolation. Together, they created an agent with far more power than anyone intended.

This is permission creep — and it’s one of the most underrated reliability risks in AI agent operations.

Why It Happens

AI agents in production are constantly hitting the edges of their configured permissions. When they do, the natural response is to add access:

• Agent needs to log results → gets write access to a directory
• Agent needs to alert on failures → gets Slack webhook
• Agent needs to update a record → gets database write access
• Agent needs to send a summary → gets email‑send permissions

None of these individual decisions are wrong. But there’s rarely a moment where anyone steps back and asks: “What can this agent actually do now?”

After 90 days, the answer is usually: a lot more than you think.

The Cost of a Mistake Scales With Access

A read‑only agent that drifts produces wrong output. You catch it, fix it, move on.

An agent with email‑send access that drifts sends 200 customers a confused message at 2 AM.

The capability hasn’t changed — just the blast radius.

The Monthly Permission Audit

Fix this with a monthly 10‑minute review. For each agent:

1. List what it can actually do
   Don’t rely on documentation. Check the actual credentials, API keys, and file paths it has access to. Reality and documentation diverge fast.

2. Ask “what’s the worst single action this agent could take?”
   If that action would be catastrophic, you have a problem regardless of how unlikely it seems.

3. Apply the principle of minimum necessary access
   For each permission: is this required for the agent’s core function? Or is it a convenience that accumulated over time?

4. Document what you remove
   Log every permission you strip. If it was legitimately needed and you find out later, you want a record of why you removed it.

The SOUL.md Permission Block

The most reliable agents I’ve worked with have an explicit permissions section in their identity file:

## Permissions
### Can do without asking:
- Read any file in /workspace
- Write to memory/ and logs/
- Post to outbox.json

### Must ask before doing:
- Writing outside /workspace
- Sending any external message
- Making any API call with write access

### Never do:
- Send email
- Make financial transactions
- Modify SOUL.md or config files
- Access files outside designated directories

This isn’t just documentation — the agent reads this file every turn. The permission boundaries are part of its working context, not a one‑time setup.

The Reload Rule

Permission documentation only matters if the agent actually reads it. Most agents load their config once at initialization and then drift from it as the session accumulates context.

Fix: reload the permission block at the start of every turn, or at minimum at the start of every session. If the agent reads its permission boundaries before every action, it can’t drift into territory it was never meant to enter.

Practical Setup

• Today: Spend 10 minutes listing every credential, API key, and file path your agent has access to. Compare it to what you intended when you built it.
• This week: Add a permission block to your SOUL.md. Make it explicit — what the agent can do, what requires approval, and what it should never do.
• Monthly: Set a calendar reminder to re‑audit permissions. Add new access intentionally, not reactively.

Permission creep is a slow problem that becomes a fast crisis. The agents running in production for 6+ months without incident almost always have explicit, actively maintained permission boundaries.

The configs that work — including permission block templates we use across five production agents — are in the Ask Patrick Library.