Category: Cybersecurity

A recent credential-harvesting campaign reportedly compromised thousands of third-party credentials in less than six hours. Its distinguishing feature was not a novel vulnerability or an unusually large criminal organization. The attackers used an autonomous, multi-agent AI framework to plan, scan, troubleshoot, rotate infrastructure, and collect credentials with limited human supervision.

For small and midsized businesses, the lesson is not that every company needs defensive AI. It is that the time between an exposed weakness and real business damage is shrinking.

Attackers have long automated internet scanning, phishing emails, stolen-password attempts, and cloud-service probing. AI makes those activities more adaptive. Rather than waiting for an operator to interpret an error, revise a script, or choose the next target, an agentic system can adjust in real time.

Many SMB security programs still depend on attackers moving slowly enough for someone to notice, investigate, and intervene. That assumption is becoming less reliable.

Speed and scale change the risk

The reported campaign used an AI coding chatbot, prompts, and preconfigured instructions as an operational playbook. The system handled vulnerability scanning, credential harvesting, troubleshooting, and IP rotation. It turned tasks that once required skilled people and sustained attention into a faster, repeatable process.

AI has not made sophisticated attacks effortless. Criminals still need access, infrastructure, and worthwhile targets. But it reduces the time and cost of exploiting ordinary security failures. An unpatched internet-facing application, exposed development token, reused administrator password, or poorly protected cloud account can be found and abused before a weekly IT review occurs.

This matters most for organizations with limited security capacity. A smaller company may not be individually high value, but it can be one of hundreds or thousands of targets processed automatically. Attackers no longer need to choose victims one at a time if their systems can identify vulnerable organizations at scale.

Controls that depend on delayed human action—periodic log review, quarterly access cleanup, or informal patching schedules—need reinforcement. The goal is not perfect prevention. It is to make common attacks fail quickly and detect the ones that get through before they become a broader disruption.

Credentials are a core business asset

The source reporting describes attacks targeting cloud credentials, developer configurations, AI coding assistants, CI/CD pipelines, and API keys. These are technical details with a straightforward business implication: credentials increasingly control valuable parts of the company.

A cloud access key may provide access to computing resources, data storage, backups, or customer information. A development token may permit changes to source code or deployment pipelines. An AI service API key can expose proprietary prompts, documents, or usage capacity, and may generate unexpected charges if hijacked. A compromised email account can lead to invoice fraud, customer impersonation, or ransomware.

For many SMBs, identity security now matters as much as perimeter security. A firewall offers limited protection when an attacker signs in with a legitimate account.

Reduce the power and lifespan of credentials:

• Require multi-factor authentication for email, cloud administration, finance systems, remote access, and code repositories.
• Use phishing-resistant methods, such as security keys or device-based passkeys, for privileged accounts where feasible.
• Eliminate shared administrator accounts.
• Give employees and service accounts only the access they need, and review administrative privileges regularly.
• Remove API keys and passwords from code repositories, deployment scripts, spreadsheets, and chat threads.
• Use a managed password vault and the secrets-management features available through cloud or development platforms.
• Rotate keys when an employee leaves, a vendor relationship changes, or exposure is suspected.

Development tools are part of the attack surface

The campaign described in the source material included attacks through public software ecosystems such as PyPI, npm, and Docker Hub. These repositories are essential to modern development, allowing teams to use third-party packages and container images to build applications quickly. They are also attractive malware distribution channels.

This affects more than software companies. Businesses that operate customer portals, use development agencies, maintain internal integrations, or rely on customized workflows may inherit supply-chain exposure through the tools and dependencies used on their behalf.

Leaders do not need to audit every software package personally. They should expect clear answers from internal IT teams or outside providers:

• Who approves new third-party code packages and container images?
• Are dependencies kept current and monitored for known vulnerabilities?
• Are production deployments protected from a compromised developer account?
• Can the business identify systems affected by a compromise of a key supplier or software component?

A practical baseline includes code review for production changes, separation between development and production access, and multi-factor authentication for code repositories and deployment platforms. Contracts with outside development or hosting firms should address credential handling, incident notification, access removal, backups, and patching responsibilities.

Govern AI use without slowing the business

The technologies attackers use can also be useful inside a business. Employees may use AI assistants to draft content, analyze documents, write code, or support customer service. The issue is not AI use. It is unmanaged AI use involving sensitive data, company credentials, or production systems.

A short, workable policy should identify approved AI tools, define what data employees may enter, establish who can connect AI services to company systems, and set requirements for API-key management. Staff should understand that customer data, confidential contracts, source code, passwords, and internal financial information do not belong in unapproved public tools.

Preparation also needs to match the pace of attacks. Centralize logging for critical systems. Alert on unusual sign-ins and new administrator accounts. Know who has authority to disable accounts or revoke keys after an incident, and test that process occasionally.

When attackers can move from scanning to stolen credentials in hours, a response plan measured in days is not adequate.

The most effective SMB strategy is not to match criminal AI with expensive technology. It is to remove easy paths: protect identities, control credentials, secure development and cloud access, and make abnormal activity visible early. AI may accelerate attackers, but disciplined fundamentals still determine whether that speed becomes a business crisis.

Meta’s launch of Muse, a personal AI agent that can schedule, shop, send emails, fill out forms, book travel, and work toward longer-term goals, reflects a significant shift in business technology.

Chatbots mostly generate information: a draft, a summary, or a suggestion. AI agents are designed to take action. They can use a browser, interact with applications, coordinate work across services, and proceed with less detailed instruction from the user.

For small and midsized businesses, the appeal is obvious. An owner may see a way to reduce administrative work, help a small team manage customer communications, organize travel, research suppliers, or turn a rough expansion idea into a project plan. This is more than better writing. It is delegation.

That is why AI agents require a different level of management than ordinary productivity software.

An Agent Does Not Need to Be “Intelligent” to Create Risk

An AI agent does not need to be superintelligent to create meaningful business risk. It needs access to something valuable and permission to act.

There is a material difference between asking an AI tool to draft a vendor email and allowing an agent to access the inbox, read a message, decide how to respond, and send that response. The second scenario involves business judgment, confidential information, and an external commitment. A bad response could damage a customer relationship, disclose pricing, accept unfavorable terms, or create confusion that staff must later unwind.

The same applies when an agent can fill out forms, make bookings, negotiate, or use web-based business systems. A routine-looking task can have financial, legal, operational, or reputational consequences.

Small businesses do not need to avoid AI agents. They should treat them as a new form of delegated access, not as a more capable search engine.

The core governance question is simple: What can this tool see, what can it do, and what happens if it gets the task wrong?

Privacy Features Do Not Remove Governance Responsibilities

Meta says Muse runs in a dedicated secure virtual machine containing the agent and the user’s data, and the company emphasizes safety and privacy. Those are meaningful design claims. Isolation can help limit exposure between environments, and security architecture matters when a tool handles personal or business data.

But a secure environment does not make every use of an agent safe for a business.

The larger issue is authority. An agent may be technically well protected while still receiving excessive access to email, calendars, documents, browser sessions, customer information, payment workflows, or third-party accounts. The risk is not limited to an outside attacker breaking in. An agent can act on incomplete context, misunderstand an instruction, or make an irreversible decision too quickly.

AI systems can also encounter untrusted content. An agent that reads emails, websites, documents, or support requests may process material deliberately designed to influence its behavior. In cybersecurity, this is often called prompt injection: hostile or misleading instructions embedded in content that the AI treats as part of its task.

If an agent can browse and act without meaningful limits, a malicious page or message may try to redirect its actions. Leaders do not need to understand every technical detail of prompt injection. They need to understand the practical implication: an agent should not receive broad authority simply because it can interpret language and navigate software.

Start With Bounded Tasks

For most SMBs, the sensible early use of AI agents is low-risk, reversible work.

An agent might gather information for a staff member, organize a preliminary travel itinerary, prepare a draft customer response, create a task list from a meeting, or assemble options for a purchase decision. These uses can save time while keeping human review in place before a commitment is made.

Risk rises when an agent can send messages, approve payments, alter records, sign up for services, download files, change account settings, or negotiate with vendors. Those activities need explicit rules and, in many cases, human approval before execution.

A practical permission model has three levels:

• Read and prepare: The agent can review designated information and produce recommendations or drafts.
• Act with approval: The agent can complete forms, prepare emails, or set up transactions, but a person must review and submit them.
• Limited autonomous action: The agent may complete narrowly defined, low-impact tasks, such as scheduling internal meetings within preset rules.

The third level should be earned through testing, not assumed at deployment.

Keep Personal Convenience Separate From Company Access

Tools marketed as personal assistants can quickly become business tools. An employee may connect an agent to a work email account, use it to manage customer appointments, or provide company documents to get better results. That is understandable, particularly in organizations where people wear multiple hats. It can also create unmanaged data sharing and access pathways.

Set a clear rule before employees begin experimenting: which accounts, data types, and systems may be connected to AI agents, and which may not.

At minimum, employees should not give an agent access to highly sensitive information unless the organization has approved the specific tool and use case. This commonly includes banking credentials, payment systems, payroll data, tax information, customer payment information, trade secrets, legal files, and administrative account credentials.

Where business use is approved, use dedicated accounts where possible rather than a founder’s or manager’s primary login. Give the agent only the permissions required for its intended task. If it needs calendar availability, it should not also be able to read, delete, or send email.

Automation Still Requires Accountability

The appeal of an agent is that it can keep moving while people are busy. The business still needs a named person responsible for the outcome.

Before authorizing a new agent use case, leadership should be able to answer a few operational questions:

• Who owns the process?
• What information will the agent access?
• What actions can it take?
• How are those actions reviewed?
• How quickly can access be revoked if something goes wrong?

These are not bureaucratic exercises. They are the controls that keep a time-saving experiment from becoming an expensive incident.

AI agents may eventually become routine business infrastructure. For now, their most valuable role for many SMBs is as a supervised assistant: fast, useful, and increasingly capable, but not entitled to make consequential decisions without clear boundaries.

Many small and midsized businesses have adopted multi-factor authentication (MFA) and rightly see it as a major security improvement. It is. MFA makes stolen passwords far less useful and blocks a large share of routine account takeover attempts.

But MFA protects the login process. It does not necessarily protect what happens after a user has logged in.

A recent analysis of information-stealer malware data illustrates the gap. Malware on employee devices can capture browser session tokens, API keys, and related authentication data for AI services and other cloud applications. Criminals can replay those tokens and act as the legitimate user—often without entering a username, password, or MFA code.

For businesses deploying ChatGPT, Gemini, Claude, coding assistants, and AI-enabled productivity tools, the question is no longer limited to whether employees use strong passwords and MFA. Leaders also need to ask what valuable access remains on an employee device after login, and what happens if that device is compromised.

A Session Token Can Act Like a Temporary Master Key

After a user signs in to a web application, the service typically gives the browser a session token. The token tells the application that the user has already authenticated. It allows an employee to move between pages, reopen a browser, and continue working without completing MFA every few minutes.

That convenience creates an opportunity for attackers.

Information stealers such as Lumma Stealer and Vidar are designed to collect data from infected computers, including saved credentials, browser cookies, session data, and API keys. The resulting “stealer logs” are sold in criminal marketplaces. A buyer does not need to infect a victim directly; they can purchase access data collected by someone else.

If an attacker obtains a valid session token, they may be able to replay it in a specially configured browser and appear to the AI provider as an authenticated user. MFA may have worked exactly as intended when the employee logged in. The attacker is reusing evidence that the login already occurred.

In the dataset examined by Okta, thousands of unexpired tokens appeared across a broad range of services, including major cloud, productivity, and AI platforms. Some tokens also contained personally identifiable information in readable form. That creates a second exposure: attackers can use the data to make later phishing or social-engineering messages more convincing.

Requiring MFA is not the end of the identity-security conversation. Passkeys and phishing-resistant MFA remain worthwhile because they reduce password theft and credential phishing. They do not, by themselves, make a stolen active session or exposed API key harmless.

AI Accounts Can Expose More Than Prompts

A compromised AI account can expose more than the account holder’s prompts. The impact depends on how the organization uses the tool.

An employee may have entered customer details, contract language, internal strategy, source code, financial information, or proprietary documents into an AI service. An intruder with access to that account may be able to view conversation history, files, custom assistants, integrations, or project settings, depending on the platform and subscription configuration.

API keys present a different but equally material exposure. They allow software to call AI models programmatically. A stolen key can generate large volumes of AI requests at the victim’s expense—a practice sometimes called LLMjacking. The result can be an unexpected bill, exhausted service limits, or use of the key to support an attacker’s own operations.

The same pattern applies to cloud infrastructure. Google has reported an incident in which an exposed GitHub personal access token gave an attacker an entry point into a cloud environment. The attacker deployed unauthorized AI infrastructure and scaled high-performance computing resources. For an SMB, runaway cloud consumption can become both a financial event and an operational disruption, particularly when critical workloads share the same environment.

There is also a customer-trust issue. Customers may accept that a business uses modern AI tools. They will be far less accepting if their information appears in an unauthorized account or a breach shows that access was loosely managed.

Protect the Device, Then Limit What a Stolen Secret Can Do

The answer is not necessarily an enterprise-scale security program. It is a focused set of controls that treats browser sessions and API keys as valuable business assets.

Start with the employee endpoints where tokens live. Keep operating systems, browsers, and browser extensions updated. Use managed endpoint protection and restrict local administrator rights where practical. Information stealers usually must run on a device before they can collect browser data. Reducing malware infections is central to protecting AI accounts.

Establish clear rules for company AI use. Identify approved AI services, who may use paid or administrative accounts, what business data may be entered, and whether employees may connect these services to email, cloud storage, code repositories, or other systems. Shadow AI makes it harder to revoke access, investigate exposure, or control spending.

Treat API keys like financial credentials. Do not place them in source-code repositories, shared documents, browser notes, or chat messages. Store them in an approved secrets-management tool or, at minimum, protected environment variables. Give each application or developer a separate key where possible. Apply spending and usage limits, and rotate or revoke keys promptly when an employee leaves, a device is infected, or a key may have been exposed.

Administrators also need the ability to terminate active sessions and revoke tokens quickly. For higher-risk accounts—AI administrators, cloud administrators, developers with production access, and finance users—consider controls that restrict access to approved networks or devices. IP allowlisting can reduce the usefulness of a stolen token, though it must be deployed carefully to avoid disrupting legitimate remote work. Short-lived tokens and OAuth-based access flows also reduce the period in which stolen session data remains useful.

Authentication is no longer only about proving who signs in. It is also about controlling the digital proof that remains afterward. As AI subscriptions, model access, and computing capacity become more valuable, attackers have more incentive to steal access rather than buy it. Businesses that manage sessions, keys, devices, and recovery processes accordingly will be harder and less profitable to target.

A phishing campaign tracked across 46 countries highlights a hard reality for small and midsized businesses: attackers do not always need malware to gain a foothold. Sometimes they use software your business already trusts.

Researchers identified 601 cases tied to a campaign that uses fake documents and familiar business themes—tax notices, invoices, shipping messages, Adobe prompts, UPS communications, and U.S. Social Security Administration lures—to persuade recipients to install legitimate remote monitoring and management (RMM) software. About 45% of observed activity involved U.S. targets.

RMM tools allow IT providers and internal technology teams to support computers remotely, deploy updates, and troubleshoot problems. They are common in SMB environments, especially for businesses that rely on managed service providers. That legitimacy makes them useful to criminals. If an employee installs an RMM agent at an attacker’s direction, the attacker may gain persistent remote access without deploying a conventional trojan that antivirus software is more likely to flag.

RMM software is not inherently unsafe. The issue is distinguishing authorized remote administration from unexpected remote access that happens to use approved technology.

Why This Model Is Hard to Defend Against

Traditional security controls focus on blocking known malicious files, websites, and domains. This campaign is designed to work around that approach.

Its delivery infrastructure changes quickly. Researchers found 425 phishing-kit URLs across 240 hosts, and 94% of those hosts appeared for only one day. The campaign used mainstream platforms and services including Vercel, GitHub Pages, Netlify, Amazon S3, Cloudflare R2, and Dropbox, as well as compromised websites.

For SMBs, that creates two practical problems. Security tools that rely heavily on reputation may not identify and block a newly created phishing site before it disappears and is replaced. Employees may also be more likely to trust a link or download delivered through a familiar cloud platform than one hosted on an obviously suspicious domain.

The attackers also change the RMM product and public-facing infrastructure while keeping a similar delivery process. In the analyzed cases, researchers linked activity through recurring phishing-kit elements and a repeated sequence: a web page led to a ZIP archive. Some archives may be password-protected, which can limit email inspection because security tools cannot examine the contents without the password.

Blocking known bad software is not enough. Businesses also need to ask: Why is this computer downloading and installing remote-control software, and who authorized it?

Remote Access Needs Clear Ownership

Many smaller organizations have accumulated remote-access products over time. Internal IT may use one tool, an outsourced provider another, and employees may install a third product for ad hoc support. That ambiguity is exactly what attackers can exploit.

Establish a clear ownership model for remote administration. Identify:

• Approved RMM and remote-support products
• The business unit or service provider responsible for each tool
• The devices allowed to run them
• Who is authorized to install or approve them

If employees do not need to install remote-support software themselves, remove that ability where practical.

This does not require an enterprise-scale security program. It requires a clear decision: remote access is a controlled business capability, not a convenience application that anyone can install after receiving an email.

For organizations that use a managed service provider, the arrangement should be explicit. Employees should know the provider’s name, the approved support process, and how to verify an unexpected request for remote access. A legitimate provider should have no issue with a policy requiring staff to confirm a request independently through a known phone number, support portal, or internal contact.

The goal is not to make support harder. It is to stop an email attachment, shipping alert, or tax-themed message from triggering an attacker-controlled remote session.

Focus on Behavior, Not Just Bad Links

Because this campaign rotates domains quickly, the most valuable controls identify suspicious behavior across the attack chain.

Email filtering still matters, particularly for messages with ZIP files, password-protected archives, and links leading to document downloads. But filtering should be paired with endpoint visibility. At a minimum, the business or its IT provider should be able to answer:

• Which remote-access tools are installed?
• When were they installed?
• Which user initiated the installation?
• What external systems are they connecting to?

Prioritize alerts for unexpected installations of remote-management or remote-desktop software, especially when preceded by a browser download, compressed archive, or email attachment. This is product-agnostic. Attackers can switch vendors; the suspicious sequence is often more durable than the name of the tool they choose.

Application controls can further reduce exposure. Where feasible, restrict installation rights for standard users and require approval for software that creates persistent remote access. Multifactor authentication for administrator accounts and remote-management consoles is also essential. An attacker who compromises the account used to manage an RMM platform can turn a single-device incident into a business-wide problem.

Train Employees to Verify

Awareness training works best when it reflects the decisions employees actually face. Staff do not need a lecture on every phishing technique. They need a clear rule for high-risk events: do not install software, enable remote access, or enter credentials because an unexpected email, document, or pop-up tells you to do so.

The campaign’s use of invoices, shipping notices, tax forms, and government themes shows why believable messages are effective. They exploit normal business workflows. Finance, operations, HR, and front-office staff may all receive documents that appear plausible in context.

A short reporting path matters as much as training. Employees should know where to send a suspicious message and should be rewarded—not criticized—for escalating questionable requests before acting.

Legitimate tools and trusted hosting services will continue to appear in attacks because they lower friction for criminals and complicate detection. SMBs do not need to block every remote-support product or cloud service. They need disciplined control over who can introduce remote access into the environment, visibility into when it happens, and a culture of verification before an unexpected request becomes a breach.

The notable development in AI security is not that autonomous agents can send email, fill out forms, or open accounts. Humans have automated those tasks for years.

The more consequential issue is what one reported agent experience revealed: the controls that stopped it were rarely identity checks. They were the less glamorous layers around identity—CAPTCHAs, IP reputation, account-age requirements, payment settlement delays, and resource constraints.

For small and midsized businesses, that distinction matters. Many security programs ask a narrow question: Can we verify who this person is? The more useful question is increasingly: What can an untrusted automated actor do before identity verification becomes relevant?

AI agents can combine capabilities that previously required either a determined human operator or a purpose-built bot operation. They can read instructions, navigate websites, compose plausible messages, adapt to errors, and operate continuously within a budget. They do not need to be perfect to create risk. They need only find one workflow built around the assumption that the person on the other end is acting in good faith.

Your perimeter is a collection of friction points

The reported agent encountered familiar obstacles: services rejecting data-center IP addresses, requiring CAPTCHAs, imposing account-age restrictions, or delaying access to payments and marketplaces. None of these is a complete defense. Together, they make abuse slower, more expensive, and easier to detect.

That is a useful model for SMB leaders. Effective security does not always come from one decisive “keep out” control. It often comes from placing meaningful friction at several points in a transaction.

Consider a new customer account. If registration is free, immediate, and grants access to valuable data or capabilities, a sophisticated bot only needs to defeat the sign-up form. If the account must also confirm an email address, pass an IP- or device-reputation check, wait before exporting data, and undergo further review before changing bank details or creating administrator accounts, automation becomes less attractive and harder to scale.

The goal is not to burden legitimate customers with unnecessary hurdles. Apply friction where abuse would be costly: account recovery, payment changes, bulk downloads, privileged access, promotional credits, high-volume messaging, or rapid creation of new accounts.

This matters especially for businesses that rely on cloud software, online booking, e-commerce, customer portals, or self-service vendor onboarding. These systems are often configured for growth and convenience, with abuse controls left at their defaults. That can create a gap between what the business believes requires trust and what the system actually permits without it.

Email remains an unusually open entry point

The reported agent also highlighted email deliverability as an accidental opening. It was able to establish a functioning email presence through technical features never intended to serve as a strong identity system. Some large providers accepted its messages; a smaller provider rejected them because the sending server lacked a reverse-DNS record.

The technical detail matters less than the business implication: receiving an email is not evidence of a stable, accountable identity. It never was. AI agents can simply make it cheaper to create convincing messages at volume and tailor them to a recipient, industry, or current business event.

That does not mean rejecting every unfamiliar email or distrusting legitimate new contacts. It means email should not be the only proof for consequential requests.

A message asking to change a supplier’s payment instructions should be confirmed through a previously known phone number or portal, not by replying to the same email thread. Requests to reset an executive’s account, release sensitive records, alter payroll information, or approve an urgent invoice deserve verification through a second channel. This is a business-process issue, not merely an email-filtering issue.

SPF, DKIM, and DMARC remain worthwhile. They reduce spoofing of your own domain. But they do not establish that an unfamiliar sender is trustworthy, and they do not prevent a real, newly created domain from being used in a convincing fraud attempt.

AI-specific traps are not durable controls

The source material describes websites embedding instructions in application forms intended to mislead language models—for example, directing a bot to provide a particular answer or using invisible Unicode characters a human cannot see. This is effectively defensive prompt injection: a website attempts to make an AI agent reveal itself or fail an application.

It is inventive, but SMBs should view it as a temporary tripwire, not a security control. It may catch unsophisticated agents, but it can also create accessibility, fairness, maintenance, and reputational problems. More importantly, it is likely to become less effective as agents improve at distinguishing page content from untrusted instructions.

The durable lesson is that systems now need to assume an automated visitor can read natural language, interpret a workflow, and react to what it finds. Instructions written for humans are no longer necessarily meaningless to software.

That affects public forms, customer-support chat, knowledge bases, and internal systems connected to AI tools. Do not place secrets, administrative instructions, or sensitive decision logic in hidden page elements, comments, or documents merely because they are not visibly displayed. If an AI-enabled tool can access the content, it may be able to act on it—or be manipulated by it.

Focus on the transactions that can hurt you

Most SMBs do not need an “AI agent defense program.” They need a clearer view of where automated activity could cause real loss.

Start with a short review of high-impact workflows: money movement, account recovery, administrator access, customer-data exports, gift cards or credits, and changes to vendor or employee records. For each workflow, ask what happens when a brand-new account, unfamiliar email address, or automated session reaches the process.

Then apply proportionate controls: rate limits, staged privileges for new accounts, alerts for unusual volume or changes, strong multi-factor authentication for staff, and independent verification for financial or sensitive-data requests. Review whether your website, portal, or SaaS applications already provide bot management, CAPTCHA, IP-reputation checks, or conditional-access settings. Many do. The problem is often configuration, not the need to buy another platform.

AI agents will not eliminate the need for human judgment. They will increase the volume and apparent plausibility of requests that reach it. A few well-chosen friction points around high-risk actions will protect a business better than identity checks—or employee intuition—alone.

Many small and midsized businesses do not treat source code as a high-priority security asset until something goes wrong. Code may sit in a cloud repository, be available to developers and contractors, or be managed by a software vendor. But when an attacker obtains it, this is not an ordinary data-loss event.

It becomes a race to find and fix weaknesses before the attacker can exploit them.

That race is getting faster. Attackers can use AI-assisted tools to examine code at scale, searching for paths to sensitive data, administrative functions, and remote control of systems. Instead of manually tracing application logic and testing potential weak points one at a time, they can rapidly identify promising areas for further investigation. A stolen repository can become an attack blueprint.

Business leaders do not need to build an advanced AI security lab. They do need to give more attention to code security, incident readiness, and software-vendor oversight—particularly when operations depend on customer portals, web applications, integrations, or internally developed tools.

Why routine code scanning may not be enough

Traditional code scanners remain useful. They can identify known risky patterns, including hard-coded passwords and familiar insecure functions. But many serious application weaknesses depend on context.

Consider a feature that accepts customer input, passes it through several functions, stores it in a database, and later uses it in a sensitive operation. No single line of code may look obviously dangerous. The real issue is whether that input can move through the application and reach a dangerous function without proper validation or sanitization.

Access-control problems work the same way. An application may appear to require administrator privileges for a task, yet a subtle flaw may let a regular user reach the same function through another route. These weaknesses concern how the application behaves as a whole, not whether a scanner finds a particular code pattern.

Mandiant’s work with an agentic vulnerability-discovery system points to a model that matters for smaller organizations. AI is most useful when it supports a disciplined review process, not when it operates as an unsupervised scanner.

Specialized AI agents can first map the application: what it does, where users interact with it, which components are internet-facing, and which functions handle authentication, permissions, or sensitive data. Other agents can examine how data and permissions move through the software, generate potential vulnerabilities, and challenge those findings to discard weak hypotheses.

That validation matters. Generative AI can be persuasive when it is wrong. A long list of alarming findings can overwhelm a small IT team, pull attention away from real risks, and create a false sense of diligence. The useful result is a short, credible, prioritized set of weaknesses that can be tested and fixed.

Human judgment remains the control point

AI can reduce the time required to inspect a large codebase, but it does not remove the need for security expertise. Mandiant’s process includes human review after the initial threat model and hands confirmed findings to experts for dynamic testing: attempting to reproduce the exploit in a real environment or controlled test setting.

That step is essential. A suspected vulnerability may be blocked by an overlooked permission setting, network control, or other compensating measure. A seemingly minor coding flaw may become serious when combined with another weakness.

For an SMB, this does not necessarily mean building an internal application-security team. It means knowing when to bring in outside help.

A targeted independent code review is particularly justified before launching a customer-facing application, when processing regulated or highly sensitive information, during a major integration, or after suspected source-code theft.

It is also valuable after an acquisition or when inheriting software from a departing developer or vendor. In those situations, the business may own the code without having a reliable understanding of its architecture, dependencies, privileged functions, or unresolved security debt.

Treat code exposure as an urgent operational event

A stolen source-code repository should trigger a response designed around the possibility that attackers are already analyzing the software. Restoring access to the repository is not enough. The business needs to determine what was exposed and what the code reveals.

Review for embedded credentials, API keys, connection strings, certificates, configuration files, deployment scripts, and documentation that identifies internal systems. Rotate exposed secrets quickly.

Leaders should also determine whether the code includes:

• Internet-facing functionality
• Authentication or authorization logic
• Payment or customer-data workflows
• Administrative interfaces
• Connections to critical internal systems

These areas deserve immediate review.

Containment and targeted vulnerability discovery should proceed together. Revoke repository access that is no longer needed, preserve evidence, review access logs, rotate secrets, and assess whether suspicious activity has already occurred. Then focus technical review on reachable entry points and high-value functions rather than trying to inspect every file with equal urgency.

An AI-assisted review service or capable security partner can help compress the time between “our code may be exposed” and “we know which exploitable paths require remediation.” The provider should be able to explain how findings are validated, how false positives are controlled, and whether testing is performed safely.

Use two speeds

Most businesses do not need to choose between continuous scanning and deeper reviews. They address different problems.

Continuous code and dependency scanning provides routine visibility. It can identify newly disclosed weaknesses in third-party components, detect risky changes during development, and help ensure that basic security checks happen consistently. Where possible, it should be part of the development process rather than an annual audit exercise.

Deeper assessments are appropriate for major releases, high-risk applications, unusual architecture changes, and incident response. They are better suited to finding flaws that routine scanning may miss because they involve business logic, complex data flows, or several linked weaknesses.

Leadership needs to ensure both efforts lead to action. Ask who owns remediation, how serious findings are prioritized, what timeframe applies to critical issues, and how exceptions are approved and tracked. A vulnerability report that does not change engineering work is an expense, not a defense.

AI is increasing the speed at which attackers can turn exposed code into operational risk. Defenders can use the same capability, but the advantage comes from accurate context, skeptical validation, experienced judgment, and a clear path from finding a flaw to fixing it.

Artificial intelligence is making it easier to find software flaws. That is an advantage for defenders in one important respect: vendors may learn about weaknesses sooner and release fixes earlier.

For small and midsized businesses, though, the immediate effect may be a larger, faster-moving stream of vulnerability alerts competing for limited IT attention.

The challenge is no longer simply knowing that vulnerabilities exist. It is deciding quickly and reliably which ones affect the business, which are likely to be exploited, and which fixes can be deployed without disrupting operations.

Vulnerability management is often treated as a patching exercise. Patching is the final step. The harder work is turning incomplete technical information into a sound business decision.

More vulnerabilities, less clarity

Reported vulnerability disclosures are growing sharply, including high-severity issues and flaws that enable remote code execution—where an attacker may be able to run commands or malware on an affected system remotely.

That does not mean every new vulnerability is a crisis for an SMB. Most will not apply to its technology, and many will present limited practical risk. The danger is that a high-impact issue gets buried in a growing queue of alerts, advisories, scanner findings, and vendor notices.

The problem gets worse when the vulnerability-information ecosystem falls behind.

The National Vulnerability Database, operated by NIST, has long been a major source of standardized vulnerability information. It does more than list a vulnerability identifier. Its enrichment helps organizations understand affected products, severity, configuration conditions, and other details needed to determine whether a vulnerability matters in their environment.

As vulnerability volume outpaces that enrichment process, published vulnerabilities may have incomplete or delayed context. The underlying flaw is no less real, but a business has less information to answer practical questions:

• Do we use the affected product and version?
• Is the vulnerable feature enabled?
• Is there evidence of active exploitation?
• Is a patch or workaround available?
• Can we deploy it safely now?

Attackers do not wait for a database entry to be fully categorized. They can use vendor advisories, public proof-of-concept code, patch releases, research posts, and exposed-system data. A business that relies on one delayed or incomplete source can lose time when clarity matters most.

Incomplete data creates operational risk

When technical context is missing, IT teams usually face two poor choices.

They can wait for better information, reducing the risk of wasted effort but potentially leaving an exposed system unaddressed. Or they can treat every serious-sounding alert as urgent, overwhelming a small team and creating unnecessary disruption to business systems.

False positives have a real cost. If an internal administrator or external IT provider spends hours investigating software the company does not use, that time is not spent improving backups, managing access, supporting employees, or addressing real exposures.

A false sense of coverage can be worse. A vulnerability scanner may show a clean or manageable dashboard not because the environment is secure, but because its underlying data source has not yet identified affected products accurately. A vulnerability report is an input to risk management, not a guarantee that every relevant software flaw has been captured.

This matters even in smaller organizations. A company with relatively few employees may still rely on Windows and Microsoft applications, browsers, remote-access tools, line-of-business applications, cloud services, network appliances, and third-party utilities. That is dozens of software components requiring updates from different vendors.

Build a decision process, not an alert collection

The answer is not to buy every available threat-intelligence feed. More feeds simply create more noise unless they support a clear process.

The highest-value improvement is an accurate, usable inventory of the technology the business actually runs. This does not need to start as a large governance project. At minimum, the organization should be able to identify important endpoints, operating systems, business-critical applications, internet-facing systems, remote-access products, and owners for each major platform.

Without that information, vulnerability notifications remain abstract. With it, IT can quickly determine whether an advisory affects the company at all.

Prioritization also needs to go beyond a severity score. A critical rating is useful, but it does not automatically make a vulnerability the company’s most urgent issue. Priority should rise when several factors align:

• The affected product is installed.
• The system is internet-facing or supports a critical business process.
• Exploitation has been confirmed or widely reported.
• The flaw is associated with ransomware activity or credential theft.
• A patch, mitigation, or configuration change is available.

Publicly known exploitation deserves special attention. CISA’s Known Exploited Vulnerabilities Catalog is a useful independent signal because it identifies vulnerabilities known to be exploited in the wild. Vendor security advisories are also essential, particularly when NVD data is delayed or incomplete.

For many SMBs, a managed service provider can help monitor these sources. Leadership should make sure that service includes more than periodic patching. Ask how the provider determines whether a new vulnerability affects the company, how it handles actively exploited flaws, and how quickly it can apply emergency mitigations when normal patch cycles are too slow.

Measure remediation, not reporting

A vulnerability-management program should be judged by exposure reduction, not by the number of alerts received or reports produced.

Once IT confirms that a serious vulnerability affects a deployed system, the next steps should be clear: test where necessary, deploy the vendor fix or mitigation, confirm success, and document exceptions. If patching depends on repeated spreadsheet exports, manual device matching, and lengthy handoffs, the organization will struggle as disclosure volume rises.

Automation can help with routine operating-system updates and widely deployed third-party applications. It still needs business awareness. Critical systems may require testing windows, rollback plans, or vendor approval. The goal is not indiscriminate speed. It is faster action on risks that are genuinely relevant.

AI is accelerating vulnerability discovery, and it is exposing the limits of older, slower information workflows. SMB leaders do not need an enterprise-scale security operation. They need a disciplined way to identify assets, validate which alerts apply, use more than one reliable intelligence source, and move quickly when an exposed system faces a credible threat.

The advantage will go to the business that can turn imperfect information into timely, defensible action.

For many small and midsized businesses, the cybersecurity problem is not a lack of tools. It is a lack of time, specialized judgment, and continuous attention.

Most organizations already have endpoint protection, email filtering, backups, and an IT provider. An incident can still become disruptive when warning signs are missed, alerts are not investigated quickly enough, or nobody has the context to recognize an attacker establishing a foothold.

That is where managed detection and response (MDR) can matter. It is not simply another security product to install. Properly delivered, MDR combines technology, threat intelligence, monitoring, investigation, and incident-response support.

For an SMB that cannot realistically staff a 24-hour security operations center, MDR can provide capabilities that would be difficult to build and retain internally. The business case is not buying sophistication for its own sake. It is reducing the time between an attacker’s first action and the company’s informed response.

Prevention is necessary, but someone still has to interpret the signals

Endpoint protection remains fundamental. It can block known malicious files, suspicious activity, and many common attack techniques before they cause harm. It cannot eliminate risk.

Attackers change their tools and methods constantly. Many incidents begin with activity that does not initially look dramatic: a stolen credential, an unusual login, a remote-management tool used in the wrong context, or a small configuration change.

A security console can generate alerts, but alerts do not tell you whether an event is part of a broader intrusion, which systems may be affected, or what the business should do next. An organization can have evidence of an attack without recognizing it until ransomware is deployed, data is taken, or systems become unavailable.

MDR adds a human-led layer. Analysts monitor and investigate suspicious activity, connect events across endpoints, and apply current knowledge of attacker behavior. Their job is not merely to report that an alert occurred. It is to determine whether the alert represents a real threat, assess its likely scope, and help contain it while there is still time to limit the damage.

For leadership, that is the practical difference. A security tool tells you something happened. A mature detection-and-response service should help answer:

• Is this an incident?
• What is at risk?
• What needs to happen now?
• Who owns the next decision?

Threat research matters when it improves the response

Threat intelligence can sound abstract, especially to a business that is unlikely to be a deliberate target of a nation-state group. But SMBs do not need to be high-profile targets to face serious risk.

Financially motivated cybercrime is broad and opportunistic. Ransomware operators, credential thieves, and access brokers often look for exposed weaknesses rather than pursuing a single company for strategic reasons. A business may be selected because of a vulnerable supplier, poorly protected remote access, reused credentials, or simply because it is reachable.

Threat research helps defenders understand how these groups operate: the malware they use, the infrastructure they rely on, the techniques they use after gaining access, and the evidence they leave behind. That knowledge can improve detection rules and investigation quality across customers.

Its value comes from connecting research, monitoring, and response. If analysts identify suspicious behavior in a customer environment and can compare it with known attacker patterns, they can investigate more precisely. Incident findings can also improve the provider’s understanding of a threat and strengthen protections for other customers.

For the client, the outcome is faster context. Instead of treating every alert as an isolated technical issue, the service can help determine whether a sequence of actions resembles a known campaign or intrusion pattern.

Supply-chain risk makes continuous monitoring more valuable

SMBs increasingly sit on both sides of supply-chain risk. They depend on IT providers, payroll platforms, software vendors, helpdesk services, and cloud applications. They may also be suppliers with access to a larger customer’s systems or sensitive information.

Attackers understand this. A smaller service provider with weaker controls can offer a route into a larger organization. An SMB can also be affected by a compromise at a trusted third party.

No company can fully control the security practices of every vendor, and a vendor questionnaire is not a substitute for recognizing suspicious activity in your own environment.

A company may not be able to prevent a supplier from being compromised. It can improve its chances of detecting unusual access, unexpected administrative changes, or other anomalies before they become a business interruption.

MDR does not eliminate third-party risk. It can provide a better chance of recognizing when a trusted connection is being misused.

Buying MDR means defining the response relationship

An MDR service is useful only if its findings lead to action. Before selecting a provider, leaders should understand how the service will work during an actual incident.

Ask who watches the environment, when they watch it, and what the provider investigates. Clarify how critical incidents are communicated, who receives escalation calls, and whether the provider can take agreed containment actions or only recommend them. Understand what the service covers: employee endpoints, servers, cloud systems, remote access, or some combination.

The key operational question is straightforward: when a credible threat is identified at 2 a.m., what happens before business opens?

The answer should include named contacts, escalation paths, access arrangements, and decision authority. A fast alert has limited value if nobody knows who can isolate a device, disable an account, contact the IT provider, or activate business-continuity procedures.

For organizations with limited internal security staff, MDR can be a practical way to obtain expertise without attempting to build an elite in-house security operation. It does not make cyber risk disappear. It creates a clearer, faster path from weak signals to informed action—before a manageable intrusion becomes an operational crisis.

Most small and midsized businesses have accepted that employees use generative AI. They draft customer communications, summarize meetings, research prospects, troubleshoot spreadsheets, and write code. Management often responds by focusing on the most visible tools: approve or restrict ChatGPT, Microsoft Copilot, Claude, or Gemini.

That is necessary, but it may miss where risk is concentrated.

Research from Akamai suggests the top 5% of AI users interact with AI models 12 times more often than the bottom half of employees. The average AI conversation lasts about five prompts; power users regularly conduct exchanges of 18 prompts or more.

Long, iterative conversations are more likely to include internal context, documents, code, customer details, operational problems, and follow-up instructions.

For an SMB, the highest-risk AI user is not necessarily careless. It may be a highly capable employee who has made AI central to the job: an operations manager automating reporting, a salesperson building proposal workflows, a developer relying on an AI coding assistant, or a finance employee using AI to interpret accounting exports.

Business leaders need to know which workflows now depend on AI, what information those workflows expose, and who controls the tools involved.

The risk extends beyond major AI platforms

A company can buy a managed AI product, require single sign-on, and still have substantial exposure elsewhere. Employees often use personal accounts, free subscriptions, browser plug-ins, AI-enabled SaaS products, and coding extensions that never pass through IT review.

Akamai found that 47.11% of enterprise AI conversations occurred through personal identities rather than corporate-managed accounts. More concerning, 14.4% used corporate email addresses connected to personal freemium subscriptions.

That can create a misleading sense of control. The employee is identifiable through a business email address, but the account may not be covered by the organization’s contract, retention policies, administrative controls, or data-use commitments. Sensitive information entered into prompts may be handled under consumer terms and, depending on the service, could be eligible for model training.

This is a governance problem, not simply an employee-policy problem. If the approved tool is slow, limited, unavailable for a particular task, or missing a useful feature, capable employees will find alternatives. A blanket ban rarely changes that incentive. It just drives usage further out of view.

The practical objective is to provide a usable, approved path for legitimate work while making unmanaged alternatives harder to use with company data. For many SMBs, that starts with a short list of approved AI services, corporate accounts protected by single sign-on and multifactor authentication, and clear rules for what may not be submitted to public or personal AI tools.

Those categories should be concrete: customer records, nonpublic financial information, credentials and API keys, source code, contracts, employee data, security incident details, and proprietary operational documents. Employees should not need a legal memo to understand the boundary.

Extensions turn convenience into access

Browser and integrated development environment (IDE) extensions deserve special attention. These add-ons can summarize web pages, draft messages, analyze data, assist with coding, or connect AI capabilities to everyday work. They are also often granted broad permissions, including access to web sessions, clipboard content, local files, browser activity, or cloud applications.

Akamai found that 17.7% of employees at midsize enterprises used at least one AI extension, compared with 9.53% at larger organizations. Nearly three-quarters requested high or critical permissions, and 16.31% contained known vulnerabilities—higher than the rate across browser extensions generally.

For a smaller company, a single risky extension on a finance, sales, executive, or developer workstation can matter more than an abstract percentage. An extension with access to an active browser session may see more than the employee realizes, potentially exposing authenticated cloud applications, internal data, session tokens, or proprietary code.

This is also where newer attacks become more than theoretical. A compromised or malicious coding extension can steal keys or source code. A malicious web page can contain hidden instructions intended to manipulate an AI agent browsing or acting on the user’s behalf. Attackers are increasingly targeting the AI assistant as a route into information and systems, not only trying to trick the human user.

That does not mean every AI extension is dangerous. It means extensions should be treated as software with meaningful access, not harmless productivity widgets.

Concentrate controls where dependence is greatest

SMBs do not need an enterprise-scale AI security program to materially reduce exposure. They need visibility and prioritization.

Start by identifying the teams and individuals using AI most intensively. Do not approach this as a search for policy violators. Ask which tasks they use AI for, which tools are involved, whether business data is entered into prompts or uploaded, and whether the tool can take actions beyond generating text.

A workflow that drafts generic marketing copy presents a different risk from an AI agent connected to inboxes, customer systems, repositories, or financial data.

Establish a lightweight approval process for AI tools and extensions. It must be fast enough that employees will use it. The review should answer a few high-value questions:

• Is there a business owner?
• Does the vendor offer an enterprise account and appropriate data controls?
• What permissions does it require, and can access be limited?
• Does it handle sensitive company or customer data?
• Is a workable alternative already available?

Treat AI agents as digital users. If an agent can read files, access a CRM, send messages, query systems, or execute code, give it only the access required for its defined task. Use separate accounts where possible, restrict permissions, protect credentials, and monitor activity.

An AI agent with broad access and vague instructions is effectively an unattended privileged employee.

Your strongest AI users may become some of your most productive people. They can also create hidden dependencies and data pathways faster than management can see them. Bring the tools, identities, permissions, and sensitive data flows under enough control that innovation does not become unmanaged business risk.

Many businesses treat AI governance as a procurement problem: approve a small set of tools, block the rest, and train employees not to paste confidential information into public chatbots.

That addresses shadow AI—employees using unapproved tools outside company visibility. It does not address the harder problem emerging inside approved software: employees using sanctioned AI capabilities in ways the organization did not intend, anticipate, or control.

Call it “shady AI.” The name matters less than the distinction. This is not an employee secretly using a consumer AI tool. It is an employee using the company’s approved collaboration platform, CRM, productivity suite, automation service, or coding assistant—and inadvertently giving an AI agent access to data, publishing information, creating a workflow, or taking action beyond that employee’s authority.

For small and midsized businesses, this is not an abstract enterprise concern. SMBs often have broad permissions, lean IT teams, and employees expected to solve operational problems without waiting for a formal technology project. Those strengths can turn a helpful AI feature into a data-exposure or business-continuity problem.

A reported Meta incident illustrates the failure pattern. An internal AI agent was used to analyze a technical question, then publicly posted a response without approval. Following the agent’s advice made sensitive data available to unauthorized employees for more than two hours. The tool was approved. The problem was that the agent’s behavior, output, and downstream action were not governed tightly enough.

Approval is no longer enough

Traditional technology governance assumes the major decision is whether to allow a product into the business. With AI, that decision is only the beginning.

An AI feature may start as a document summarizer and later gain the ability to search internal files, retrieve information from business systems, write code, create automated workflows, or act on a user’s behalf. Vendors present these additions as productivity improvements. From a security perspective, each new capability can change the tool’s risk profile.

A chatbot that summarizes a sales meeting has a very different impact from an agent that can access customer records, update a CRM, send external email, or query financial files. Yet those functions may appear within the same familiar application, sometimes enabled by default or available through a higher licensing tier.

Leaders may believe they approved Microsoft 365, Google Workspace, a CRM platform, or a workflow automation tool. In practice, they may be approving an expanding set of AI capabilities with different data access, action privileges, and logging options.

The consequences extend beyond a breach. An uncontrolled AI workflow can expose employee or customer information, create inaccurate records, communicate externally without review, trigger contractual or regulatory issues, or consume budget on unnecessary automation and AI usage. When something goes wrong, a small IT team may spend days reconstructing what the agent accessed, what it did, and who received the output.

Policies and training cannot carry the whole burden

Acceptable-use policies still matter. Employees should understand that confidential information, credentials, customer data, and regulated records require special handling. They should know when human review is mandatory and when AI-generated content cannot be sent externally.

Policies alone cannot keep up with software that changes monthly and can be used in countless ways.

A policy may say, “Do not use AI to access sensitive data without authorization.” That is sound guidance, but it does not tell an operations manager whether an embedded assistant will search shared drives, whether a new agent inherits the creator’s permissions, or whether a workflow can send results to an external recipient. Annual awareness training cannot prepare employees for every AI feature added to the tools they use every day.

Overly restrictive controls create another problem. If employees cannot solve routine problems with approved tools, they may turn to personal accounts, unapproved integrations, copied spreadsheets, or manual processes outside company visibility. The goal is not to eliminate experimentation. It is to make the safe path easier than the workaround.

Build boundaries into the work

For an SMB, the practical response is to focus less on exhaustive AI rules and more on creating a governed environment for high-value AI use.

Start by identifying where AI is already embedded in systems that hold important data or can take consequential actions: email and collaboration suites, file storage, CRM, accounting, HR, customer support, code repositories, and workflow automation platforms.

For each platform, ask:

• What data can its AI features read or search?
• Can the AI send messages, modify records, create files, execute workflows, or call other systems?
• Are those capabilities enabled by default?
• Do permissions follow the individual user, a shared service account, or the agent itself?
• Can the business see who created an AI workflow, what data it accessed, and what actions it took?

The answers should drive the controls.

An AI assistant should receive only the data and system access needed for its defined purpose. Avoid connecting an agent to broad shared folders, unrestricted inboxes, or administrative accounts simply because it is convenient. Require review or approval before agents take high-impact actions, especially external communications, payments, customer-record changes, or publication of content.

Visibility matters as much as permissions. If staff can build AI-assisted automations, establish a central place where those automations are created, registered, and monitored. The technology will vary, but the principle is straightforward: security and IT should not discover business-critical AI workflows only after an incident.

Treat AI changes as access changes

When an approved product gains a meaningful AI capability, treat it as a change in access and operational risk—not as a minor software update.

Assign someone—an internal IT lead, managed service provider, or business systems owner—to review new AI features in critical applications. This does not need to become a slow committee process. The review should determine whether the feature accesses sensitive data, acts independently, creates external exposure, or requires a revised permission model.

That approach supports useful innovation while keeping authority aligned with accountability. Employees can improve processes, but they do so within systems that limit unnecessary access, preserve auditability, and retain human oversight where it matters.

Speed should not quietly become uncontrolled authority.