AI Agents Inside Your Systems: What an Agent May Do Alone, What a Person Must Approve, and How to Start Without Losing Control

An AI agent is a language model that can ask your software to run functions, meaning actions such as looking up a payment, updating a ticket or issuing a refund. The model only makes the request. Your systems decide whether to carry it out, and that is where you keep control. Start with one narrow task, where the agent reads data and prepares drafts on its own. A named person approves anything that moves money, changes a client's record or leaves the company.

What is an AI agent, in plain words?

A language model, the kind of AI behind ChatGPT, produces text. An agent is a language model connected to functions in your systems, so its output can be an action as well as an answer.

Anthropic's documentation for its Claude models says: “Tool use (also called function calling) lets Claude call functions that you define or that Anthropic provides.” For the functions you define, the model “returns a structured call that your application runs”. It writes the request, and your software runs it or refuses. All sources in this article were opened on 2 November 2026.

An agent repeats this in a loop. It calls a function, reads the result and chooses the next step until the task is done. A 2024 post on Anthropic's engineering blog describes agents as “typically just LLMs using tools based on environmental feedback in a loop.” LLM is short for large language model, and tools are the functions it can call.

So an agent can do only what its functions allow. The list of functions is its job description, and it is the first document to ask for.

Why does it matter whether the agent reads data or changes it?

Because reading changes nothing. If the agent pulls a client's last five payments and gets one wrong, the result is a wrong draft, which a person can catch.

Writing changes something outside the model: a refund is paid or an email reaches a client. Some of these changes cannot be undone.

OpenAI's guide to building agents suggests rating each function low, medium or high risk “based on factors like read-only vs. write access, reversibility, required account permissions, and financial impact.” Reading stays low risk only while the agent cannot send what it read anywhere. The section on prompt injection, a trick that plants instructions in an email or document, shows why.

Which actions can the agent take alone, and which need a person?

Sort every function into one of three groups:

• Agent alone: reading data, searching documents, tagging, and writing drafts that stay inside your systems until someone uses them
• Agent proposes, a person approves: anything that moves money, changes a client's record or status, or sends a message outside the company
• Never: changes to access rights, limits or bank details, and decisions your regulator expects a named person to take

Four questions decide the group for most functions:

• Can the action be undone, and by whom?
• Does it move money or change what a client owes?
• Will a client, a partner or a regulator see the result?
• Does a law, a licence condition or your own policy say a person must decide?

OpenAI's guide gives the same advice for the middle group: “Actions that are sensitive, irreversible, or have high stakes should trigger human oversight until confidence in the agent's reliability grows.” Its examples include “canceling user orders, authorizing large refunds, or making payments.”

The OWASP Top 10 for LLM Applications 2025, a list of risks published by the OWASP security project, has an entry called excessive agency. It covers the damage an agent can do when it has more functions, rights or freedom than its task needs. One of the controls it lists is to “require a human to approve high-impact actions before they are taken.”

What does this look like in support, onboarding, payments and reporting?

In each area, the agent reads and drafts, and a person keeps the decisions. Your own list depends on your systems and on what your regulator expects.

• Support: the agent tags tickets and drafts replies. A person approves every reply at first, and refunds and fee waivers always need approval. The agent never changes a client's email or phone number, since whoever controls them can reset the client's login
• Onboarding: the agent checks documents for missing fields and summarises them for the analyst. A change to a risk rating waits for approval, and accepting a client stays with a person
• Payments: the agent matches bank statement lines to invoices and flags gaps. Releasing a held payment waits for approval, and a payee's bank details are never the agent's to change
• Reporting: the agent drafts the monthly report with the source of each number. A person approves anything sent to a client, the board or a regulator

Where should the approval step sit?

Put the approval in the software that runs the function, not only in the prompt, which is the set of instructions the model receives. A model can ignore a line in its prompt or be talked out of it. A refund function that will not run without an approver's click cannot be talked out of anything.

OWASP's guidance agrees: “Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.”

A useful approval screen shows the approver:

• The action, the record it changes and the amount
• The record before and after the change
• The evidence the agent used, such as the ticket or the statement line
• A required reason whenever the approver rejects

If every proposal is approved within seconds, people have stopped checking. The EU AI Act has a name for this: automation bias. Its article on human oversight says the people overseeing a high-risk system must be able to stay aware of “the possible tendency of automatically relying or over-relying on the output”. Re-check a sample of approved actions every week.

What rights should the agent's account have?

The agent's account should allow the functions on its list and nothing else. Give each agent its own account in each system it touches, never an administrator account or an employee's login. Set those rights in the system itself, where the model cannot change them. Passwords and keys stay in your software, out of the model's sight.

OWASP's example is an agent that recommends products and “might only need read access to a 'products' table”. It also warns against open-ended functions, such as running any command on a server, and prefers narrow functions that each do one thing.

When the agent works for one employee, it should act “in the context of that specific user, and with the minimum privileges necessary”, in OWASP's words. It then cannot see or do more than that person.

What is prompt injection, and why does it matter more for agents?

Prompt injection means planting instructions in text the agent reads, such as an email, a ticket or an uploaded document. The model may follow them as if they came from you. The instructions can be hidden from a human reader, and with an agent they can turn into actions. OWASP ranks prompt injection first in its 2025 list and says “it is unclear if there are fool-proof methods of prevention for prompt injection.”

OWASP's entry on excessive agency describes an assistant that reads a mailbox to summarise incoming email. The add-on it uses can also send email. A crafted email tricks it into searching the inbox for sensitive information and forwarding it to the attacker.

OWASP's fixes start with a function that can only read mail and read-only access to the mailbox. A person must also “manually review and hit 'send' on every mail drafted by the LLM extension.” Since prompt injection cannot be ruled out, plan for an agent that has been tricked, and keep the damage it can do small.

What should we log, and how do we undo a mistake?

Log every function call. Each entry shows the agent, the function and its inputs, the result, the text that led to the call, the model and prompt version, and who approved it and when. Someone outside the build team should be able to read the log and tell what happened to a given client.

OWASP notes that logging and rate limits will not prevent excessive agency, “but can limit the level of damage caused”. A rate limit caps how many actions of one kind the agent can take in a given time, so a run of bad actions stops early.

Before launch, write down how each function that changes data is undone, and who does it. Prefer functions that create something pending, such as a refund waiting in a queue. A pending item can be deleted, while a sent payment is hard to take back. Keep a switch that turns the agent's functions off at once, without a software release, and test it before go-live.

Does the law say a person must approve?

In the EU, the AI Act sets rules for human oversight of AI systems it classes as high-risk. Those rules are in Article 14, and Annex III lists the high-risk uses. The list includes assessing the creditworthiness of individuals or setting their credit score, though systems that detect financial fraud are excluded. It also includes risk assessment and pricing for individuals in life and health insurance. The European Commission's AI Act Service Desk gives 2 December 2027 as the date the rules for high-risk systems in Annex III apply. That date reflects changes made by the Digital Omnibus on AI. Dates like this can move, so check the current timeline before you plan around it.

Article 14 says oversight measures “shall be commensurate with the risks, level of autonomy and context of use” of the system. The people overseeing it must be able “to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output”. They must also be able to stop it with “a ‘stop’ button or a similar procedure”.

These rules apply only to the high-risk systems the Act lists, and many agents in support and operations will not be among them. The same controls still make sense for those agents. Whether your system falls under the rules is a question for your lawyers. This article is not legal advice and covers only EU rules.

How do we start without losing control?

Start by asking whether the task needs an agent at all. Anthropic's engineering post recommends “finding the simplest solution possible, and only increasing complexity when needed”, and adds: “This might mean not building agentic systems at all.” For many tasks, a single request to the model or a fixed sequence of steps does the job. A fixed sequence also behaves more predictably than an agent that picks its own steps.

Pick one workflow with many cases a week, clear rules and mistakes that are cheap to fix, such as sorting support tickets and drafting replies. Then move in stages:

• Measure the workflow as it runs today: time per case, the share of cases redone, and the weekly backlog
• Run the agent in shadow mode on real cases. It proposes, people work as before, and you compare the two
• Switch to approval mode, where a person approves each action, and record how often approvers edit or reject
• Let the agent act alone only on the action types with the fewest corrections, and keep checking a weekly sample

Agree in advance which numbers move the agent to the next stage, and who decides. OpenAI's guide ends with: “Start small, validate with real users, and grow capabilities over time.” Anthropic's post recommends “extensive testing in sandboxed environments”, meaning a copy of your systems where mistakes cost nothing.

What should we check before the agent goes live?

• Every function is in one of the three groups and has a named owner on your side
• Someone tried a forbidden action with the agent's account in each system and saw it fail
• Tickets and documents with planted instructions went through the agent, and nothing happened outside what the groups allow
• For any client, the log shows what the agent did and who approved it
• A new model version goes live only after the same tests run again

Who owns the code, the prompts and the logs?

Your company should, and the contract should say so. The code is only part of the agent. The prompts, the list of functions, the approval rules and the test cases decide how it behaves. Name all of them as deliverables, kept on storage your company controls.

The logs hold client data, so they need the same access rules and retention period as the records they describe. If the model runs at an outside provider, ask whether that provider stores what the agent sends it, and for how long.

What should we ask a firm that would build it?

• Can we see every function the agent will call, with the group each one is in?
• Where are approvals enforced: in our systems, in your code or only in the prompt?
• Which account does the agent use in each system, and how did you test that it cannot do more?
• How do you test for prompt injection, and what happens when a test succeeds?
• Can our compliance team read the log without your help?
• How is each action undone, and how fast can we switch the agent off?
• What do we own at the end: code, prompts, function definitions, test cases and logs?

Where does amBrain fit?

amBrain uses agents in its own product. Its line on that product reads: “Our own product, shyash.ai, runs on AI agents that research, write, check and measure from one shared memory of company facts. A person approves everything that goes out.”

The only client project with a language model that amBrain describes in public is this one: “We have taken an LLM integration to production inside a client's FinTech perimeter: extracting and normalising unstructured broker and venue notices — corporate actions, instrument and margin changes — into structured records the trading system consumes.”

This article is not a case study and describes no client work beyond the line above. That line says nothing about agents or approvals, and the article does not say that amBrain builds agent systems for clients. The examples from support, onboarding, payments and reporting are general, not taken from amBrain work.

The companies and organisations named here are cited from their published pages. The article claims no relationship between amBrain and any of them and gives no amBrain prices or timelines.

amBrain has been building software since 2019. It works in three formats: full delivery, a dedicated team, or engineers embedded in your team. Its line on ownership is “The client keeps full ownership of the product and the code, except our reusable components.” The questions above apply to any firm you consider.