Demonstrate permission, malformed-input, repetition, and injection handling.
You will separate model, tools, state, loop, and permissions; design approval gates; and test an agent without unnecessary authority.
Before you begin
Understand that a language model proposes text. Think of one tool, such as reading a file or creating a calendar item, that software could expose.
Model plus loop
An AI agent usually combines a model with a loop that observes state, chooses an action, uses a tool, and evaluates the result. Tools may read files, call APIs, search data, or run code. Memory can be as simple as a task log; it is not human memory or guaranteed understanding.
Capability comes from permissions
A text model cannot modify a calendar by itself. An application gives it a calendar tool and credentials. The safest design grants only the minimum operations and scope required. Reading a document, drafting an email, and sending it are separate permissions with different consequences.
Approval and recovery
Require human approval before payments, public messages, deletion, credential changes, or other high-impact actions. Log tool calls, set limits, validate targets, and keep changes recoverable. A stop condition is a feature: the agent should report uncertainty instead of improvising authority.
When not to use an agent
A deterministic script is usually better for a stable, well-defined transformation. Use an agent when interpretation and flexible planning add value, and surround that flexibility with tests and policy. More autonomy does not automatically mean a better product.
The parts of an agent
An agent combines a model with instructions, tools, state or memory, and a loop that observes results and selects another step. The model may propose a structured tool call; application code validates and executes it. Memory may be temporary context, saved task state, or a database. None creates permission or judgment. Reliability depends on surrounding software, validation, and stopping conditions.
Tools define the risk boundary
A text-only model can suggest something harmful. A tool-enabled system may send it, overwrite a file, spend money, or expose data. Give tools narrow inputs and permissions, separate read from write, and validate targets in ordinary code. Require approval for external messages, purchases, publishing, access changes, destructive operations, and other consequential steps. Do not hide a broad shell behind a harmless tool name.
A controlled project-planning example
A safe starter agent reads a user-selected brief, proposes milestones, and saves a draft in a new file. It cannot email, modify the brief, or change calendars. The user reviews before follow-up tools become available. Logs record input source, model version, proposed and approved calls, and outputs without secrets. A step limit stops loops. The system remains useful while authority and recovery stay visible.
Test failure and prompt injection
Test denied permissions, malformed arguments, unavailable services, repeated actions, stale state, and instructions embedded in documents that try to override the task. Treat retrieved content as data, not authority. Reject unknown tools and arguments, make writes idempotent where practical, and stop when required information is missing. Evaluate the full loop, not only final prose. A good agent fails visibly and recoverably.
Evaluate agent permission models
Decision: Prefer software that displays tool calls, constrains scope, and pauses before consequential actions.
Relevant options: Cline and Roo Code document editor agents; Claude Code and Aider operate in terminals. Model quality never replaces command, network, file, and credential boundaries.
Worked example: Rename one function in a disposable repository while approving commands and denying network access.
Failure mode: An agent can edit generated files, read unrelated secrets, issue a destructive command, or retry indefinitely.
Validation: Compare final changes with scope, inspect logs, and prove rollback from a clean checkpoint.
Useful next step: Write file and command allow-lists plus a stop condition first.
Official sources checked 2026-10-24: Cline · Roo Code · Claude Code · Aider. Product availability, support, terms, pricing, and licenses can change. These are vendor or project sources; no independent benchmark is claimed.
Original permission-gate fixture
The fixture permits only read_note with a validated identifier. It denies an unknown tool, malformed arguments, a repeated request ID, and an instruction embedded in note text.
Tests passed with Node 26.8.1 on 2026-10-27. This deterministic fixture has no model, network, or external side effect.
Authoritative references
Reference scope checked 2026-10-27. These sources support the concepts and risk controls; product-specific behavior still requires the nearby vendor documentation and a dated test.
Your next step
Run the fixture and add one denied case before connecting a real model or external tool.
Editorial provenance
Nyfir Studios is the publisher and editorially responsible organization. AI tools assisted with drafting and structured review for this candidate; factual claims, test labels, links, and retained evidence require human review before deployment. No named employee, credential, or unrecorded hands-on result is implied.