An AI agent is a language model that is allowed to operate tools. The chat window many people know from everyday use only produces text. An agent can do things beyond that: read a ticket, change a file, run a query. It receives a task, plans steps, calls tools and evaluates the result, until the task is done or it gets stuck.
The difference is the same as between an adviser on the phone and an employee with a set of keys. One says what should be done. The other does it. That is why the most important question about agents is not how clever the model is, but which keys it gets.
This article explains what separates agents from assistants, where they get their knowledge from and why the permission model comes before the use case.
Assistant, agent, automation: different roles
The terms describe different characteristics and can overlap [5].
- An assistant supports people: it reads, summarises and drafts. Depending on its integrations, it can also use tools; the permission model determines which actions it executes itself.
- An agent acts. It executes steps itself, within the tools and permissions it has been given.
- An automation executes defined workflows, for example on a schedule or in response to an event. It may use AI, but does not have to. Benefit and risk depend on the workflow and its permissions.
Start with limited permissions and clear approvals. Expand autonomy only on the basis of evaluated results.
Where the agent gets its context
A language model knows nothing about your company. Everything it is supposed to say about your tickets, contracts or systems has to be handed to it at runtime.
There are two common ways to do that. In the first, an upstream system finds the relevant documents and presents them to the model together with the question; the technique is called retrieval augmented generation, RAG for short. In the second, the model gets direct, scoped access to a system through a defined interface. An open standard for this is the Model Context Protocol (MCP): it describes how an agent finds tools, calls them and receives their results [1].
For practice this means: the connection is infrastructure. It is built, permissioned and logged like any other interface in the organisation. How to secure MCP connections is covered in the article Securing MCP.
What changes once it is allowed to write
Even a read-only agent can disclose confidential information and cause substantial harm. Write permissions introduce additional risks: an agent can close tickets, submit code or grant permissions [2].
An example. A team gives its agent read access to the ticket system and write access to the repository, to speed up small fixes. Then someone outside creates a ticket whose text contains an instruction. The model may confuse an instruction in the text it reads with its operator's task. The path from the crafted ticket to the executed change is short if no approval stage sits in between. The most effective countermeasure is not a better prompt, but a smaller permission [2].
The permission model comes before the use case
The tempting order is: build the useful case first, secure it later. The one that holds up is the reverse, for a simple reason: permissions once granted are rarely collected again, because by then something depends on them.
Four questions pin down the model before the first case is built: under which identity does the agent act, and can it be told apart from people? Which tools does it get, and which explicitly not? Which of its actions need a human approval? And where can you read afterwards what it did?
Who is responsible for the actions
Responsibilities for operation must be assigned within the organisation. The NIST AI RMF describes clear roles and responsibilities for managing AI risks. It does not determine who is legally liable in an individual case [3].
In practice this means: for every agent action, someone must be nameable who answers for it. Three building blocks do this together: its own identity (the action is attributable to the agent), the approval stage (a person signed off the critical action) and the log (the sequence of events can be reconstructed). If one of the three is missing, the answer to an incident is speculation.
Example: an agent in the ticket system
A typical case. A support team lets an agent pre-sort incoming tickets: assign a category, spot duplicates, suggest a reply. The agent has read access to tickets and its own identity. It does not send the suggested reply itself; it appears as a draft a person approves.
After a while, the log shows which suggestions are approved unchanged and which are not. Only on this basis does the team decide whether the agent may answer certain ticket classes itself. The decision is based on evaluated results and the risk of the action concerned.
An agent is a tool bearer. Its usefulness is determined by the model; its damage radius is determined by you: through identity, tool list, approval stages and log.
What you can decide afterwards
- Which tasks your first use case handles and how much autonomy it needs.
- Which four answers your permission model has to give before the first connection is built.
- What you will use to decide when an agent gets more autonomy.
Frequently asked questions
Is an agent the same as an internal GPT?
Not automatically. An internal GPT can answer questions based on internal documents. Whether it also takes action depends on its connected tools and approvals. The operating models available for this are covered in Internal AI assistants.
How do you secure the interfaces the agent talks through?
Each interface must verify the caller's identity, restrict permissions for actions and records, and validate input. An agent receives only the access its task requires. Securing MCP explains how to protect its connection. Our API expertise covers architecture, security testing and implementing these controls.
Does every agent need a human approval?
Not every action, but every class of action needs a conscious decision about it. Reading can be free, writing can require a draft stage, deleting can be off limits entirely. What matters is that the classification is made before operation, not during it.
Sources
- Model Context Protocol: Introduction modelcontextprotocol.io
- OWASP Top 10 for LLM Applications OWASP GenAI Security Project
- AI Risk Management Framework NIST
- Künstliche Intelligenz: Informationen und Empfehlungen BSI, Germany's federal cyber security authority
- Building effective agents Anthropic