Guardrails, Approvals, and Logs for AI Agents That Do Real Work :

What changes when an agent does real work

A chat assistant produces text, and a person decides what to do with it. An agent in a digital workforce takes steps: it looks things up, calls tools, drafts changes, and sometimes makes them. It decides at run time which tool to use next. That creates four risks that ordinary software does not have in the same form. The agent can be redirected by content it reads, which is why prompt injection is first on OWASP's 2026 list of risks for language model applications. It can be given more reach than its job needs, which OWASP calls excessive agency and moved up to third place in the same list. It can loop, spending money and time on work that goes nowhere. And it can produce wrong work that looks competent, which is the hardest failure to catch.

The layers around each agent

A working control design has five layers. None of them depends on the model behaving well.

• Tool registry. Each agent has a written list of the tools it may call, with the permission each needs (read, draft, or write) and a risk level. Calls go through a gateway that checks the list. Anything not on the list is refused and logged.
• Data scope. The agent's identity can reach only the records its task requires, enforced by the system that holds the data, not by the agent's instructions. No administrator credentials, ever.
• Approval gates. Consequential actions are prepared by the agent and held until a person approves them. The rules for what counts as consequential are written down with the department that owns the work.
• Logs. Every request, tool call, result, approval, rejection, and error is recorded with a trace number that ties the steps of one task together.
• Stop and alarms. The owner can pause an agent at once. Alarms fire on unusual patterns, such as a sudden jump in tool calls, repeated failures, or spend approaching its limit.

Designing approvals people will use

Approval gates fail in a predictable way. If everything needs approval, people approve everything without reading it. Put the gate where the consequence is, and make each approval quick to judge.

• Tier the actions. Low-risk work runs and is logged. Medium-risk work runs and a sample is reviewed each week. High-risk work waits for a person.
• Show the approver what matters: the proposed change, the evidence behind it, anything the agent could not verify, and how to undo it.
• Allow three answers, not two: approve, change, or reject. Record which one was chosen and why.
• Treat rejections as information. A pattern of rejections shows where the workflow or the agent needs to change.
• Watch approval times. If a queue sits for days, people will look for a way around it, and the gate becomes the problem.

What the design is built to withstand

The controls map to specific threats. It helps to name them, because each needs a different defense.

• Injected instructions. Content the agent reads is treated as data, not as orders. The tool list and data scope limit what a fooled agent can do, and approval gates catch what gets through.
• Too much reach. Narrow tools and narrow data mean a mistake stays small.
• Runaway loops. Step limits, spending limits, and alarms stop an agent that is going in circles.
• Untrusted tools and connectors. Third-party tools, plugins, and connector servers are reviewed and pinned to known versions before an agent may use them.
• Confident wrong work. A separate reviewing agent checks the work against written acceptance rules, and a person samples the result.

Three common deployment patterns

The same layers apply everywhere, but the emphasis shifts with who the agent serves.

• Back-office agents, such as finance reconciliation or claims preparation: data scope and approval gates carry most of the weight.
• Customer-facing agents, such as support or scheduling: untrusted-content handling, rate limits, and clear handoff to a person carry most of the weight.
• Agents that serve several clients or business units: strict separation of data and memory between them, tested before launch, not assumed.

What the owner receives

When an agent goes into service, its owner should hold six things: the agent's one-page charter, the tool list with permissions, the approval rules, a sample of the log in a readable format, a short runbook for pausing the agent and handling an incident, and a weekly summary of volume, approvals, rejections, errors, and cost. If any of these is missing, the agent is not ready.

How LYFYE runs this

LYFYE runs its own digital workforce with these controls. The agent that does the work is not the agent that reviews it. Completion claims must come with evidence a skeptic could check. Spending limits are enforced before a model call, not after the invoice. Agents stop and ask when a decision is ambiguous or hard to reverse. We build the same structure into client work. The honest limit: these controls reduce risk and make problems visible early. They do not make an agent infallible. We test each one before launch and tell you plainly what risk remains.