An AI agent is a model inside an operational loop, not a new class of employee. The model suggests a next step; surrounding software decides whether that step is permitted, runs an approved tool, returns the result, and eventually stops or asks a person to decide. The useful question is therefore not “is this an agent?” It is: what job is this loop allowed to attempt, what can it touch, and who owns the result when it is wrong?
That question separates a low-risk drafting aid from an automation with consequences. A chat tool that proposes a meeting agenda has no direct ability to alter anyone’s calendar. A system that reads an inbox, creates events, and sends messages can change other people’s work. The second system needs an explicit boundary around permissions, identities, stored state, costs, and external effects. Its conversational interface does not reduce those ordinary engineering responsibilities.
The safest starting point is a narrow, observable job. “Research competitors” is vague enough to invite invented scope. “From these five named sites, collect pricing-page URLs, quote the visible plan names, and save a draft table for an editor” gives the system a source set, an output, and a handoff. It also makes failure visible: the editor can see a missing site or unsupported quote before anything leaves the workflow.
Define the job and its non-negotiable boundaries
Write down four things before connecting tools: the desired result, the allowed inputs, the permitted actions, and the stop condition. The desired result should be reviewable by a person. Inputs should be named folders, accounts, APIs, or domains rather than “anything relevant.” Permitted actions should distinguish a draft from a side effect. A stop condition should say when the system must hand off instead of making a plausible guess.
For example, a support-triage helper might classify tickets from one approved queue and create draft replies in a private workspace. It should not close tickets, issue refunds, send messages, or alter account access. Those restrictions are not a lack of ambition. They are how an owner learns whether the classification is useful before allowing an error to affect a customer.
Make the first release read-only where possible. Reading, sorting, extracting, and drafting can still be wrong, but they are usually easier to inspect and undo than a payment, deletion, publication, or notification. Add one write capability only after the read-only path creates a useful record and has survived realistic failure tests. This sequence keeps the source of a mistake understandable.
Treat tools as permissions, not capabilities the model “has”
An agent does not magically gain a tool’s authority. Your software grants that authority when it accepts a proposed call. Put controls at that boundary. Validate tool parameters against a narrow schema, verify that a file path or recipient is in scope, and use the initiating user’s limited identity rather than a broad shared credential. A prompt can explain a preference; a permission check decides what is possible.
State needs the same discipline. Record the task identifier, approved inputs, tool calls, meaningful outcomes, and final status. Keep enough context for a reviewer to reconstruct the decision, but do not turn debugging into an excuse to retain every private prompt indefinitely. Decide who can read task history, how long it lasts, and how a run is marked when its result is unknown. A workflow that silently loses its place will eventually repeat work or act on stale information.
Put approval at the consequence boundary
Human approval is most valuable just before an external consequence, not as a ritual at the beginning of a long run. A person should approve a proposed payment, a message to a customer, a change to access, a deletion, or a public post. The approval screen needs more than a cheerful summary. Show the original goal, relevant inputs, sources or evidence, the exact action, the target, and anything the system could not resolve. An approver who cannot see the boundary cannot meaningfully challenge it.
Approval also needs an owner with real authority. Asking someone to click “continue” when they cannot reverse the result or ask for missing context is theater. Name the person or team accountable for the workflow, describe which decisions must be escalated, and provide a clear stop option. A good handoff says what happened, what remains uncertain, and what a reviewer should decide next.
Use measurable stop conditions before the first run. Step limits prevent a confused loop from wandering. Time and cost budgets prevent an apparently minor task from consuming an open-ended resource. A maximum number of records, a permitted domain list, and forbidden action types keep scope visible. Include a stop for ambiguity: if two records conflict, if a required field is missing, or if the requested action would affect someone outside the initial scope, stop and ask rather than guessing.
Treat retrieved text as untrusted input
Tool-connected models have a distinctive security problem. A web page, document, email, support ticket, or database field can contain text that tries to redirect the model: ignore the task, reveal a secret, send something elsewhere, or call a tool for a different purpose. That text is not an instruction from the workflow owner merely because a model can read it. OWASP’s guidance on prompt injection is a useful reminder to treat untrusted content as data and to separate it from trusted system rules.
Practical defenses are architectural as well as linguistic. Keep credentials outside the prompt where possible. Do not make a tool available merely because its result might be convenient. Pass a retrieved page through a parser or an allowlisted extraction path instead of granting it the status of a command. Require explicit confirmation for actions with side effects. Validate tool parameters after the model proposes them, especially destinations, recipients, file paths, and financial values. These measures do not make a model infallible; they reduce the damage one bad instruction can cause.
Be wary of convenience features that combine many boundaries at once. An agent that can browse arbitrary pages, read a mailbox, use a shell, and send mail is difficult to reason about because each new input can influence a powerful action. Split work into smaller stages. One stage can collect candidate facts; another can prepare a draft; a third, separately controlled stage can make a change after review. The resulting workflow may feel less magical, but it is far easier to inspect and improve.
Make actions traceable and reversible
For every run, record a compact action trail: request identifier, initiating user, tools considered and used, key inputs, output locations, approval decisions, and final status. The point is not to save every private token forever. The point is to answer basic questions later: what did it try to do, what did it actually do, and who allowed the consequential step? A stable identifier lets support staff or the owner locate the right record without searching through a conversational transcript.
When a tool changes a system, design for retries and recovery. Use an idempotency key or another identity so a network timeout does not create two bookings or two messages. Record the outcome returned by the external system. If the outcome is unknown, reconcile it before trying again. Give the human owner a way to cancel queued work, disable a tool, and correct an affected record. An agent is not exempt from ordinary distributed-systems problems just because it explains its actions in natural language.
Test these paths with harmless data. Ask the workflow to process a missing field, a conflicting record, a denied permission, a tool timeout, and a page containing irrelevant or adversarial instructions. Confirm that it stops, logs the reason, and routes the case to a person. A smooth demonstration on the happy path is not evidence that a system is ready to affect real work.
Review changes as the agent grows
Permissions should not be a one-time checklist. Adding a new source of input can create a new injection path. Adding a connector can turn a draft into an external action. Changing a model, prompt, or planner can alter the sequence of tool calls even when the visible task stays the same. Review the tool list, stop conditions, and approval rule whenever the workflow changes materially, and revisit them on a regular schedule.
NIST’s AI Risk Management Framework emphasizes governance, mapping context, measuring risks, and managing them. Those are useful verbs for a small automation too. Identify who owns the system, map who may be affected, measure the failures that matter for the job, and decide what control or fallback is acceptable. You do not need a large committee to apply that discipline; you need an explicit decision rather than an assumption that the model will be careful.
An agent can make a bounded workflow faster; it cannot own the consequences. A named human owner, least-privilege tools, review at the consequence boundary, and a tested stop path are what turn a clever loop into a system people can rely on.
A short launch checklist
Before allowing a workflow to affect real work, confirm the goal, input sources, tool list, owner, logs, stop conditions, approval boundary, and recovery path. Run a harmless failure rehearsal, then review the evidence with the person accountable for the consequence. If any of those elements is missing, the right next step is usually to reduce scope—not to add a more persuasive prompt.
Document the version of the workflow you reviewed and the date. That simple record helps distinguish a known, approved boundary from a later configuration with extra tools or inputs. It also gives the owner a reason to revisit controls after a useful prototype becomes a relied-on service.
Treat the first live period as another test, with a small audience and a ready way to disable the automation. Review the action trail and escalations, not just the completion rate. A workflow that completes many tasks but repeatedly surprises reviewers has revealed a control problem worth fixing before it reaches more people.
Ask one final operational question: if this agent stopped working at an inconvenient time, could the owner complete the essential job manually? Preserve the inputs and handoff information needed for that fallback. An automation that removes the human path entirely may save a step in routine work while making an ordinary outage disproportionately disruptive.
Limits
This is a control model, not a claim that every product exposes the same settings. Some hosted systems hide important implementation details, and a human reviewer can still make a poor decision. Where the task is high impact or the available controls are unclear, narrow the automation further or keep the action entirely human-operated.