Insights
Safe AI automation for business: an agent should not have more power than the task requires
An AI agent can retrieve data, prepare a change, call an API and complete work that previously required several screens and manual steps. That is useful. The same mechanism also lets a poorly designed agent execute a wrong action faster.
Our starting rule is simple: a model may propose and execute actions only inside boundaries that the system can enforce independently of the model. The larger the consequence of an operation, the less we should rely on the model's own judgement as the control.
That leads to four practical questions:
- Which tools and data does the agent actually need?
- Which actions may it execute autonomously, and which need human approval?
- How do we verify what the agent really changed, rather than what it said in chat?
- How can we reconstruct the decision weeks or months later without stitching together five different logs?
This part of the Brillnet site documents the patterns we use when working with APIs, MCP, automation and systems where an action may later need to be evidenced. These are engineering patterns, not a certification or a universal design for every agentic system.
Start with the consequence, not with how technical the action looks
A complex read-only report may be low risk. A single DELETE call may remove data. One enable operation may start spending money.
A useful starting classification is:
| Action class | Example | Default control |
|---|---|---|
| Low-risk read | retrieve status, report or approved resources | agent may execute within a scoped read boundary |
| Prepare a change | draft configuration, plan or content | agent prepares; a person sees the result before publication |
| Reversible write | change a setting that can be rolled back quickly | explicit write scope, input validation, outcome record |
| External or financial action | publish, send a message, enable a campaign, increase spend | explicit human approval before execution |
| Destructive or security-sensitive action | delete data, change access, rotate security settings | separate scope, preview, approval and independent checks where practical |
This is not a mathematical risk model. It is a way to identify where a model error becomes a business error or a security incident.
Four layers we keep separate
1. The model can reason, but it does not grant itself permissions
A model may choose from tools it has been given. It should not expand that set itself or decide that it needs administrator privileges “just this once”.
Authorization should come from operator identity, the agent's role, the specific tool and the target resource. The authorization decision belongs to the surrounding system, not to text generated by the model.
Read: Least privilege for AI agents
2. High-impact actions pass through an approval gate
“Human in the loop” should not mean a person clicks OK for every read. That quickly turns control into ceremony.
Approval is useful when an operation spends money, communicates externally, changes access, deletes data or creates an outcome that is difficult to reverse. Before approving, the person should be able to see what will change, where, why and what the likely consequence is.
Read: When should an AI agent require human approval?
3. The tool layer enforces policy independently of the prompt
A prompt is part of steering model behaviour. It is not a sufficient security mechanism for writes, spend or administrative operations.
In our internal Brillnet Ads MCP tool, restrictions are enforced at the gateway. The operation is classified, scopes are checked and safe defaults prevent an omitted parameter from silently turning into a live action. For example, a newly created campaign stays PAUSED when no status is explicitly provided. Enabling spend requires an operational permission and explicit confirmation.
For us, that is a more useful control pattern than simply writing a stricter system prompt.
Read: MCP and AI agents — designing safer tools
4. Audit records describe the operation without logging everything
A useful audit trail can answer:
- who or which agent initiated the action;
- which tool was called;
- which resource was targeted;
- what authorization decision was made;
- whether human approval was required and who approved it;
- what the provider returned;
- what resulting state was observed after the write.
That does not mean storing secrets, access tokens, authorization headers or complete raw datasets “just in case”. A log that becomes a second store of sensitive information solves one problem by creating another.
Read: AI agent audit trails — what to log and what not to log
What we check before connecting an agent to a new system
A short design checklist:
- Purpose: does the agent have a defined job, or broad access “to everything”?
- Identity: can each call be attributed to the operator, agent and task/session?
- Tools: can the agent see only the functions required for its job?
- Resources: can access be limited to a specific account, tenant, project, directory or record set?
- Read versus write: are read and write permissions separate?
- High-risk operations: do they require a separate scope or approval?
- Validation: does the gateway validate structure, resource identifiers and operation class before calling the target system?
- Safe defaults: does an omitted parameter produce a safe state rather than enable an action?
- Retry behaviour: can an automatic retry execute the same write twice? If so, add idempotency or an equivalent control.
- Resulting state: can the system read and display the target resource after a write?
- Audit: can the decision and result be recorded without secrets and unnecessary personal data?
- Interrupt: can a person stop the workflow before subsequent steps increase the impact?
If several answers are “we don't know”, the answer is not another prompt. The boundary between the model and the target system needs design work.
Example: why retry behaviour and read-after-write matter
Suppose an agent creates a resource through an API. It sends the request, but the response is lost in transit. The agent does not know whether the resource was created. A simple retry may create a duplicate.
For write operations, we therefore use an idempotency identifier and read the resulting state after the change. A network problem is less likely to become a duplicate action, and the operator sees the state of the target system rather than trusting a “done” message from the agent.
This looks like a small implementation detail until the operation affects money, message recipients or security configuration. Then it is no longer small.
What we are not claiming
- There is no single autonomy level that fits every process.
- MCP by itself does not make a tool secure.
- Logging by itself is not an audit trail if events cannot be linked to a decision and outcome.
- A human approval step does not repair weak access control.
- These patterns do not replace threat modelling, security testing or legal analysis for a specific deployment.
Reference sources
- OWASP AI Agent Security Cheat Sheet
- Model Context Protocol — 2026-07-28 specification release
- NIST AI Risk Management Framework
- Google: Optimizing your website for generative AI features on Google Search
Where to go next
If you are assessing Brillnet as a supplier, start with our public security and compliance and AI oversight information.
If you have a concrete process where an agent should read or change data in another system, describe one action it should be able to perform and one action it must never perform. That is a better starting point than a generic “we want to deploy AI agents”.