
What Is an AI Agent? Permissions and Approval Gates
OpenClaw set the agent conversation on fire. How agents differ from prompting and vibe coding (state, tools, loop), and the permission and verification problems that come with autonomy, with code.
Autonomous AI agents, as popularized by OpenClaw (formerly Moltbot): prompts vs. agents, the risks of broad permissions, and why you need human approval gates.
An agent is the stage where the model, equipped with state, tools, and a loop, repeats actions on its own without a person. Through Part 2, a person ran the loop. We built, ran, and fixed. Agents hand that loop to the model. The model uses tools on its own, looks at the results, and decides its next action.
> Part 3 of the "Evolution of LLM use" series. ① Prompting · ② Vibe coding · ③ Agents · ④ Harness engineering · ⑤ Open models.
OpenClaw popularized autonomous agents
What popularized this concept almost overnight was OpenClaw in early 2026. It's an open-source autonomous agent built by Austrian developer Peter Steinberger, which went from Clawdbot → Moltbot → OpenClaw (the interim rename was due to an Anthropic trademark issue) and passed 140,000 GitHub stars [1]. Using messengers like Telegram and Slack as its interface, it directly runs shell commands, the browser, files, and the calendar. All from a single text message [2].

How agents differ from prompting and vibe coding
Agents tackle the three limits of the earlier stages (no state, no tools, no verification) head on.
- State: An agent carries a memory of what it has done so far.
- Tools: It can take real actions like running code, reading files, and searching.
- Loop: It doesn't answer once and stop; it repeatedly looks at results and decides the next action.
Put the three stages side by side and the difference is clearer.
| Stage | State (memory) | Tool execution | Loop |
|---|---|---|---|
| Prompting | None | None | None; one-off response |
| Vibe coding | Only within a session | Up to code generation | A person runs it |
| Agents | Persisted | Direct execution (shell, files, APIs) | The model runs it on its own |
So an agent is essentially model + tools + loop + memory. The model is just one part of the brain; what makes an agent an agent is the loop around it. The simplest form looks like this.
# The essence of an agent = a perceive -> plan -> act -> observe loop
state = memory.load()
while not done:
action = model.decide(state, tools) # plan: decide the next action
if action.is_risky: # if risky, go to a person
if not human_approve(action): # HITL gate
continue
result = run(action) # act: actually run the tool
state = memory.update(state, action, result) # observe: fold the result into state
done = model.is_complete(state)
If a prompt was a single model.decide() call, an agent puts it inside a while loop and attaches tools and memory.
The price of autonomy: permissions and verification
This is why OpenClaw was both a sensation and a controversy. Accessing the shell, email, calendar, and messengers requires broad permissions, and those permissions are the risk. A misconfigured or exposed agent leads straight to security and privacy incidents. That's why security researchers raised concerns about OpenClaw's permission model [1].
The root of the problem is autonomy itself. The moment you hand the loop to the model, the model will also go ahead and execute the wrong actions. So production agents need two things. First, a human approval gate (HITL) in front of risky actions (payments, deletions, secrets, external publishing). Second, loop caps and verification to prevent runaways. That's where human_approve and is_risky sit in the code above. When we run agents ourselves, we make sure a person always stops the process before financial transactions, irreversible deletions, and secret writes.
In short
Agents used a loop to get past the wall that prompting and vibe coding couldn't (state, tools, verification). The model uses tools on its own and iterates while watching results. OpenClaw showed the public that possibility, and at the same time left us with the homework that autonomy needs guardrails.
That very homework, running agents safely and at consistent quality, calls for the next stage: harness engineering, designing tools, hooks, guardrails, and verification around the model.
For related reading, see What is vibe coding? Its limits and the AI code verification loop, How to write good prompts: pin down AI output with context design, and 5 agentic workflow patterns: from prompt chaining to orchestrators.
You can continue with The AI Marketing OS TRAIL Labs Builds: A System, Not Tools and Open-Weight vs. API Models: Own a Domain Model with Hermes.
Frequently asked questions
How are agents different from automation scripts (RPA)?
Automation scripts move only by fixed rules, while with an agent the model looks at the situation and decides its next action on its own. When the rules change, a script has to be rewritten, but an agent makes a different judgment within the same loop.
What safeguards should come first when adopting agents?
The minimum is a human approval gate (HITL) in front of hard-to-reverse actions like payments, deletions, and secret access, and a cap so the loop can't repeat forever.
Is OpenClaw safe to use right now?
Security researchers have raised concerns about its broad permission model, so minimize permissions for sensitive access like the shell, email, and calendar, and always put an approval step in front of risky actions.
References
Summary
- An agent is the stage where the model gets state (memory), tools, and a loop so it repeats actions on its own.
- OpenClaw popularized the concept but also exposed the problem that broad permissions mean security and privacy risk.
- Production agents absolutely need a human approval gate (HITL) in front of risky actions, plus loop caps and verification.
- The next stage that tackles this is harness engineering, which designs everything around the model.
Why TRAIL Labs works this way
How a researcher-founder grounds measurement and recommendations, and how the three products relate to the company, is laid out on the about page, and how we work day to day is written up separately.
More posts

TRAIL Labs joins the Google for Startups Cloud Program
TRAIL Labs has joined the Google for Startups Cloud Program, gaining cloud credits and support to run our AI-search measurement and content engine at scale.

TRAIL Labs has joined the NVIDIA Inception program
TRAIL Labs has joined the NVIDIA Inception program, gaining compute, technical resources, and a network to grow our AI-search measurement and content engine.

Is AI search visibility enough? Why we changed our question
AI search visibility is countable, but more of it doesn't mean your accurate information reached the answer. What measurement and three papers taught us.
Keep reading on this topic
- Defending Against RAG Hallucinations: Types and LimitsRAG retrieves outside documents to ground answers, yet hallucinations still arise in retrieval and generation. Types, defenses, and limits of automated checks.
- Design principles for a GEO data AI agentDesign principles for a GEO data AI agent: text parsing vs. structured tool calls, blocking irreversible actions, and why skipping evals is risky.
- Open-Weight vs. API Models: Own a Domain Model with HermesOwn the model instead of renting it: why open weights, open vs. API models, Nous Research Hermes 4.3, its function-calling standard, and the data flywheel.
This post is part of the TRAIL Labs category, which collects all 19 posts on the topic. See all posts in TRAIL Labs