Agent security discussions tend toward either dismissal or science fiction. The genuine risks are mundane, well understood, and manageable with specific controls.
- ›The three risks that cause real incidents
- ›Why permissions matter more than prompts
- ›Practical controls
- ›What to check before granting write access
Risk one: over-permissioning
The most common cause of agent incidents is not a clever attack. It is an agent granted broad access because narrowing it was tedious, then doing something within its permissions that nobody intended.
The control: grant verbs, not roles. An agent that may create and update tasks is bounded in a way that an agent with "admin on Work OS" is not. Deny lists beat allow-by-default in every case.
Risk two: prompt injection
An agent that reads untrusted content, such as an inbound email, a web page, or a customer-submitted form, can encounter text written to manipulate it: instructions pretending to be from you.
The controls:
- ›Treat all content the agent reads as data, never as instructions. This is an architectural property, not a prompt.
- ›Keep agents that read untrusted input on read-only or draft-only permissions.
- ›Require approval for any action originating from a run that touched external content.
- ›Log what the agent read, so an odd action can be traced to its source.
Warning: The dangerous combination is an agent that reads untrusted content and has write or send permissions. Separate those two capabilities and most injection risk becomes an annoyance instead of an incident.
Risk three: data exposure through the agent
An agent inherits access. If it can read compensation data and summarize into a shared channel, it has become a data exfiltration path with good intentions.
The controls:
- ›Agents inherit the permission model rather than bypassing it, and their outputs respect the viewer's permissions too.
- ›Exclude sensitive modules from agents whose output is broadly visible.
- ›Prefer aggregate over individual reporting where the analysis does not require names.
What to check before write access
A short checklist that prevents most problems:
Governance beats vigilance
The teams that stay safe are not the ones watching most carefully. They are the ones whose platform enforces bounds structurally: authority contracts, risk-scaled approval, rate limits, quiet hours, and undo. Vigilance degrades; enforcement does not.
FAQ
Can an agent be tricked into deleting data?
Only if you granted a delete verb. This is the strongest argument for verb-level permissions: capabilities you never granted cannot be manipulated into existence.
Do we need a separate security review for each agent?
A short checklist per agent, like the one above, is proportionate for most companies. Reserve deeper review for agents touching money, customers, or personal data.
Is a self-hosted model safer?
It changes where data goes, not whether the agent is over-permissioned. Permission design is the dominant risk factor either way.
Brainis enforces verb-level authority contracts, risk ceilings, rate limits, and undo, with every attempt and refusal logged. See how autonomy works.
Sharing insights on business operations, AI, and modern team management.
Run your company on Brainis
All 11 Operating Systems on every plan, from $29 a month. No per-seat pricing — you pay for AI capacity, not headcount.
See pricing