AI coding agents are getting powerful — and they’re getting powerful fast. But they operate on a dangerous binary: either they have full access to your systems, or none at all. We need a middle ground.
I’ve been spending a lot of time thinking about agent safety lately. Not the “will AI take over the world” kind of safety. The more immediate kind: “my AI assistant just tried to write to a system file it shouldn’t have touched” safety.
The problem is straightforward. AI coding agents — tools that can write code, deploy infrastructure, modify files, and execute commands — are growing more capable by the month. They’re useful. They save time. They do work I’d rather not do.
But they operate on a binary: either they have full access, or they have no access. There’s no middle ground. No runtime supervision. No way to say “yes, you can edit files in this directory, but no, you cannot touch the production database.”
That’s a problem.
The Binary Trap
Think about how you give permissions to a human employee. You don’t hand them the keys to everything on day one. You give them access to what they need. You watch their work. You escalate privileges as trust builds.
We don’t do this with AI agents. We either sandbox them into uselessness or we give them root.
The industry is waking up to this gap. Several approaches are emerging, each with different tradeoffs. Let me walk through them.
Approach 1 — Runtime Detection
This is the most mature approach. A monitoring layer sits between the agent and the system, watching every system call in real time. The agent tries to read /etc/shadow? Flagged. It opens a network socket to an unknown IP address? Blocked. It attempts to modify a file outside its working directory? Denied.
Pros: Catches bad behavior as it happens. Works for things the agent didn’t declare in advance.
Cons: Requires deep system integration. Can be noisy — legitimate actions can look suspicious. Needs careful tuning to avoid false positives.
Best for: High-security environments where agents need broad access but must be contained.
Approach 2 — Permission Manifests
Before the agent runs, it declares exactly what it needs. Files it will read. Commands it might execute. Network endpoints it will contact. The system checks every action against this manifest and rejects anything outside the declared scope.
Pros: Declarative and auditable. Clear contract between agent and system. Great for compliance.
Cons: Kills adaptability. Agents can’t do anything unexpected — including the useful, creative things that make them valuable. The manifest becomes a straitjacket.
Best for: Repetitive, well-defined tasks where the agent’s scope is known in advance.
Approach 3 — Human-in-the-Loop Approval
Risky actions get sent to a queue. A human reviews, approves, denies, or adds to an allowlist. The agent waits for the response before proceeding.
Pros: Maximum safety. A human is always in the loop for important decisions.
Cons: Creates a bottleneck. The whole point of an autonomous agent is that it doesn’t need hand-holding. If every action requires approval, why not just do it yourself?
Best for: Critical infrastructure changes where human judgment is irreplaceable.
Approach 4 — Blast Radius Containers
Every agent task runs in an ephemeral environment: tight resource limits, no persistent network access, automatic teardown when the task completes. The agent can do whatever it wants inside the box, but it can’t escape.
Pros: Clean, container-native, easy to implement. Whatever the agent does, the box gets destroyed afterward.
Cons: Can’t interact with long-running systems. No persistent state. Hard to use for anything that requires ongoing access to infrastructure.
Best for: Isolated development work, code generation, and tasks that don’t need system access.
Approach 5 — Behavioral Baselines
Watch the agent over time. Learn what “normal” looks like — what files it typically reads, what commands it runs, what times of day it works. Flag deviations from the baseline.
Pros: Adapts to the agent’s actual patterns. No need to declare permissions in advance.
Cons: Training period leaves early gaps. Sophisticated attacks can look like normal behavior if they’re gradual enough. And an agent can learn bad habits that become “baseline.”
Best for: Long-running, established agent deployments where patterns are stable.
The Real Answer: Layers
None of these approaches works alone. The future is layered:
1. Permission manifests for planning — “Here’s what I intend to do.”
2. Runtime detection for execution — “Here’s what I’m actually doing.”
3. Blast radius limits for safety — “Here’s the worst that can happen.”
4. Human approval for the hard calls — “Here’s where I need judgment.”
Think of it like airport security. You show your ID at check-in (manifest). Your bag gets scanned (runtime detection). You can only access certain areas (blast radius). And if something flags, a human decides (approval).
No single layer makes flying safe. The combination does.
What This Means for Educators
If you’re a CTE educator, you’re probably thinking “this doesn’t apply to me.” It does.
Your students will graduate into a world where AI agents are part of every IT workflow. They’ll need to understand not just how to use agents, but how to govern them. The kid who understands agent safety will be more valuable than the one who just knows how to write prompts.
Start teaching this now. Have your students design a permission system for an AI agent. Make them defend their choices. Let them debate whether runtime detection or manifests is more important. The conversation itself is the lesson.
What This Means for You
If you’re already using AI coding agents at work, ask yourself: what guardrails do I have in place right now? If the answer is “none” or “I trust the agent,” you have a gap.
Start with the simplest layer — blast radius limits. Run your agent in a container or a restricted directory. Then add a permission manifest. Then think about runtime monitoring. Each layer reduces risk without sacrificing utility.
The binary of “full access or nothing” made sense when agents were toys. They’re not toys anymore.
