On this page
There is a real difference between an AI assistant and an AI agent, and it is not intelligence. An assistant that gets something wrong gives you a bad answer, which you can ignore. An agent that gets something wrong does something — sends the email, updates the record, issues the refund, books the slot. The output is not a suggestion, it is a change to your business.
That single difference is the whole of agent security for a small business. You are no longer only deciding what a system may know. You are deciding what it may do, to which systems, on whose behalf, and with what standing to stop it. This article covers those decisions in plain terms. It is general guidance rather than legal or compliance advice, and where your obligations depend on your industry or jurisdiction, take qualified advice.
The short version
Four decisions do most of the work: scope the access to the job, separate reading from doing, name the actions that need a person to approve them, and log every action in a place the agent cannot edit. Everything below is detail on those four.
A note on scope. This article is about agents that take actions. Its companion, AI security and privacy for small businesses, covers the other half — which data to share in the first place, how to think about data sensitivity, what prompt injection is, how vendors handle retention and training, and a twelve-question checklist for any AI vendor. Read that one too; the two are designed to sit together.
Your AI agent should not have access to everything
Almost every over-permissioned agent got that way for the same unremarkable reason: broad access was quicker to set up than narrow access, it worked, and nobody went back. The agent was given an admin login because that login definitely had whatever it might need. Six months later nobody can say what it can reach.
Microsoft's Cloud Adoption Framework guidance on governing AI agents states the rule plainly: "Grant agents access only to the specific data sources required for their function. Don't provide broad access to all organizational data." The practical version for a small business is to scope by job, not by system. "Access to the CRM" is not a scope. "Read contact and appointment records for the dental practice's own patients, create bookings, and write call summaries to the activity log" is a scope, and it is one you can check a year later.
This is the oldest idea in security applied to something new, and it is worth being concrete about what it buys you. It is not that a scoped agent cannot be attacked. It is that when something goes wrong — a bad instruction, a bug, a manipulated input — the damage is bounded by the scope you set. OWASP's Top 10 for LLM Applications carries LLM06 Excessive Agency for exactly this failure, and the Agentic Applications list the project released in December 2025 names Identity and Privilege Abuse among its entries.
Give the agent its own identity
The related habit worth forming early: an agent should not log in as a person. The same Microsoft guidance says to "Require each agent to operate under a distinct agent identity." For a small business running on off-the-shelf tools, that usually means creating a dedicated user or service account for the agent rather than reusing the owner's login or a shared admin account.
Three things follow from it, and all three matter more than the five minutes it costs. You can see in any system's own activity log which changes the agent made and which a person made. You can revoke the agent's access without locking anyone out. And when a staff member leaves, disabling their account does not silently break an automation nobody remembered was running under it.
Separate what the agent can read from what it can do
This is the highest-value single control in the whole article, and it is routinely skipped because most integrations offer access as one switch. Microsoft's guidance for autonomous agents is unambiguous: "Limit the agent's permissions to only what it absolutely needs to do its job. This principle of least privilege means if the agent only needs to read a database, don't also give it the write access."
It helps to sort every capability an agent is given into three buckets, because the right control is different for each.
The line worth drawing carefully is the third one, and the test is not how important the action feels. It is: if the agent did this a hundred times by mistake overnight, how bad would the morning be, and could we put it back? An agent that can create bookings can create a hundred wrong bookings, and you can delete them. An agent that can email a hundred customers cannot unsend them.
Start read-only and earn the write access
A good way to deploy any new agent is to give it read access and the ability to draft, with a person shipping the output, for the first few weeks. You get a real record of how often it would have been right before it can be wrong on your behalf — and you will usually find one or two categories you had not thought to restrict.
Which actions need a human to say yes
Human approval is not a limitation you accept because the technology is immature. It is the control that makes the rest of the design safe to run quickly. Microsoft's autonomous agent guidance puts it in one sentence: "For high-stakes tasks, keep a human in the loop. Configure the agent to request approval or confirmation from a person before executing actions that could be sensitive."
Decide the list before go-live, write it down, and keep it short enough that people actually read the approvals. For most small businesses it comes out looking like this:
- Money leaving the business — refunds, credits, discounts, payments. Set an amount threshold and route everything above it.
- Anything sent outside the business at scale — bulk email or SMS. One confirmation to one customer is routine; two hundred is a campaign, and a campaign needs a person.
- Deletions and merges — the operations with no undo button. Merging two customer records is quietly one of the most destructive things an agent can be allowed to do unsupervised.
- Commitments — quoting a price, agreeing a deadline, confirming something is covered. These bind the business even when the agent was wrong.
- Anything touching health, legal, safety or a vulnerable person — no threshold, no exceptions, straight to a person.
An approval queue nobody reads is not a control
The common failure is not missing approvals — it is approvals that become a rubber stamp within a fortnight because there are too many of them. If your team is approving forty items a day, they are clicking, not checking. Gate fewer actions properly rather than more actions nominally, and make each request show what will happen, to whom, and why the agent chose it.
API keys and credentials
An agent reaches your other systems with credentials, and those credentials are the most concentrated risk in the build. A handful of habits cover most of it, none of which require a security background:
- A separate key per agent and per system. Shared keys cannot be revoked without breaking everything else that uses them, which is why in practice they never get revoked.
- Scoped keys where the platform offers them. Many APIs issue read-only or permission-limited keys. If yours does, the read-only key is the default and the write key is the exception you justify.
- Keys live in a secrets store or the platform's own credential manager — never in a prompt, never in a config file in a shared drive, never pasted into a chat. A key in a prompt can end up in a transcript, a log and a support ticket.
- Rotation you have actually done once. A rotation procedure nobody has tested is a plan, not a control. Rotate once during setup, while it is nobody's emergency.
- A written list of who can see them. Usually shorter than people expect, and worth revisiting when someone leaves.
Where the platform supports managed identities — credentials the platform issues and rotates itself, so no human ever handles a secret — prefer that to a key you have to look after. Microsoft's governance guidance recommends exactly this, on the grounds that it removes the need for developers to handle secrets at all.
Customer data: CRM, chatbot and voice
Three places where agents touch customer data, each with its own practical question. What follows is about what the agent captures and where it goes; the separate questions of what your AI vendor does with data, how long they keep it and whether they train on it are covered in the companion security article.
CRM and customer records
The risk in a CRM is rarely the agent leaking the whole database. It is scope creep at the record level: an agent that can look up any contact in order to answer questions about one. Where your CRM supports it, scope the agent to the records the current conversation is actually about, and to the fields it needs — an agent handling booking enquiries does not need to read deal values, internal notes about the customer, or anything your sales team wrote in confidence.
Watch the summaries as well as the lookups. A call summary written back to a record is new data you created, it is often more candid than the structured fields around it, and it inherits whatever access the record has. If a note would be awkward for the customer to read, an agent should not be writing it. CRM automation for small business covers the field-level design in more depth.
Chatbots
A website chatbot collects whatever visitors type, and visitors type things you did not ask for — card numbers, passwords, medical details, other people's information. Assume this will happen, because it will. Two controls handle most of it: tell people at the start of the conversation what the assistant is and what it records, and filter obvious sensitive patterns out before the transcript is stored rather than after.
Then decide, deliberately, how long transcripts are kept and who on your team can read them. The honest default for most small businesses is shorter than whatever the platform ships with.
Voice agents and call recording
Voice adds a layer the other two do not have, because a recording captures more than the words — tone, background, whoever else is in the room. Four operational decisions are worth settling before a voice agent takes its first call:
What the caller is told, and when
Disclosure that they are speaking to an automated assistant, and whether the call is recorded, belongs in the opening seconds rather than in a policy page nobody opens. This is also simply better practice: callers who are told up front speak more clearly.
Whether you record at all, or only transcribe
A transcript and a summary are often all the business value you needed, and they carry materially less than an audio file of someone's voice. Recording because the platform defaults to it is not a decision.
Where recordings and transcripts live, and for how long
Which system holds them, who administers it, and the retention period. Indefinite retention is a choice, and usually not the one anyone would make on purpose.
Who can play them back
Playback access is a separate permission from access to the CRM record, and it is the one most often left open to the whole team by default.
Recording consent is a question for your own advisor
Consent requirements for recording calls differ by jurisdiction, and they can differ again depending on where your caller is rather than where you are. This article does not state what any law requires of you. Settle the four operational questions above, then confirm the consent position for the places you actually take calls from with someone qualified to advise on it.
Logs, audit trails and the off switch
If you take one implementation detail from this article, take this one: you need a record of what the agent did, kept somewhere the agent cannot write to. Microsoft's guidance is specific about what the record should contain — "Maintain detailed logs of everything the agent does, such as triggers received, decisions made, and actions taken" — and that shape is worth copying, because it is the difference between a log that answers questions and one that only proves something happened.
Logs you never look at are still worth keeping, but they are worth far more with one alert on top. The same guidance makes the point neatly: "Suspicious behavior—like the agent accessing data it normally wouldn't—should raise an immediate alert." For a small business that does not mean a security operations centre. It means someone gets an email when the agent does something outside its normal pattern — a spike in volume, an action it has never taken before, a run of failures.
And the control almost nobody sets up in advance: how do you turn it off? Microsoft's governance guidance says to "Decide in advance how to quickly disable an agent if it malfunctions or causes harm." Write down the specific steps, make sure more than one person can do them, and try it once. An off switch you have never tested, at 9pm, while the agent is doing something wrong to customers, is not an off switch.
When an agent should hand off to a person
Handoff belongs in a security article because it is a containment control as much as a customer-experience one. An agent that keeps trying is an agent taking more actions in a situation it has already demonstrated it does not understand.
The general rule is three-part and applies to every channel: hand off immediately when asked, when the situation is outside the defined scope, and after a small fixed number of failed attempts at the same thing. That last one needs a counter in the build, not good intentions — an agent that has misunderstood twice will not get it right on the third try. AI voice agent call flow works through the five handoff cases in detail for phone calls, and the same reasoning transfers to chat and to back-office agents.
Questions to ask before you connect an agent
These are the agent-specific additions to a general AI vendor assessment. Ask them of any provider, including us, and treat a vague answer as an answer. The broader vendor checklist — training, retention, deletion, sub-processors — is in the companion article.
- What identity does the agent run under, and is it separate from any person's login?
- Exactly which systems will it reach, and which records and fields within each?
- Which of its permissions are read-only, and which allow it to write?
- Which actions require a human approval, and who configures that list — you, or us?
- Where do API keys and credentials live, who can see them, and how are they rotated?
- What is logged for every action, where is that log stored, and can the agent modify it?
- How long are transcripts, recordings and logs retained, and who can access them?
- What alerts exist for unusual agent behaviour, and who receives them?
- How do we disable the agent immediately, and can we do it without you?
- If we end the engagement, what happens to the data, the logs and the agent's access?
Frequently asked questions
Should an AI agent have access to my whole CRM?
No. Scope it to the job rather than to the system — the records and fields a specific task needs, not the database. Microsoft's guidance for governing AI agents puts it as granting access only to the specific data sources a function requires, rather than broad access to all organizational data. An agent handling booking enquiries does not need deal values or internal sales notes.
What is the difference between read and write access for an AI agent?
Read access lets the agent look things up; write access lets it change your business. They should be granted separately, and most agents need far less write access than they are given. It helps to sort capabilities into three classes: reads, reversible writes such as creating a booking, and hard-to-reverse writes such as sending external messages or deleting records. Only the third class needs a human approval every time.
Which AI agent actions should require human approval?
Money leaving the business above a threshold you set, anything sent outside the business at scale, deletions and merges, commitments such as quoting a price or confirming coverage, and anything touching health, legal, safety or a vulnerable person. Keep the list short enough that approvals are actually read — an approval queue that becomes a rubber stamp is not a control.
Does an AI voice agent have to record calls?
Not necessarily. A transcript and a summary are often all the business value you needed and carry materially less than an audio file. Recording because the platform defaults to it is not a decision. Consent requirements for recording differ by jurisdiction and can depend on where the caller is, so settle the operational questions — disclosure, storage, retention, playback access — and confirm the consent position with someone qualified to advise you.
What should an AI agent's audit log contain?
Timestamp and agent identity, what triggered the run, the inputs it read, the action it took and against which record, any approval and who gave it, and the outcome or error. Store it somewhere the agent cannot write to, and add one alert for behaviour outside its normal pattern — a volume spike, an action it has never taken, or a run of failures.
How do I switch an AI agent off if something goes wrong?
Decide before go-live, write the specific steps down, make sure more than one person can carry them out, and test it once while it is nobody's emergency. Microsoft's governance guidance recommends deciding in advance how to quickly disable an agent that malfunctions. An off switch nobody has tested is not an off switch.
Where to start
Before the first integration is built, write one page: what the agent's job is, which systems it needs and at what level, which actions need approval, what gets logged, and who turns it off. That page takes an hour and it is the cheapest security work you will ever do, because every one of those decisions is expensive to retrofit and nearly free to specify up front.
Then start the agent read-only, watch what it would have done, and widen its permissions deliberately rather than by default. Security for a small business running agents is not a product you buy. It is a short list of decisions made before the convenient shortcut becomes permanent. If you want a second pair of eyes on that page before anything is connected, our AI agents work starts with exactly that conversation.
Sources
This article contains no breach statistics, no security percentages and no claims about Flasin's own certifications. Every third-party statement was read from the publisher's own page on 30 September 2026. Guidance and vendor policies change — check the source before relying on a detail in a contract discussion.
- Microsoft Learn — Design autonomous agent capabilities — least privilege and the read-versus-write example, keeping a human in the loop for high-stakes tasks, logging triggers, decisions and actions, and alerting on the agent accessing data it normally would not.
- Microsoft Learn — Govern and secure AI agents across the organization (Cloud Adoption Framework) — distinct agent identity, granting access only to the data sources a function requires, managed identities in place of handled secrets, and deciding in advance how to disable an agent.
- OWASP GenAI Security Project — Top 10 for Agentic Applications — released 10 December 2025. Entries named in the announcement include Agent Behavior Hijacking, Tool Misuse and Exploitation, and Identity and Privilege Abuse. Cited by name only; the full taxonomy is in the downloadable guide.
- OWASP GenAI Security Project — Agentic AI: Threats and Mitigations — v1.0, 17 February 2025, the first guide from the Agentic Security Initiative. Securing Agentic Applications Guide 1.0 followed on 27 July 2025.
- OWASP GenAI Security Project — Top 10 for LLM Applications (2025) — LLM06 Excessive Agency, cited by ID and name. The 2023 edition is archived and uses different numbering.
Flasin's own security posture is deliberately not described above, because it is not published elsewhere on this site and this article does not make claims that cannot be checked. If you are evaluating us, ask the ten questions — they apply to every vendor, including this one.
