The Agentic AI Time Bomb Inside Your Operations.

Agentic AI is the most significant operational shift most SMBs have made in the past two years — and the least understood. Unlike a chatbot that answers questions or a model that generates text, an AI agent takes actions. It accesses systems. It makes calls. It sends emails, updates records, executes workflows, and increasingly, coordinates with other agents to complete multi-step tasks.

Most of the SMBs we work with have deployed at least one AI agent in the past 18 months. Most of them cannot tell us, with precision, what that agent has access to, what decisions it makes autonomously, how its actions are logged, or what happens when it encounters a situation it wasn't designed for. That gap — between what you think your agent does and what it actually does — is where the liability lives.

78% of SMBs that have deployed AI agents have no formal audit log of agent actions. 3x higher regulatory scrutiny for organisations where AI agents have write access to customer data. And 0 — zero AI vendor contracts we've reviewed that accept liability for agent-initiated errors.

You don't need a specialist to run this audit. You need honesty about what you've actually deployed and the discipline to document it properly. Here are the four risks your audit must address.

When an AI agent is deployed, it is typically granted permissions by a developer or system administrator who is optimising for the agent's ability to complete its intended task. The path of least resistance is to grant broad permissions — read and write access to relevant systems — rather than the minimum permissions required for each specific action.

The result: an agent designed to draft customer communications may have write access to your CRM, your email system, your customer database, and your billing platform. If it encounters an edge case — a malformed request, a prompt injection attack, a misunderstood instruction — it can cause damage across all four systems before any human is notified.

The audit question: for each agent, what is the maximum damage it could cause if it received a malicious or malformed instruction? If the answer is "it could email every customer in our database" or "it could modify billing records," your permission scope is too broad.

"Your agent was designed for the tasks you imagined. It operates in the full complexity of your actual systems. The gap between those two things is your exposure."

When a human employee makes a decision — sends an email, updates a record, approves a transaction — there is typically a trail. It may be imperfect, but it exists. When an AI agent makes the same decision, the trail exists only if someone deliberately built logging into the agent's architecture. Most people don't, because logging feels like overhead when you're trying to ship.

The regulatory and operational consequences of absent logging are severe. Under GDPR, you may be required to demonstrate that processing of personal data was lawful — which means documenting what your agent did, when, to whose data, and on what legal basis. Under the EU AI Act's high-risk provisions, you need audit trails of consequential decisions. Under your professional indemnity insurance, you may need to demonstrate the sequence of events that led to an error.

If your agent took an action today that caused a customer complaint next week, could you reconstruct exactly what the agent did, why, and when? If the answer is no, you have a logging gap that needs to be closed before you need it.

Prompt injection is an attack in which malicious instructions are embedded in content that your agent processes — a customer email, a web page it visits, a document it reads — causing the agent to execute unintended actions. It is not a theoretical vulnerability. It has been demonstrated against production agentic systems and is increasingly exploited as agents gain greater access to enterprise systems.

For an SMB with an agent that processes incoming emails, visits customer-provided URLs, or reads external documents, the attack surface is significant. An attacker who knows your agent reads support emails can embed instructions in a support ticket. An agent with write access to your systems may execute those instructions before any human sees them.

The mitigation is not to stop using agents. It is to design agents with the assumption that they will receive malicious input. This means input sanitisation, clear privilege boundaries between agent actions, human approval gates for high-consequence actions, and regular adversarial testing of agent behaviour with unexpected inputs.

The most sophisticated — and least understood — deployment pattern is orchestrated multi-agent systems: one agent coordinates the actions of others, each of which has its own set of permissions and capabilities. These systems are powerful. They are also substantially harder to audit, because the action you need to trace may have been initiated by an orchestrator agent, delegated to a specialist agent, and executed by a third agent — with each handoff potentially losing context and oversight.

Most SMBs that have deployed multi-agent systems have a single human point of accountability who has not reviewed the full permission scope of every agent in the network. If your orchestration layer goes wrong — if it misroutes a task, misinterprets an instruction, or escalates to a higher-permission agent when it shouldn't — the blast radius is significantly larger than a single-agent failure.

The governance requirement: a complete permission inventory across all agents in your network, a documented escalation policy that specifies when and whether agents can delegate to higher-privilege agents, and a designated human owner for each agent who is responsible for its audit log.

Step 1: Inventory every agent in your environment. List every AI agent, automation, or workflow that takes actions in your systems without direct human input for each action. Include agents in third-party tools your team uses daily — CRM automations, email agents, scheduling tools, support ticket processors.

Step 2: Map permissions for each agent. For each agent, document: what systems does it have read access to? Write access? Can it communicate externally (email, API calls)? Can it initiate financial transactions? Can it delegate to other agents? Document the maximum possible impact of a worst-case action by each agent.

Step 3: Audit your logging coverage. For each agent, can you produce a complete action log for the past 30 days? If not, what actions are not being logged? Assess whether unlogged actions involve personal data, financial transactions, or customer communications — all of which require evidence trails under existing regulation.

Step 4: Test with adversarial inputs. For each customer-facing or externally-exposed agent, run at least one adversarial test: provide an input that contains instructions designed to cause the agent to behave unexpectedly. Document how the agent responds. If it follows the injected instruction, your input validation needs to be addressed before the next deployment.

Step 5: Assign human ownership to every agent. Every agent in your environment should have a named human owner who is responsible for: reviewing the action log at least monthly, approving any change to permissions, and being the first point of contact if the agent behaves unexpectedly. "The AI team owns it" is not ownership. A named person is ownership.

Now. Not after the next deployment. Not after the next board meeting. The EU AI Act's deployer obligations apply regardless of whether you've audited your systems. A regulator examining your agentic AI deployment will not accept "we didn't know" as a defence.

The audit window is now. Use it.