Permissions & Trust
What an agent can do
matters less than what
it is allowed to do.
Every agent I deploy follows a permissions architecture designed around one principle: earn access through demonstrated reliability, never assume it.
Read before write. Observe before act.
When I deploy an AI agent into a business, the first version cannot send emails, cannot modify records, and cannot take any action with external consequences. It starts with read-only access to the systems it needs to understand.
The limitation is deliberate. It is the architecture.
An agent that can read your inbox, CRM, and booking system learns your business context, tone, and patterns before it ever drafts a reply. By the time it earns write access, it already knows how you operate.
Most AI deployments fail because they start with capability and bolt on trust later. I start with trust and unlock capability as it is earned.
Four tiers of earned access.
Observe
The agent learns your business before it touches anything.
Can
- Read emails, CRM records, calendar, booking data
- Search the web and gather competitive intelligence
- Analyse documents and data provided to it
- Write working files to its own workspace
Cannot
- Send any external communication
- Modify any record in any system
- Access data outside its designated scope
- Take any action visible to customers or partners
Advances when: When the operator confirms the agent understands their business context, tone, and workflows accurately.
Draft
The agent creates. A human approves.
Can
- Draft email replies for review
- Prepare CRM updates for approval
- Create documents, reports, and analysis
- Suggest operational changes
Cannot
- Send emails or messages
- Apply CRM changes directly
- Interact with customers
- Make irreversible changes to any system
Advances when: When drafts consistently require minimal editing and the operator trusts the agent's judgement on tone, accuracy, and completeness.
Act with Approval
Routine operations run. Novel actions still need sign-off.
Can
- Send pre-approved email templates
- Update CRM fields within defined rules
- Apply labels, tags, and categorisations
- Execute routine workflows autonomously
Cannot
- Send bespoke communications without review
- Delete any data
- Access new systems without explicit authorisation
- Override operator decisions
Advances when: Rarely. Full autonomy is appropriate only for well-defined, low-risk, reversible operations.
Autonomous
Bounded independence. The rails are the product.
Can
- Execute defined workflows end-to-end
- Handle routine communications independently
- Monitor systems and flag anomalies
- Escalate anything outside its defined scope
Cannot
- Expand its own permissions
- Access systems beyond its mandate
- Take irreversible actions without confirmation
- Operate outside explicitly defined boundaries
Hard boundaries for every deployment.
These are architectural constraints built into every deployment.
No sending without approval
Until explicitly promoted to Tier 3 or above.
No deleting data
Agents create and update. Never destroy.
Credentials stay in infrastructure
API keys and tokens live in secure environment configuration. Never in agent memory, never in prompts.
Progressive access
New systems are granted deliberately, one at a time, with clear intent. Each expansion requires a conscious decision.
Purposeful access
Agents query live systems when needed. They don't bulk-export customer records or cache personal data in their own storage.
No self-modification
Agents cannot change their own permissions, instructions, or safety boundaries.
The deployment that works is the one people trust.
The biggest risk in AI deployment is trust failure. An agent that sends one wrong email, updates one wrong record, or accesses one wrong system erodes confidence faster than any amount of good work rebuilds it.
The permissions model exists to make the boring outcome the default. An agent that does exactly what it is supposed to, within exactly the boundaries it is given, every single time. That is the product working as designed.
I built this model running my own business on it first. Full context: email, CRM, calendar, financial data, codebase. The trust tiers above reflect how that access actually expanded over weeks of real operation. The principles are tested because I test them on myself before anyone else.
Want to see how this works in practice?