Agents and approvals
Agents and approvals
An agent is an AI assistant that does things in MaxSuite by calling the same tools the modules offer, such as tasks.create or domains.expiring. Before any tool runs, the approval check decides whether it runs straight away, waits for a person, or is refused.
How an agent acts
An agent is defined on Agents → Agents: a name, a system prompt that says how it behaves, an AI connection and model, and optionally the modules it may use. See Agents.
An agent always acts for a person, never on its own account:
- in Chat, or in a linked Telegram chat, it acts for whoever is talking to it;
- on a schedule, it acts for the person who set the schedule;
- in a pipeline, it carries on after each gate as the person who decided that gate.
The tools an agent is offered are narrowed several times, and every step can only narrow:
- what the person it acts for may call, by their permissions;
- what the workspace has (installed, entitled, enabled);
- the agent's own list of modules, if it has one (empty means everything the person can reach);
- its capability packs, if it has any;
- read-only tools only, when it runs with the Plan execution profile.
So an agent can never do more than the person behind it. Giving an agent a narrow list of modules is how you make it do less.
The approval check
Every tool call passes the approval check when the Approvals module is installed: calls from agents, from connected apps such as Claude, from API keys, and from the screens that call tools for you, such as the dashboard's quick add. Clicking a button on an ordinary screen is not a tool call; your permissions alone decide it.
The check gives one of three answers:
- allow: the tool runs now;
- ask: a request goes to a person, and the tool waits;
- deny: the tool is refused, with the reason.
Action classes
Every tool is classed by what it does, when it is written:
| Class | What it means | Default when no rule says otherwise |
|---|---|---|
read | Looks, changes nothing | allow |
write | Changes something inside MaxSuite | ask |
destructive | Removes or overwrites something, or grants access that cannot be taken back | ask |
external | Reaches outside MaxSuite: sends a message, changes DNS, publishes | ask |
spend | Commits money | ask, always |
So, out of the box, reads run and everything else asks.
Rules
Agents → Approvals → Rules holds the standing answers. A rule says allow, ask or deny, and is about either:
- a kind of action, such as every
externalact; or - one tool, such as
tasks.create, optionally only when some of its arguments have given values (for example only for one project).
Each rule applies to everyone, to one agent, or to you alone, and can have an expiry date. When several rules could apply, the most specific wins:
- your own rules first, then the agent's, then everyone's;
- within those, a tool rule whose conditions match, then a tool rule without conditions, then a kind-of-action rule;
- if two are equally specific, the stricter wins: deny, then ask, then allow;
- with no rule at all, the class default above.
Spending always asks
No rule can let a tool spend money without a person. A rule that would allow a spend tool, or any change in a module that handles money, is refused when you try to save it. One saved before that rule existed is listed as "Not honoured: spending always asks." This holds for every caller: agents, keys and connected apps alike.
Sensitive modules
Some modules declare that they touch something sensitive:
| Sensitivity | Meaning | Modules on main |
|---|---|---|
money | It moves or records money | Accounts, AI spend, Costs, Extraction, Gateways, Invoices, Books, Bills, Vaults |
auth | It decides who can sign in or what they may do | People, Connected apps |
secrets | It holds credentials | Connectors, Coolify, DigitalOcean |
Each module page says whether its module is sensitive.
When an agent does anything other than read in a sensitive module, it goes to a person, even where a rule says allow. The request says why: "Asked because … is marked sensitive". A tool nobody can place in a module is asked about too.
One exception: a rule that names one exact tool, such as one created with Always allow, lets that tool through in an auth or secrets module. It never does for money or for a spend tool.
This forced escalation is for agents acting on their own judgement. A person, or an API key somebody set up and answers for, follows the rules and class defaults only. That is why keys should be narrow. See API keys and MCP access.
Two more reasons an agent asks
- It has read outside content. Once a run has read a mail, a web page, a scraped site or another server's answer, every act that is not a read asks a person for the rest of that run, whatever the rules allow. The request says what it read and when, because a stranger's text may now be steering it.
- It wrote the tool itself. A tool an agent defined must be approved by a person on its first call.
Answering a request
Requests wait on Agents → Approvals → Requests, and in a linked Telegram chat as buttons. Each shows the tool, what it would do and why it asked.
- Approve lets this one call run.
- Always allow approves it and adds a rule so this tool stops asking for this agent. Always allow, only when… adds the rule only for the argument values you tick. Neither appears where a rule could not be honoured, such as spending.
- Deny refuses it. You must give a reason before Decline sends it, so the agent has something to act on.
A paused agent run carries on by itself once approved, as the person who started it. A key or a connected app calls the tool again to use the approval. A request not answered within 24 hours expires.
Seeing requests needs approvals:read, deciding them approvals:decide, and setting rules approvals:manage. Only whoever asked, people who may decide, and administrators see what a request would do; others see that it exists.