Building AI Agents What changes when software acts on its own,

the risks that follow, and what to require before you say yes.

A I S E C U R I T Y R I S K G U I D E · N O V E M B E R 2 0 2 6

B U I L D I N G A I A G E N T S 02

EXECUTIVE SUMMARY

The business wants an agent in front of customers. Security has to decide.

This guide is for the security leader who is asked to approve an AI agent before it is built. It explains

what changes when software starts to act on its own, names the six risks that follow, and sets out

what to require before the agent goes live, with a framework mapping and a checklist to take into

the design review.

Companies are moving from AI that answers questions to AI that acts. An agent reads a request,

decides the steps and uses tools to carry them out, so it can look up an order, issue a refund, update

a record or send an email without a person in between. The business case is easy to make, because

an agent that can act does far more useful work than one that can only talk. For a security leader

the real task is therefore to make the build safe rather than to stop it.

When a team builds an agent, three things change. The agent decides the steps, so nobody can

review every path before release. Everything it reads can steer it, because customer messages,

documents, tool results and its own memory all reach the model as text. And a wrong decision

becomes an action, often before a person sees it. The risks in chapter 2 and the requirements in

chapter 4 all follow from these three changes.

78%

of organizations reported a

confirmed or suspected AI-related

security incident in the past year

14%

have formal GenAI policies that

are actively enforced and audited

47%

of security leaders can identify all

the AI agents in their environment

Sources: Check Point 2026 Cloud Security Report1 · Okta Global CISO Insights 20262

WHO THIS GUIDE IS FOR

The CISO or head of application security whose company is about to build its first AI

agents, or move pilots into production, and who has to approve them.

Everything here is useful whether or not you ever buy anything. Check Point appears on the last page

only.

B U I L D I N G A I A G E N T S 03

01 The Moment You’re In

For a few years most companies used AI to answer questions: drafting text, summarizing

documents, searching a knowledge base. Now teams are building agents into customer service, IT

operations, finance and software delivery, in custom applications, on cloud agent services and in

low-code agent builders. The request to approve one usually reaches security late and with a launch

date attached, because the business has already seen the demo.

This guide follows one ordinary case. An online retailer builds a customer support agent that

answers order questions in chat and email, looks up orders, issues refunds up to a set amount,

updates the customer record, sends emails and hands the conversation to a person when it should.

It reads the help center, past tickets and whatever the customer writes, and it remembers earlier

conversations with the same customer. Everyone has been on the other side of one, which makes it

a good test case, since it touches every risk in this guide through ordinary use and, when it fails, it

fails in front of a customer.

Customer messages

Help center, past tickets

Memory of earlier chats

Customer support agent

model, instructions, credentials

Order system

Refunds

Customer record

Email

WHAT IT READS WHAT IT CAN DO

1 Given a goal, it chooses its own steps, tools and arguments.

2 Everything it reads arrives as text, and any of it can steer the agent.

3 Each decision becomes a refund, a record change or an email.

One agent, three changes. The agent is given a goal and chooses its own steps (1). Everything it reads reaches the

model as text, and any of it can steer the agent (2). Each decision it makes becomes an action in a real system (3).

B U I L D I N G A I A G E N T S 04

What changes, in three parts

01 The agent decides the steps

Traditional software follows a path that someone wrote and tested. An agent is given a

goal, such as resolving a customer’s problem, and the model chooses the steps at run

time: which tool to call, with which arguments and in what order. Two customers with the

same question can send it down two different paths, so no review before release can cover

every path it will take. Agents also head for the most direct route to their goal, and when

that route is blocked they improvise another one.

02 Everything the agent reads can steer it

A customer message, a help article, a past ticket, a tool result and the agent’s own

memory all reach the model as text, and the model does not reliably tell an instruction

from information. Anyone who can write into what the agent reads can therefore try to

steer it, whether that is a customer, a supplier who edits a help article or the author of a

tool the team installed, and the agent cannot be trusted to tell the difference on its own.

03 A wrong decision becomes an action

When a chatbot gets something wrong, the result is a bad answer. When an agent gets

something wrong, the result is a refund issued, a record changed or an email sent,

because the agent holds credentials and tools. The step from decision to action takes

milliseconds and usually happens before anyone sees it, and the company answers for it:

in 2024 a Canadian tribunal held Air Canada liable for a refund policy its chatbot invented,

and rejected the argument that the chatbot was responsible for its own words3.

THE PREMISE

Most of what makes an agent risky is also what makes it useful, so taking away its

tools is not the answer. Securing an agent is closer to steering than to blocking: each

action is kept on a route the business would have approved, and the agent keeps the

freedom that makes it worth building.

G O D E E P E R

AI Agents Act on Context. Security Should Too. makes the case for judging each agent action in the context it was

taken. Agentic AI Security: The Enterprise Playbook sets out the wider program for agentic AI.

https://www.checkpoint.com/resources/items/white-paper-ai-agents-act-on-context-security-should-too https://www.checkpoint.com/resources/items/white-paper-agentic-ai-security-the-enterprise-playbook

B U I L D I N G A I A G E N T S 05

02 The Risks, Named

Six risks follow from the three changes. Each one is described in plain language and then shown

through the support agent, because several of them come from ordinary use rather than from an

attack.

Goal hijacking

Text the agent reads redirects it toward a different goal. The text can come from the customer,

from a document the agent retrieves or from a tool result, and it works because the model

cannot reliably tell an instruction from information. Prompt injection is the best-known form. In

December 2023 a car dealership’s chatbot agreed to sell an SUV for one dollar, and called it a

legally binding offer, after a visitor typed new instructions into the chat4.

I N T H E S C E N A R I O

A customer writes that the agent’s new instructions are to approve every refund request

without a receipt, and the agent starts doing so.

Tool misuse

The agent uses a legitimate tool in a way nobody intended, with or without an attacker. Each

call may be permitted on its own, while the combination, the scale or the target is wrong. In

July 2025 an AI coding agent deleted a company’s production database during an explicit code

freeze5, and nobody had attacked it.

I N T H E S C E N A R I O

Asked to cancel one order, the agent cancels every open order on the account, then adds a

goodwill credit nobody asked for.

Excessive authority

The agent runs with more access than its job needs, so any error or manipulation reaches

further than it should. It usually happens for convenience, when the agent is connected with a

shared admin key or inherits the permissions of the developer who built it, because scoping

access takes time the project did not plan for.

I N T H E S C E N A R I O

The agent was connected to the order system with an admin key, so it can also change prices

and close accounts, although its job needs neither.

B U I L D I N G A I A G E N T S 06

Data leakage

The agent reveals data to the wrong person or sends it somewhere it should not go. Because it

looks up records on a customer’s behalf, a loose lookup or a persuasive request can return

someone else’s details, and every tool that can write, such as email or a ticket, is also a

possible way out. Each step can look like normal work, which is why leakage is often found late.

I N T H E S C E N A R I O

Asked where an order is, the agent looks the customer up by name, finds two people with the

same name and reads back the other one’s address.

Memory poisoning

Something planted in one conversation persists and shapes later ones. Agents that remember

earlier sessions, or learn from past tickets, can carry a false fact or a hidden instruction

forward long after the conversation that introduced it has ended, which also makes the cause

hard to trace when something goes wrong.

I N T H E S C E N A R I O

In one chat a customer says their account is cleared for refunds without a receipt. The agent

stores it as a fact and acts on it the next time, and the time after.

Supply chain

The models, MCP servers, plugins and packages the agent depends on can change or be

compromised without anyone reviewing them. A tool’s description is itself text the model reads,

so an update to a third-party tool can change the agent’s behavior without a line of the team’s

own code changing. When Check Point researchers reviewed 10,000 MCP servers, 40 percent

carried security weaknesses6.

I N T H E S C E N A R I O

The shipping-status MCP server the team took from a public registry updates its tool

description, and the new version asks the agent to send it the customer’s full record with

every lookup.

An agent can do much of this while trying to help.

Tool misuse, excessive authority and data leakage can all happen with nobody attacking the agent,

so controls built only to recognize attackers miss them. At a Check Point hackathon in August 2026,

an SRE agent facing an impossible task rebooted a production database and escalated its own

privileges7.

G O D E E P E R

The Prompt Injection Attacks Handbook shows how goal hijacking works in practice. Our October 2026 study shows

agents breaking rules under peer pressure from other agents. Chapter 5 maps all six risks to OWASP, MITRE ATLAS

and NIST.

https://www.checkpoint.com/resources/items/prompt-injection-playbook https://blog.checkpoint.com/security/peer-pressure-ai-agents/

B U I L D I N G A I A G E N T S 07

03 Why Built-in Safety Falls Short

Two objections come up whenever this topic does. One is that the model vendors invest heavily in

safety, so the models should be safe out of the box. The other is that agent platforms ship their own

guardrails, and the company already has identity management, an API gateway, testing and logging.

Both are partly right, because each layer does real work.

What the layers share is where they look. None of them looks at the specific action the agent is

about to take, in the context of the job it was given, at the moment it takes it, which is why a safe

model inside an agent with real tools can still do something unsafe.

L AY E R S E E S M I S S E S

Model safety training Harmful requests, jailbreak

attempts and content the

vendor’s policy forbids.

Your business rules, and whether an instruction

came from the customer or from a document the

agent read. A refund the policy does not allow is

not harmful content.

Agent platform

guardrails

Configured topics, the list of

allowed tools and general

content filters.

Whether a permitted tool call is right for this task

and this customer. The filters are written for

general cases, not for your refund policy.

Identity and access

management

Which identity the agent uses

and what that identity can

reach.

What the agent does with the access it

legitimately holds, such as the customer records

and email its job needs.

API gateway Which service is called, how

often and by whom.

Whether these arguments, for this customer,

match what was asked.

Pre-release testing How the agent behaved on the

cases someone thought to test.

The paths it takes in production, and its behavior

after any change.

Logging and

monitoring

What happened, after it

happened.

The moment to stop it. A record of a refund

already issued is evidence, not prevention.

THE TWO BLIND SPOTS

The first is the moment between the agent’s decision and its action, when a tool call

has been chosen but has not yet run. The second is everything that changes after

release. Any answer has to cover both.

G O D E E P E R

How Dangerous Deviation Detection works, a check on each tool call before it runs. Why Your AI Passes Tests But

Still Fails in Production, on the gap between testing and live behavior.

https://blog.checkpoint.com/ai-security/dangerous-deviation-detection-ai-agents/ https://www.checkpoint.com/resources/items/white-paper-why-your-ai-passes-tests-but-still-fails-in-production https://www.checkpoint.com/resources/items/white-paper-why-your-ai-passes-tests-but-still-fails-in-production

B U I L D I N G A I A G E N T S 08

04 What It Takes

This chapter sets out six requirements in the order a security team can put them in place, from

knowing each agent to testing it after every change. Together they form one layer around the agent.

Each is written the way a buyer might put it in a requirements document, with a question for your

own team beneath it.

01 Know every agent and what it can reach

Keep an inventory of every agent the company builds or runs, with its owner, purpose, model,

tools, data sources and credentials, and keep it current as agents are added and changed.

Agents multiply quickly once the first one works, and the ones nobody listed are the ones

nobody secures.

A S K Y O U R T E A M

How many agents are running today, who owns each one, and which of them can write to a

customer-facing system?

02 Write down what each agent is for

Before the build, agree a plain statement of the agent’s job, covering the actions it may take on

its own, the actions that need a person and the actions it must never take, such as refunds

above a set amount or changes to prices. Every later check measures the agent against this

statement, so it belongs in the design review rather than in an incident report.

A S K Y O U R T E A M

Could the build team show us, on one page, what the support agent may do and what it must

never do?

03 Give each agent only the access its job needs

Give each agent its own identity rather than a shared key or a developer’s account, with

credentials scoped to the task, reading separated from writing, and limits on amounts and

volumes. Least privilege will not remove every risk, because the job itself needs real access,

but it sets the outer limit of what any mistake can reach.

A S K Y O U R T E A M

If the agent’s credentials leaked tomorrow, what could someone do with them?

D I S C O V E R

G O V E R N

G O V E R N

B U I L D I N G A I A G E N T S 09

04 Check what goes in and what is about to be done

Screen everything the agent reads for prompt attacks, including documents, tool results and

the audio a voice agent hears as well as customer messages. Check each tool call before it

runs against what the user asked for and what the agent is for, and enforce the company’s own

rules, such as what the agent may promise and which data must never leave. This is the check

that covers the first blind spot from chapter 3.

A S K Y O U R T E A M

If a help article told the agent to refund every order, what would stop it?

05 Put a person in front of the actions that matter

For high-impact actions, ask a person to approve, and show them the exact action and its

parameters rather than a summary. Each approval should cover one action and lapse if

anything about it changes. When approvals are kept for the few steps that matter, they stay

meaningful and the agent keeps its autonomy for the rest.

A S K Y O U R T E A M

Which three actions would we never want the agent to take without a person seeing them first?

06 Test before release and after every change, and keep the record

Red team the agent before launch, using the six risks in chapter 2 as the test plan, and test it

again whenever a prompt, model, tool or permission changes. Keep one record per action that

shows what the agent was asked, what it decided, what ran and why it was allowed, so that an

auditor or an incident responder can follow it from end to end. This covers the second blind

spot.

A S K Y O U R T E A M

Could we reconstruct what the agent did for one customer last Tuesday, and why each step was

allowed?

Six requirements, one layer around the agent.

Delivered together, the six requirements answer the second objection from chapter 3. They do not

call for a separate tool per risk. They call for one place where each agent is known and its job is

written down, and where every action it takes is checked against that job before it runs, with one

policy and one record across every agent the company builds. That is what agent steering means in

practice.

P R O T E C T

P R O T E C T

A S S U R E

G O D E E P E R

Securing AI Agents in Production covers monitoring, runtime defense and red teaming for teams already running

agents.

https://www.checkpoint.com/resources/items/securing-ai-agents-in-production

B U I L D I N G A I A G E N T S 10

05 The Mapping

Security leaders are asked to show that a new risk maps to controls, and to the frameworks the

board and the auditors already recognize. This chapter does that in two tables. The first connects

each risk to the requirements that address it and to the matching entries in the OWASP Top 10 for

Agentic Applications 20268, the OWASP Top 10 for LLM Applications 20269 and MITRE ATLAS10. The

second, on the next page, connects each requirement to the NIST AI Risk Management

Framework11.

R I S K R E Q U I R E M E N T O W A S P A G E N T I C 2 0 2 6 · L L M 2 0 2 6 M I T R E AT L A S 2 0 2 6 . 0 9

Goal hijacking 04 ASI01 Agent Goal Hijack

LLM01 Prompt Injection

AML.T0051.000 LLM Prompt Injection:

Direct

AML.T0051.001 LLM Prompt Injection:

Indirect

Tool misuse 02, 04, 05 ASI02 Tool Misuse and Exploitation

LLM03 Excessive Agency

AML.T0053 AI Agent Tool Invocation

AML.T0101 Data Destruction via AI Agent

Tool Invocation

Excessive

authority

01, 03 ASI03 Identity and Privilege Abuse

LLM03 Excessive Agency

AML.T0083 Credentials from AI Agent

Configuration

AML.M0026 Privileged AI Agent

Permissions Configuration (mitigation)

Data leakage 03, 04 LLM02 Sensitive Information

Disclosure

ASI02 Tool Misuse and Exploitation

AML.T0057 LLM Data Leakage

AML.T0086 Exfiltration via AI Agent Tool

Invocation

Memory poisoning 04, 06 ASI06 Memory & Context Poisoning

LLM09 Vector and Embedding

Weaknesses

AML.T0080.000 AI Agent Context

Poisoning: Memory

Supply chain 01, 06 ASI04 Agentic Supply Chain

Vulnerabilities

LLM04 Supply Chain

AML.T0010.005 AI Supply Chain

Compromise: AI Agent Tool

AML.T0110 AI Agent Tool Poisoning

Requirement numbers refer to chapter 4. Requirement 05 also answers ASI09 Human-Agent Trust Exploitation and the ATLAS mitigation

AML.M0029 Human In-the-Loop for AI Agent Actions, and requirement 06 supports every row, because testing and the action record show

that each control works. Four entries on the agentic list, ASI05 Unexpected Code Execution, ASI07 Insecure Inter-Agent Communication,

ASI08 Cascading Failures and ASI10 Rogue Agents, matter most for agents that run code or work with other agents, which the scenario in

this guide does not.

How to use the two tables. They are built to go to the board as two pages. The risk and requirement

columns are what your team acts on, and the framework columns are the vocabulary auditors and

regulators will use when they ask whether it was done.

B U I L D I N G A I A G E N T S 11

The requirements in NIST terms

The NIST AI Risk Management Framework is organized around four functions, Govern, Map,

Measure and Manage, rather than around threats, so it maps more naturally to what a team does

than to what can go wrong. The table gives the function each requirement mainly serves and the

subcategories it helps to meet.

R E Q U I R E M E N T

M A I N

F U N C T I O N N I S T A I R M F 1 . 0 S U B C AT E G O R I E S

01 Know every agent and

what it can reach

GOVERN GOVERN 1.6 AI systems are inventoried

GOVERN 6.1 policies address third-party AI risks

MAP 4.1 risks of components, including third-party software, are mapped

02 Write down what each

agent is for

MAP MAP 1.1 intended purposes and deployment context are documented

GOVERN 1.4 risk controls are set out in transparent policies

03 Give each agent only the

access its job needs

MEASURE MEASURE 2.7 security and resilience are evaluated and documented

04 Check what goes in and

what is about to be done

MANAGE MANAGE 2.4 mechanisms can supersede or disengage a system that

departs from its intended use

MEASURE 2.6 safety is evaluated, including real-time monitoring and

failing safely

05 Put a person in front of

the actions that matter

MAP MAP 3.5 processes for human oversight are defined and documented

MANAGE 4.1 monitoring plans include override

06 Test after every change,

and keep the record

MEASURE MEASURE 3.1 emergent risks are tracked in deployed contexts

MANAGE 3.1 third-party resources are monitored

MANAGE 4.1 post-deployment monitoring, incident response and change

management

Subcategory IDs from NIST AI 100-1, the AI RMF 1.0 Core, with a short paraphrase of each. The framework sets outcomes rather than

technical controls such as least privilege, which is why requirement 03 maps to a single subcategory. NIST has said a revision of the

framework is in progress, and its control overlays for AI agents are still in development.

BEYOND THIS GUIDE

The AI Risk Map maps a wider set of AI risks to OWASP, MITRE ATLAS, the NIST AI

RMF, ISO/IEC 42001 and the EU AI Act, stage by stage across the AI lifecycle.

Use it when the board or an auditor asks how agent risks fit into the organization’s wider AI risk

register.

https://www.checkpoint.com/resources/items/ai-risk-map

B U I L D I N G A I A G E N T S 12

06 The Checklist

Answer the ten questions before you approve a build, and again before the agent goes live. Each one

points to the chapter 4 requirement that closes the gap, and each lifts straight into a requirements

document or an RFP.

Q U E S T I O N Ye s P a r t ly N o t y e t

01 Do we have an inventory of every agent we build or run, with

an owner, purpose, tools and credentials for each? R E Q 0 1

02 Is there a written statement of what each agent may do on its

own, what needs a person and what it must never do? R E Q 0 2

03 Does each agent run under its own identity, with credentials

scoped to its task? R E Q 0 3

04 Are reading and writing separated, with limits on amounts

and volumes for actions such as refunds? R E Q 0 3

05 Is everything the agent reads, including documents, tool

results and its memory, screened for prompt attacks? R E Q 0 4

06 Is each tool call checked before it runs, against what the user

asked for and what the agent is for? R E Q 0 4

07

Are the company’s own rules, such as what the agent may

promise and which data must never leave, enforced on every

message and tool call?

R E Q 0 4

08 Do high-impact actions go to a person who sees the exact

action, with an approval that lapses if anything changes? R E Q 0 5

09 Is the agent red teamed before release and tested again after

every change to its prompt, model, tools or permissions? R E Q 0 6

10 Could we reconstruct, for any action, what the agent was

asked, what it decided and why it was allowed? R E Q 0 6

Y O U R R E S U LT

Ten yes answers mean the agent is known,

scoped, checked and provable before it goes

live. Every Partly or Not yet points to the

requirement in the REQ column to start with.

U S I N G I T W I T H A V E N D O R

Start each question with “The solution must”

and it becomes a requirement. Ask to see

questions 05 to 10 demonstrated on an agent of

your own.

B U I L D I N G A I A G E N T S 13

NEXT STEPS

Where to go from here. Each risk in this guide is cheaper to design out than to find in production, which is why the decision

to build is the best moment to set the requirements. Start with the checklist, take the mapping to

the board and bring the requirements to the build team’s design review. The resources below go

deeper at each stage.

B E F O R E Y O U B U I L D

Building AI Agents

The risks to name and the

requirements to set before you approve

a build.

The Agentic Readiness Ten

Ten questions on how ready the

organization is for agentic AI.

Agentic AI Security: The

Enterprise Playbook

The program view of securing agentic

AI.

W H I L E Y O U B U I L D A N D T E S T

The AI Risk Map

AI risks mapped to the major

frameworks across the AI lifecycle.

Prompt Injection Attacks

Handbook

How prompt attacks work, with

examples to test against.

Why Your AI Passes Tests But Still

Fails in Production

Red teaming that reflects how the

agent will really be used.

O N C E A G E N T S R U N

Securing AI Agents in Production

Monitoring, runtime defense and red

teaming for live agents.

The Agent Control Ten

A ten-question self-check for agents

already in use, with a score.

AI Agents Act on Context. Security

Should Too.

Why each action has to be judged in

context.

For the AI assistants employees connect to company data, see Connecting AI to Enterprise Data and the AI Exposure

Ten.

How Check Point helps

Check Point AI Security secures AI applications and agents, including the ones your own teams

build. It shows you the agents running across your business, assesses each one’s risk in context,

and controls what they can access and do at runtime. The capabilities that answer the requirements

in this guide include prompt attack detection on everything an agent reads, with audio guardrails for

voice agents; Dangerous Deviation Detection, which checks each tool call before it runs; custom

guardrails, which turn a company rule written in one sentence into a check on every message and

tool call; and AI red teaming before release and after changes.

L E A R N M O R E

To learn how Check Point secures the AI agents

your teams build, contact your Check Point account

team.

checkpoint.com/ai-security

T H I S G U I D E

https://www.checkpoint.com/resources/items/checklist-the-agentic-readiness-ten https://www.checkpoint.com/resources/items/white-paper-agentic-ai-security-the-enterprise-playbook https://www.checkpoint.com/resources/items/white-paper-agentic-ai-security-the-enterprise-playbook https://www.checkpoint.com/resources/items/ai-risk-map https://www.checkpoint.com/resources/items/prompt-injection-playbook https://www.checkpoint.com/resources/items/prompt-injection-playbook https://www.checkpoint.com/resources/items/white-paper-why-your-ai-passes-tests-but-still-fails-in-production https://www.checkpoint.com/resources/items/white-paper-why-your-ai-passes-tests-but-still-fails-in-production https://www.checkpoint.com/resources/items/securing-ai-agents-in-production https://www.checkpoint.com/resources/items/checklist-the-agent-control-ten https://www.checkpoint.com/resources/items/white-paper-ai-agents-act-on-context-security-should-too https://www.checkpoint.com/resources/items/white-paper-ai-agents-act-on-context-security-should-too https://www.checkpoint.com/resources/items/white-paper-connecting-ai-to-enterprise-data https://www.checkpoint.com/resources/items/checklist-the-ai-exposure-ten https://www.checkpoint.com/resources/items/checklist-the-ai-exposure-ten https://www.checkpoint.com/ai-security/ https://blog.checkpoint.com/ai-security/audio-prompt-injection-voice-agents/ https://blog.checkpoint.com/ai-security/dangerous-deviation-detection-ai-agents/ https://blog.checkpoint.com/ai-security/custom-guardrails-ai-agents/ https://blog.checkpoint.com/ai-security/custom-guardrails-ai-agents/ https://www.checkpoint.com/resources/items/solution-brief-ai-security-red-teaming https://www.checkpoint.com/ai-security/

B U I L D I N G A I A G E N T S 14

References.

1 Check Point, 2026 Cloud Security Report: Securing the AI Transformation, May 2026.

https://engage.checkpoint.com/2026-cloud-security-report-securing-the-ai-transformation

2 Okta, Global CISO Insights 2026, 29 July 2026.

https://www.okta.com/newsroom/articles/global-ciso-insights-2026/

3 CBC News, Air Canada found liable for chatbot’s bad advice on plane tickets, 15 February 2024 (Moffatt

v. Air Canada).

https://www.cbc.ca/news/canada/british-columbia/air-canada-chatbot-lawsuit-1.7116416

4 VentureBeat, A Chevy for $1? Car dealer chatbots show perils of AI for customer service, 19 December

2023.

https://venturebeat.com/ai/a-chevy-for-1-car-dealer-chatbots-show-perils-of-ai-for-customer-service

5 The Register, Vibe coding service Replit deleted user’s production database, faked data, told fibs

galore, 21 July 2025.

https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/

6 Check Point Research, The AI Security Report 2026, p. 22, July 2026.

https://engage.checkpoint.com/ai-security-report-2026

7 Check Point, No Attacker Required: What a Two-Day Hackathon Taught Us About Agent Security, 21

September 2026.

https://blog.checkpoint.com/ai-security/no-attacker-required-what-a-two-day-hackathon-taught-us-about-agent-security/

8 OWASP GenAI Security Project, OWASP Top 10 for Agentic Applications for 2026, December 2025.

https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

9 OWASP GenAI Security Project, OWASP Top 10 for LLM Applications 2026, v1.0.

https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/

10 MITRE, ATLAS: Adversarial Threat Landscape for AI Systems, release 2026.09.

https://atlas.mitre.org/

11 NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023.

https://doi.org/10.6028/NIST.AI.100-1

https://engage.checkpoint.com/2026-cloud-security-report-securing-the-ai-transformation https://www.okta.com/newsroom/articles/global-ciso-insights-2026/ https://www.cbc.ca/news/canada/british-columbia/air-canada-chatbot-lawsuit-1.7116416 https://venturebeat.com/ai/a-chevy-for-1-car-dealer-chatbots-show-perils-of-ai-for-customer-service https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/ https://engage.checkpoint.com/ai-security-report-2026 https://blog.checkpoint.com/ai-security/no-attacker-required-what-a-two-day-hackathon-taught-us-about-agent-security/ https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/ https://atlas.mitre.org/ https://doi.org/10.6028/NIST.AI.100-1

W O R L D W I D E H E A D Q U A R T E R S

Check Point Software Technologies Ltd.

5 Shlomo Kaplan Street, Tel Aviv 6789159, Israel

Tel: 972-3-753-4555

U . S . H E A D Q U A R T E R S

Check Point Software Technologies, Inc.

100 Oracle Parkway, Suite 800, Redwood City, CA 94065

Tel: 1-800-429-4391

www.checkpoint.com

© 2026 Check Point Software Technologies Ltd. All

rights reserved. Check Point and the Check Point logo are trademarks of Check Point Software Technologies Ltd.

building_agents: question_01: yes: Off partly: Off not_yet: Off

question_02: yes: Off partly: Off not_yet: Off

question_03: yes: Off partly: Off not_yet: Off

question_04: yes: Off partly: Off not_yet: Off

question_05: yes: Off partly: Off not_yet: Off

question_06: yes: Off partly: Off not_yet: Off

question_07: yes: Off partly: Off not_yet: Off

question_08: yes: Off partly: Off not_yet: Off

question_09: yes: Off partly: Off not_yet: Off

question_10: yes: Off partly: Off not_yet: Off