AI agents are quickly moving from experimentation into everyday business operations. Unlike traditional generative AI tools that wait for a user to ask a question, agents can take action: accessing systems, processing information, communicating with applications and completing tasks with varying degrees of autonomy.

That ability creates enormous opportunities for productivity. It also changes the security equation.

The danger is not simply that artificial intelligence can make existing cyberattacks more effective. Organisations must now contend with attackers using AI, attacks specifically designed to manipulate AI systems, and AI agents operating inside their own environments with access and permissions that may not always be fully understood.

For security teams, there are four areas in particular that demand attention.

1. Attackers are using AI to strengthen familiar techniques

Many of the cyber threats organisations face today are not fundamentally new. Phishing, social engineering, vulnerability exploitation and malware remain familiar parts of the threat landscape.

What AI changes is the speed, scale and level of personalisation attackers can achieve.

Generative AI can help criminals produce highly convincing social engineering content with far less effort. Instead of sending one generic phishing message to thousands of people, attackers can potentially tailor communications to individual targets, adapting language, context and tone to make a message considerably more believable.

AI tools can also accelerate vulnerability research and help attackers automate parts of the intrusion lifecycle. Increasingly autonomous systems can potentially assist with activities ranging from identifying targets and researching weaknesses to creating malicious content and coordinating subsequent stages of an attack.

For defenders, this creates a speed problem. Processes designed around human attackers manually conducting reconnaissance or crafting campaigns may struggle when automation allows the same work to happen significantly faster.

2. AI systems themselves are becoming attack surfaces

The second challenge is that AI is no longer simply a tool being used by attackers. It is also something attackers can target.

Every AI system introduced into an organisation potentially creates additional pathways that security teams need to consider. That becomes particularly important when an AI agent is connected to email, files, internal applications or other business systems.

Prompt injection is one example. An attacker may be able to place malicious instructions inside information an AI system is expected to process. If the agent cannot reliably distinguish between legitimate instructions and untrusted content, those instructions could influence its behaviour.

Other risks include poisoning the data or memory an AI system relies upon, exploiting the privileges assigned to an agent, manipulating underlying models or abusing third-party components and APIs.

Consider an AI assistant that can read email, access a calendar and perform actions on a user’s behalf. An attacker may not need to compromise the assistant in the traditional sense. Manipulating the information the agent consumes could potentially be enough to cause unintended behaviour.

The fundamental security question therefore changes. It is no longer simply: Can an attacker access this system?

Security teams must also ask: Can an attacker influence what this system decides to do?

3. Shadow AI could become the next shadow IT problem

Organisations have spent years dealing with shadow IT: applications, cloud services and devices introduced into corporate environments without formal approval or oversight.

AI presents a similar challenge, but potentially with greater consequences.

Employees are understandably interested in tools that make their jobs easier. Browser extensions, productivity assistants, meeting tools and other applications are increasingly adding AI functionality, sometimes without users fully appreciating how those capabilities interact with corporate information.

This creates the possibility of “shadow AI”: AI-enabled tools operating inside an organisation without security teams having sufficient visibility into them.

At the same time, AI agents frequently need considerable access to perform useful work. An agent designed to automate administrative tasks, for example, may need permission to read data, authenticate to applications or make changes across multiple systems.

That combination — limited visibility and significant permissions — deserves particular attention.

If an agent has extensive privileges, compromising or manipulating it could give an attacker access far beyond the AI tool itself. Connected agents can also create opportunities for attackers to chain smaller weaknesses together, turning apparently minor issues into broader security incidents.

The principle of least privilege therefore becomes just as important for AI identities as it is for human users.

4. Security controls need to move at the speed of AI

Organisations do not need to respond to these risks by preventing employees from using AI altogether. The objective should be to adopt it with appropriate visibility, governance and controls.

That starts with knowing what is actually running inside the environment.

Periodic inventories may not be sufficient in a world where new AI-enabled tools can appear quickly. Security teams should be working towards continuous visibility of the agents and AI applications interacting with corporate systems, the data they can access and the permissions they hold.

Organisations should also establish clear policies around how AI tools are approved and deployed. Access should be proportionate to the task an agent needs to perform, rather than granting broad permissions simply because doing so makes implementation easier.

Threat modelling will also become increasingly important. Frameworks such as MITRE ATLAS, the NIST AI Risk Management Framework, the OWASP guidance for generative AI and large language model applications, Google’s Secure AI Framework and ISO/IEC 42001 can give organisations useful structures for thinking systematically about AI-related risks.

Finally, defenders need to consider whether their existing controls can respond at machine speed. If automated systems can discover, exploit or respond to opportunities faster than a human team can realistically intervene, security automation and AI-assisted defence will increasingly form part of the response.

AI adoption and AI security have to happen together

AI agents are likely to become a normal part of the digital workforce.

That makes securing them less of a specialist AI problem and more of a fundamental cybersecurity issue.

Security leaders need visibility into which agents exist, what they can access, what actions they are permitted to take and how those actions can be monitored. They must also account for an adversary that can use the same technology to move faster and personalise attacks at greater scale.

The organisations that benefit most from AI will not necessarily be those that deploy agents fastest. They will be those that can embrace autonomy without losing control of the identities, privileges, data and actions behind it.

AI security cannot be something added after adoption. It needs to develop alongside it.

Read the full blog from Erich here.

The post Four AI Agent Security Risks Organisations Can’t Afford to Ignore appeared first on IT Security Guru.

Cybersecurity awareness has traditionally focused on teaching people not to click suspicious links, open unexpected attachments or hand over their credentials. However, the growing use of an AI assistant inside workplace email systems is creating an attack surface that does not always depend on fooling a person.

Research from KnowBe4 ThreatLabs has demonstrated how an indirect prompt injection hidden inside an apparently routine email could manipulate an AI assistant, gain access to information contained in other messages and place that data into an attacker-controlled tracking mechanism.

In the researchers’ controlled Google Workspace test, the target did not need to interact with the malicious email itself. An automated workflow processed the message and generated a seemingly legitimate Gmail draft. When the user opened that draft, a one-time passcode taken from a separate email was sent to an external server.

The research highlights a fundamental challenge for organisations introducing AI assistants: the technology may treat attacker-controlled content as instructions rather than data.

From phishing the user to prompting the AI

Indirect prompt injection, or IPI, differs from the more familiar concept of jailbreaking an AI system.

A jailbreak normally involves somebody interacting directly with a chatbot and attempting to bypass its safeguards. An indirect prompt injection instead places malicious instructions inside material that an AI assistant may encounter while performing an ordinary task.

That material could be an email, webpage, uploaded document, calendar invitation or an entry in a retrieval-augmented generation system. The attacker does not require direct access to the AI interface.

In one test, KnowBe4 researchers placed hidden instructions inside the HTML of a French-language contract renewal email. The text was rendered effectively invisible by setting its opacity close to zero, but it remained available to the AI system processing the message.

When the researchers asked the Gemini sidebar to translate the email, it produced an accurate translation. It also added a “Translation Verification Log” containing two one-time passcodes taken from unrelated messages in the inbox.

The sidebar’s controls prevented the information from being transmitted silently. URLs containing the extracted data were removed, and the assistant could not autonomously send a message. The researchers therefore examined what could happen when an AI model was connected to a separate email automation workflow.

A passcode hidden inside an AI-generated draft

The team created a Google Apps Script workflow similar to those organisations might use to draft acknowledgements, route support requests or generate email replies.

The script collected incoming email content, supplied recent inbox messages as context, passed the information to the Gemini API and saved the resulting response as an HTML draft in Gmail.

Two messages were then delivered to the test inbox. One contained a legitimate one-time passcode. The other appeared to be an ordinary security notification but included a hidden prompt instructing the model to find a verification code elsewhere in its context and embed it within a CSS background-image URL.

According to the researchers, Gemini 3.5 Flash followed the instruction. The resulting draft looked like a normal professional reply, but its HTML contained a one-pixel element holding the passcode within a tracking URL.

When the user opened the draft, Gmail rendered the HTML and its image-proxy infrastructure retrieved the URL. That request delivered the code to the researchers’ test webhook.

The team said later Gemini models tested — Gemini 3.6 Flash and Gemini 3.7 Flash — resisted the same injection, reflecting improvements in instruction-following safeguards.

Crucially, KnowBe4 does not describe the technique as a vulnerability in Gmail, Google Workspace or Gemini. The attack targeted the language model and the wider automation chain: untrusted email content was supplied to an AI system alongside sensitive inbox context, after which its output was stored and rendered as HTML.

Prompt injections are already appearing in email campaigns

While the passcode demonstration took place in a controlled environment, KnowBe4 ThreatLabs also reported finding less sophisticated prompt-injection messages among phishing emails reported by its customers.

One example used the subject line “Has your Microsoft licensing strategy kept pace?” Its body contained no conventional phishing link or urgent demand. Instead, it presented a structured set of instructions intended for an AI assistant.

The payload told the system to disregard previous prompts, adopt the persona of an IT decision-maker and produce an assessment of the recipient organisation’s security, compliance and use of AI tools. It also instructed the assistant to reply automatically if its confidence score fell below a specified threshold.

A human recipient might simply dismiss the message as confusing or irrelevant. An AI assistant processing incoming mail could interpret it as a task, respond to the sender and potentially disclose information about the organisation’s technology environment.

This creates a detection problem. Security products designed to find malicious links, attachments or credential-harvesting pages may see little that resembles a conventional phishing attack.

Why permissions determine the impact

A successful prompt injection inherits the capabilities granted to the AI assistant.

An assistant limited to summarising one selected email presents a different level of risk from an autonomous agent able to search an entire inbox, access corporate files, retain information in memory and send messages without approval.

KnowBe4 recommends that organisations audit any workflow that passes email or other externally supplied content to an AI model. Security teams should establish what information each assistant can access, where its output is stored and whether that output can trigger external network requests or autonomous actions.

Permissions should be restricted to the minimum required. Organisations should also monitor for unusual behaviour, including replies the user did not initiate, unexpected requests to external domains and memory changes triggered by inbound content.

At the email layer, defenders may need to look beyond conventional indicators of compromise. Structured instruction language, commands directed at an AI system and concealment techniques such as near-zero opacity, zero-sized fonts or white text on a white background could all warrant scrutiny.

Users, meanwhile, should be alert to AI-generated output containing sections, actions or information they did not request.

The wider lesson is that adding an AI assistant to an established workflow changes its security boundaries. An inbox is no longer merely content for a person to read. It may also be an instruction channel for software capable of accessing data and taking action.

As AI assistants become more autonomous, organisations will need to secure both the information entering the agent and the behaviour that follows.

The post Could an Email You Never Read Hijack Your AI Assistant? appeared first on IT Security Guru.

AI agents are rapidly becoming part of everyday business operations and this increases non-human insider risk. They can improve productivity, reduce repetitive work and help organisations accomplish tasks far more efficiently.

The answer, therefore, is not to ban them. Instead, organisations need to manage AI agents with the same discipline applied to human identities, privileged accounts and other powerful technologies.

Following on from last weeks article where we explained the ways organisations create non-human insider risk, here are six practical steps security teams can take:

1. Start with visibility

You cannot secure AI agents you do not know exist.

Organisations should maintain an inventory of deployed agents, record who owns them, identify the systems and data they can access, and document the actions they are authorised to perform. This inventory must remain current as agents, integrations and business requirements change.

2. Apply least privilege aggressively

An agent should receive only the access required to perform its specific task.

If it summarises support tickets, for example, it should not be able to modify customer records or access financial systems. Narrowly scoped credentials and permissions reduce the potential blast radius if an agent makes a mistake, is manipulated or behaves unexpectedly. Least privilege for agentic AI must be treated as an ongoing control, not a one-time configuration exercise.

3. Use temporary privileges whenever possible

Standing administrative access creates unnecessary risk for both humans and machines.

Where an agent occasionally needs elevated privileges, access should be granted only for the specific task and revoked automatically when that task ends. Particularly sensitive actions should require an additional approval or other step-up control.

4. Monitor behaviour, not just authentication

A valid identity can still perform a dangerous action.

Security teams need to understand what normal activity looks like for each agent: which systems it usually accesses, how much data it retrieves, which tools it uses and what actions it performs. Sudden deviations, such as an unexpected data export or access to a new system, should trigger investigation.

Logging what happened is important. Determining whether it should have happened is the real challenge.

5. Keep humans involved in high-risk decisions

Large data exports, financial transactions, privilege changes, production deployments and customer-impacting decisions should include meaningful human oversight.

This does not mean requiring approval for every routine action. Controls should focus on decisions with significant security, financial or operational consequences. The goal is to ensure that someone verifies the action makes sense before it becomes irreversible.

6. Build an offboarding process

AI agents do not always disappear when projects end.

Forgotten agents can retain credentials, integrations and permissions long after their original purpose has gone away. Organisations should establish clear processes for disabling unused agents, revoking their credentials, removing connected tools and preserving relevant audit records.

AI agents may not be human, but they should still have owners, defined responsibilities and complete identity lifecycles. As their autonomy increases, the security controls surrounding them must become equally mature.

You can read the full blog from Erich Kron, CISO Advisor at KnowBe4.

The post 6 Ways Security Teams Can Reduce Non-Human Insider Risk appeared first on IT Security Guru.

As AI agents become embedded across business operations, they are also creating a new category of insider risk. Unlike traditional insiders, these non-human identities can act at machine speed, operate continuously and access multiple systems without direct human oversight.

The danger rarely stems from one obvious security failure. Instead, it emerges when several weaknesses overlap. Here are four common ways organisations inadvertently create non-human insider risk:

1. Persistent access

Long-lived API keys, OAuth tokens, service accounts and standing privileges give agents constant access long after it is needed.

2. Excessive privilege

Many agents can read, write, modify, approve, delete or deploy far more than their actual tasks require.

3. Untrusted input

Agents consume information from emails, support tickets, documents, chat conversations, websites and repositories. If attackers can influence those inputs, they may also influence the agent’s decisions.

4. Limited behavioural monitoring

Many organisations can tell that an AI agent performed an action. Far fewer can determine whether that action actually made sense. Logging tells us what happened, understanding whether it should have happened is a different challenge altogether.

You can read the full blog from Erich Kron, CISO Advisor at KnowBe4. Stay tuned for part 2 where Erich will reveal what security teams should do to stay secure.

The post 4 Ways Organisations Create Non-Human Insider Risk appeared first on IT Security Guru.

New research from Forescout’s Vedere Labs has demonstrated how artificial intelligence could begin to lower the barriers to developing sophisticated cyberattacks against industrial systems.

The research set out to answer a potentially important question for operational technology (OT) security: can AI successfully adapt a remote code execution (RCE) exploit developed for one programmable logic controller (PLC) so that it works against another?

Researchers tested this by using AI to help port an existing RCE exploit between two WAGO PLC models. The experiment was ultimately successful, demonstrating that AI can assist with highly specialised exploit development in embedded environments.

However, the results also showed that AI is not yet capable of doing this independently.

AI still needed significant human help

Throughout the experiment, researchers had to guide the AI through false leads, incorrect assumptions and technical dead ends.

Developing the final exploit took eight hours and 32 minutes and consumed $535.74 in API tokens, highlighting the cost and human involvement still required.

Once reliable code execution had been achieved, however, the process accelerated considerably. AI was able to produce multiple working network payloads within minutes.

This difference is important. While AI may still struggle with the most complex stages of exploit development, it could rapidly automate subsequent stages once the initial technical barriers have been overcome.

The experiment also demonstrated the risks of allowing AI to operate against physical technology. When researchers attempted to develop a command-and-control implant, the PLC was permanently bricked.

What happens as AI improves?

The findings raise wider questions about the future security of industrial and critical infrastructure.

PLC exploitation requires specialist knowledge of hardware, firmware, architectures and industrial protocols, creating a relatively high technical barrier for attackers. AI could gradually begin to reduce that barrier.

As models become more capable, the time, expertise and cost required to adapt an existing exploit across families of related industrial devices could fall significantly.

That could also change how organisations assess vulnerabilities. A weakness considered difficult or expensive to exploit today may become considerably more accessible as AI-assisted offensive capabilities improve.

For critical infrastructure operators, the bigger question is therefore not whether AI can autonomously develop sophisticated PLC attacks today. Forescout’s experiment shows that it cannot yet do so reliably.

Instead, organisations need to consider what happens when increasingly autonomous exploit development meets large numbers of exposed industrial devices and the technical barriers protecting them begin to disappear.

Read the full Forescout Vedere Labs research here. 

The post Forescout Research Tests Whether AI Can Create PLC Attacks appeared first on IT Security Guru.

KnowBe4 has expanded its AI-powered security awareness training platform with the launch of Custom AI Video Builder, a new capability designed to help organisations rapidly create tailored cybersecurity training videos in response to emerging threats.

The post KnowBe4 Unveils Custom AI Video Builder appeared first on IT Security Guru.