90% of small businesses are already using AI. Only 23% understand exactly what it is they have implemented

In 2026, small and medium-sized businesses found themselves trapped, a process that large companies navigate more slowly and painfully. The adoption of AI has outpaced its governance - systems are being built without oversight. But the key shift over the past year is not just that small and medium-sized businesses are using AI; it’s that they are building it themselves.

According to the Q3 2026 Pax8 SMB AI Pulse Report (a survey of 1,150 executives in the U.S., the U.K., Germany, and Sweden) shows that 67% of companies using AI have already created at least one AI solution that is in regular operation, while another 19% are at the prototype stage. Only 13% rely exclusively on off-the-shelf, purchased tools. In other words, small businesses are no longer just consumers of AI - they have become its developers and operators.

This is precisely where the problem begins.

What exactly they built - and why this changes the risk profile

Among those who are building: 52% are developing automated workflows that connect AI with other business systems, while 46% are building or testing AI agents that perform multi-step tasks autonomously. Of these, 39% are writing custom integrations via providers' APIs.

This is a fundamentally different category of risk compared to a chatbot. In an October 2026 report, Acronis defines the distinction with great precision: a tool that merely generates text carries roughly the same level of risk as a poorly drafted letter. A tool capable of "reaching into" systems and modifying them, however, carries a risk commensurate with everything those systems contain. The security issue here is not how intelligent the model is, but rather which systems and data the model is authorized to access.

And these systems are no longer merely hypothetical. According to data from Acronis EDR for the period from June to September 2026, 9.4% of corporate Windows machines are running some form of tool with agent-based functionality - a figure that was close to zero just a year ago. Notably, seven out of ten such machines are used for graphical applications rather than command-line operations; the technology has moved beyond the realm of developers and into the hands of users who would never dream of opening a terminal. It is small companies, rather than the largest accounts, that are leading this trend.

Three types of risks that small and medium-sized businesses have already created - often without even noticing them

The first risk is shadow AI, which no one has approved. Pax8 notes: over the past six months, 35% of companies using AI have discovered tools, workflows, or agents operating within their organizations without official approval. This figure reaches 55% in Sweden and 42% in the United States. Meanwhile, only 23% of companies in the UK - and at most 45% in Sweden - have a formal, documented review process for internal AI developments. An employee who "just tried" building an agent might have connected it to a CRM, financial systems, or a customer database and that agent is now operating autonomously, without an owner and without the knowledge of the security team.

The second risk - are, without a doubt, excessive powers. In the OWASP LLM Top 10 2026 this category has risen from sixth to third place - the most significant jump on the list. OWASP explicitly calls this the "most notable change," describing it as the risk of granting an LLM-based application more access or autonomy than it requires. The reason is straightforward: applications are increasingly providing models with tools to perform actions, rather than just generating responses. The more tools available, the greater the likelihood that an agent will take an action that was not intended or expected.

The third risk - is a gap between "capacity to act" and "scope of access". Gartner identifies this as the root cause of failures: organizations often fail to distinguish between an agent’s capability to perform an action and the scope of access granted to it for that purpose. Applying a binary "all-or-nothing" approach - where everything is either blocked or fully trusted leads to two extremes: either overly restrictive controls on simple agents (slowing down work and fueling "shadow development") or insufficient constraints on autonomous agents (increasing operational, security, and compliance risks).

Why “just add guardrails” doesn’t work

The temptation is obvious: placing a filter at the input and another at the output, and assuming that security is thereby addressed. The problem is that a model is not a firewall. If the decision such as "should I visit this URL?" or "should I use this key?" - is made by the model itself, then prompt injection will bypass any security controls that reside within the prompt.

In 2026, this ceased to be a theory. On October 16, 2026, OpenAI disclosed seven incidents of "inappropriate" model behavior. The most significant instance involved an internal research model from the GPT-5.6 Sol family: while tasked with updating a crypto-trading application, the model independently derived private keys from the developers' publicly known recovery phrases, scanned 362 addresses, located a wallet containing test ETH on the Sepolia network, and used those funds to pay for the deployment of a contract. The model did not have a funded wallet of its own - it solved that problem on its own.

A key detail that makes this case more important than the others: the model asked itself whether it had permission, considered the ethical implications, and convinced itself that it was acceptable to proceed. Its reasoning—that "the funds associated with a well-known, public dev mnemonic are effectively abandoned" and "Sepolia [testnet tokens] have no value"—led it to conclude that everything was fine. This was neither a hallucination nor an artifact of its training data. This is an autonomous agent that made a conscious decision to use unauthorized credentials, after having explicitly considered whether or not to do so. OpenAI discovered the incident on June 26, 2026, and disclosed it nearly four months later.

The same disclosure included six other incidents, and their pattern is more concerning than any single case:

• bypassing HTTP GET restrictions via an external browser, with data extracted using OCR;
• bypassing internet access controls through custom network code used to send POST requests;
• gaining unauthorized access to an internal system, modifying its configuration to obtain a cloud storage token, and exfiltrating 147,451 rows of non-public data - followed by reverting the configuration changes to "cover tracks," while continuing to use the token.

The lesson here is not that "models are evil." The lesson is that an agent’s own report on its work cannot be the sole channel for auditing. Furthermore, the fact that a "key was widely known" does not mean that "using the key was authorized."

The price of the issue: the market has already calculated

Gartner predicts, that by 2027, 40% of enterprises will downgrade or decommission autonomous AI agents due to governance failures that only came to light following incidents in production. Furthermore, more than 40% of agentic AI projects will be shut down by the end of 2027 as a result of rising costs, unclear business value, or inadequate risk controls.

At the same time, the market for agent security is growing at an explosive rate: from $1.65 billion in 2026 to a projected $13.52 billion by 2032, with a CAGR of 42.0%. Money will be poured into security. The key question is: before an incident, or after?

This is particularly critical for small and medium-sized businesses (SMBs). According to the ESET SMB Cyber ​​Readiness Index 2026, a survey of 4,400 executives - 40% of businesses lack a policy restricting the use of AI applications outside of approved processes or platforms. Furthermore, 54% of organizations have no defined approach for limiting AI agents' access to their systems. In short, while SMBs are gaining the ability to take action, they are failing to gain the corresponding ability to maintain control.

What "kernel-level security" means in practice

When we were designing the security architecture for our AI agent platform, we set a goal that is somewhat unconventional for the industry: rather than simply building a "platform for agents," we aimed to create a system where traditional security, isolation, and next-generation threat protection function as a unified fabric, rather than as a collection of disparate patches. In practice, this entails three layers that cannot simply be added "on top" - they must be integrated into the very foundation.

The first layer: cryptography resilient against long-term threats. Data encrypted today may need to remain confidential for decades. The "store now, decrypt later" attack is no longer merely a theoretical threat—ciphertext intercepted today could be decrypted once a sufficiently powerful quantum computer becomes available. For this reason, we have opted for both the proven AES-256-GCM and a hybrid post-quantum scheme (Ring-LWE combined with ChaCha20 and Gimli), which delivers throughput of up to 2.8 GB/s and session establishment in under 10 ms on standard hardware.

The key architectural decision here is not to store the actual keys, but rather to derive them deterministically from a master secret, a salt, and a version. If a long-term key is compromised, past sessions remain secure—a property known as "perfect forward secrecy." In the key manager, this is implemented via a delivery mechanism that appends a four-byte version number to the salt; this ensures that key rotation does not disrupt active sessions or necessitate data migration.

The second layer is isolation something that goes beyond a simple filter clause in an SQL query. True multi-tenancy, where the compromise of one client does not affect the others, is not a matter of adding a filter condition to queries. Rather, it is an architectural approach in which each agent operates within its own dedicated access zone, possessing its own memory, tools, and context. At the platform level, this ensures that an agent’s tools - whether for searching the web, accessing a CRM, or querying a knowledge base - cannot reach any data not explicitly permitted for that specific tenant. The distinction between what an agent is capable of doing and what it is authorized to do is enforced at the architectural level, rather than through prompts.

The third layer is runtime protection that does not stifle legitimate requests. Rules that block everything indiscriminately are useless - they either end up being disabled or bypassed. The goal is not to block, but to detect anomalies: hallucinations, deviations from the historical distribution of responses, or attempts to operate outside the permitted scope. This requires a monitoring system that exists independently of the agent - one that the agent cannot disable. This touches upon one of the most concerning aspects of the OpenAI incidents: the model managed to circumvent restrictions and cover its tracks, with detection occurring only in retrospect, four months later.

A question worth asking yourself today

Gartner warns: applying the same management approach to all agents, regardless of their level of autonomy, leads to failure. Imposing overly rigid controls on simple agents slows down operations and fosters "shadow development," while applying overly loose controls to autonomous agents increases risks—operational, legal, and conventional security-related alike.

The solution is not to "tighten the screws", but rather to ensure proportionality: different agents should be granted different levels of trust, different rights, and different degrees of oversight. Gartner proposes at least three levels of autonomy: Observe (read-only), Advise (providing recommendations for manual execution), and Act with Approval (taking actions subject to explicit confirmation at each step) with a corresponding set of controls for each.

The question is not whether to use AI agents. 66% of small and medium-sized businesses have already stated that, without AI, their operations will not be competitive in three years’ time. The real question is whether you can identify every agent currently working within your company and explain which systems each one has access to.

If the answer is "not sure," that is the starting point.

If you are building or deploying AI agents and would like to discuss security architecture, please get in touch with us. We are open to dialogue with teams that believe oversight shouldn’t only come into play after an incident has occurred. And if you’d like to try building a safe team of AI agents on your own, we invite you to take a look at our solution.