Limit Agent Access
How To Automate Safely With Agents Without Surrendering Control
Pushing Agents To Do More
A trend I’ve observed in 2026 is granting the agent expanding privileges in order to minimize human involvement. I believe granting agents greater access is ill-advised. Agents still have an important role to play in automating away toil, but technologists need to keep the inherent risks and limitations of Large Language Model based technologies in mind.
LLMs Are Unpredictable
At the core of Large Language Models (LLMs) is a predictive model that cannot produce consistent outputs given the same input. The inherent randomness makes it difficult to use them in scenarios where consistency, predictability, and safety are important. The temptation is to give too much credence to the marketing promises of greater productivity, but one doesn’t have to look hard to learn about the consequences of placing too much trust in these models.
Tales Of Woe
By now, you may have heard about:
- OpenClaw deleted a director’s inboxdespite stop commands.
- Cursor deleted a production database.
- Replit AI’s agent deleted production data during a code freeze.
- Google’s IDE that blew away an entire drive in an attempt to clear a cache.
- Google Gemini deleting all project files after a hallucination.
I’ve included links to aggregators of such examples at the end of this post.
It’s dangerous to think, “Ah, but that won’t happen to me, I’ll do things better!” Pride goeth before a fall, reader. Turning over critical systems or sensitive data access to an LLM-based agent is an unnecessary and dangerous gamble. It is understandable why this mistake continues being made if you’re in tech; I’d wager you’re being bombarded by a breathless AI hype-cycle that includes your own reporting chain and coworkers.
”But It Feels Intelligent”
A well-trained LLM seems intelligent because they leverage our own language in a way that feels like genuine communication; this feature taps into our human tendency to anthropomorphize. I have included a list of research papers and articles that delve into the ways that the nature of LLMs trigger any number of cognitive biases and logical errors in their human users. I use these tools regularly and I have to be on guard against my own tendency to forget their limitations, risks, and pitfalls. A successful application of LLM based technologies must account for these risks and limitations as a primary aspect of their design.
Cost Problems
Using an LLM is the most expensive way to automate a process that has clear inputs, constraints, conditions, and outputs. The temptation is real: a system that can translate spoken/written language feels like the fastest path to delivering value. But you will spend more money on compute if you need to invoke an agent to perform a task that could be handled by writing a simple script, function, or service instead.
Build Better Automation With Agentic Assistance
Agentic coding tools (Claude, Codex, etc.) can still make major contributions to reliable, safe, and consistent automation. Instead of putting an agent in the driver’s seat at runtime, we’re using it to help us implement the automation that a human has designed.
Good Automation Is Consistent and Correct
The purpose of automation is to define a process that, given a set of inputs and constraints, produces the desired outcome. In practice, software engineers are taught to delay automation of a process until it is well defined, understood, and stable so that the thing being automated is robust, complete, and correct.
Use The LLM To Build Your Automation
Using an agent to produce a working implementation allows you to review, test, and iterate on it in a controlled environment before deploying it to production. The result is a predictable, reliable, and cost-effective automation that is purpose-built for your specific use case. Written programs that are reviewed and tested don’t suffer from the same class or severity of undesirable outcomes because they always behave the same way given the same inputs and environment.
A Simple Example
Several of my projects need a clean Kubernetes environment to test against. Instead of asking Claude to create these on demand (and burn through my token quotas faster), I used Claude to implement a CLI tool, kluster, that makes this as simple as running a single bash command. I can provision Kubernetes clusters locally or in CI in a matter of minutes and I don’t have to wonder whether the clusters will be consistently or correctly configured. There is zero risk that kluster will destroy my hard drive, dump my cluster secrets into pastebin, or find some other novel means of changing my plans for the day.
Constrain the Agent with APIs
For complex use cases that where human-language interfaces are desirable, I believe the fix isn’t giving an agent broader access and control; it’s giving it a narrow, purpose-built API it can call that performs the critical steps. You can build deterministic safeguards and validation directly into the API endpoints, so that a rogue orchestration layer can’t perform undesirable actions. That bounded surface can be tested and reasoned about in advance, giving you a much higher level of confidence that the automation will behave as intended.
Conclusion
You don’t need to find out the hard way; you can use LLMs to aid with the design and implementation of purpose-built automations that can be reasoned about, tested, and trusted. During this moment where it seems the most influential and loudest voices are either advocating increasing privileges and access to LLM based agents or insisting that LLMs have no place in technology, you can choose to take a more measured approach; use coding agents at design time, limit runtime agents to a narrow, purpose-built API, and build deterministic safeguards and validation into the API endpoints.
Appendix: Aggregators Of LLM Usage Gone Wrong
- AI Incident Database — an OECD-linked, continuously updated database that collects and cross-references news coverage of individual AI incidents.
- Vectara’s awesome-agent-failures — a community-curated GitHub repo of AI agent failure case studies with root-cause breakdowns for each.
- Oso’s registry of AI agent failures, exploits, and defenses — covers privilege escalation, prompt injection, and unauthorized deploys by agentic tools.
- Vibe Graveyard — a site specifically tracking “vibe coding” disasters as they happen.
Appendix: Research On LLMs and Cognitive Errors
Foundational
- Deshpande et al., “Anthropomorphization of AI: Opportunities and Risks” (2023) — the foundational framing of how alignment techniques, synthetic voice, and avatars intensify people’s tendency to anthropomorphize AI.
- Placani, “Anthropomorphism in AI: Hype and Fallacy” (2024) — argues anthropomorphism functions as both hype (exaggerating capability) and fallacy (distorting judgments of responsibility and trust).
- Maeda, “Misplaced Capabilities: Evaluating the Risks of Anthropomorphism in Human-AI Interactions” (AIES 2025) — a taxonomy of the design features that “enact” anthropomorphism on the system side and get “projected” onto it by users.
Trust calibration (empirical)
- “Believing Anthropomorphism: Examining the Role of Anthropomorphic Cues on Trust in Large Language Models” (CHI 2024) — n=2,165 study finding a voice interface alone increased both anthropomorphism and unwarranted trust in the accuracy of the answers.
- “The Impact of Revealing Large Language Model Stochasticity on Trust, Reliability, and Anthropomorphization” (2025) — proposes an interface fix (showing multiple sampled responses at once) to recalibrate trust by making the model’s probabilistic nature visible.
- “Presenting Large Language Models as Companions Affects What Mental Capacities People Attribute to Them” (2025) — companion-style framing increases attributed emotional/cognitive capacities, which the authors tie to over-reliance and emotional dependency.
- “The Influence of Mental State Attributions on Trust in Large Language Models” (2025) — preregistered N=410 study separating attributions of consciousness from attributions of intelligence, and testing how each independently moves trust in the model’s advice.
Automation bias / agentic systems
- “‘Are You Sure?’: An Empirical Study of Human Perception Vulnerability in LLM-Driven Agentic Systems” (2026) — models user trust in agents as the joint product of automation bias, source credibility, and anthropomorphism.
- “Fully Autonomous AI Agents Should Not Be Developed” (2025) — position paper citing automation bias and the “ironies of automation” (skill atrophy from over-delegation) as core arguments against full autonomy.
- “Low-rank human-like agents are trusted more and blamed less in human-autonomy teaming” (2024) — finds anthropomorphism makes trust more resistant to erosion after an agent’s mistakes — human-like agents get forgiven faster.
- “AI Awareness” survey (2025), §5.2 “False Anthropomorphism and Over-Trust” — introduces the term “autonomy leakage” for anthropomorphic cues causing people to grant an agent more leeway than it’s warranted.
Applied to coding agents
- “Vibe Coding: Is Human Nature the Ghost in the Machine?” (2025) — documents “sycophancy cascades” in multi-agent coding setups tied to irreversible data loss.
- “Understanding the (In)Security of Vibe-Coded Applications” (2026) — systematic study tracing recurring vulnerability patterns to agent limitations like memory loss and locally-optimized objectives.
- “From ‘AI’ to Probabilistic Automation: How Does Anthropomorphization of Technical Systems Descriptions Influence Trust?” (2024) — argues the vocabulary alone (“AI” vs. “probabilistic automation”) shapes perceived capability independent of any interface design.