Hello Cyber Builders 🖖
Your payment platform can be up, patched, and doing exactly what it was built to do while your company is sending money to a criminal. You needn’t go through the Vulnpocalypse (although, if you really want to, you can take a look at Patrick Garrity‘s write-up). Cybersecurity is not just about hacking computers and networks.
This week I want to focus on that particular idea.
In January 2024, an employee in Hong Kong authorized transfers totaling about HK$200 million after a deepfake video conference with criminals. According to the Hong Kong government’s account, the fraudsters used altered video and audio to impersonate executives. The meeting was pre-recorded. Payment instructions continued through messaging.
Employees trusted the request. The company lost the money.
When I think about AI and security, I see how generated human-like content has a deep impact. A convincing message reaches someone with authority, and the business process does the rest. Fake documents, fake IDs, etc.
Much of the discussion focuses on faster attackers and faster defenders. AI finds vulnerabilities, writes exploits, and sends malware. AI helps a SOC triage alerts.
All of that matters. But I think three changes need more attention: fraud and business impact, the central role of data, and the variety of AI systems businesses will need to secure.
For many businesses, I expect the biggest AI risks to come from fraud, data leaks, and deception. A company can lose money or valuable knowledge while its infrastructure continues to run.
A supplier’s bank details get changed. A customer gets a refund they should not have. An employee sends out a confidential pricing document because the request looked real. These are losses any CEO understands right away.
Fraud is nothing new. AI adds new ways to fake identity, context, and evidence to make a request look real. The Hong Kong case shows how convincing this can get.
Now think about the systems on the receiving end.
Imagine a customer-service agent that can read order history and issue refunds. You give it that access because resolving customer problems is its job. A fraudulent claim reaches the agent, which accepts the story and processes the refund.
Its credentials are valid. The refund API works. The transaction shows up in the logs. Whether anyone notices depends on whether your controls understand the business context.
Just having permission to use a tool does not tell you if a specific action is legitimate.
A finance employee might have access to a payment platform but still need someone else’s approval for a transfer. An AI agent needs the same clear limits. Who can it pay? How much? What evidence does it need to check? Who approves changes to the beneficiary?
Those decisions are for the business and security teams. A CISO can help enforce the rule, but someone in finance has to define what a real payment looks like.
That is why I think AI will bring security teams closer to fraud operations, finance, and the people who run customer processes. I am still unsure whether the “security teams” we are talking about here are the same as the ones running SOC or doing compliance work.
To understand and handle fraud, you need a much broader business sense to understand the economic value of what is manipulated.
-
Finance defines legitimate payments,
-
Fraud teams understand deception,
-
Security helps enforce boundaries and investigate abuse.
Then, data security is often overlooked in many companies today.
A generic AI model knows almost nothing about your company. Connect it to your contracts, customer records, messages, and internal documents, and now it becomes useful.
That is also when the security questions get specific.
Take a sales assistant. It can read past negotiations, summarize a customer’s objections, and help prepare an offer. The real value is the commercial knowledge it can pull together: the transcript of all your calls, the customer roadmap, your forecast, your margins, etc.
If it leaks that information, moving the workload to another server will not fix the loss.
Data also shapes what the system does. An AI agent reads information, interprets it, and may use tools based on what it sees. If an attacker can change that information, they can influence what happens.
Imagine a procurement agent reviewing a supplier proposal. The document asks it to send internal pricing information to an outside address. A human would know a supplier document cannot make that request. The AI agent needs to keep that same boundary.
This can happen while the application and infrastructure are operating normally. The AI agent just runs into hostile content during a real task.
I would start with three questions for any AI workflow: what can it read, what can it reveal, and what can it change?
The answers usually sit with different teams. IT knows the connector. The business owner knows the documents. Security knows the permissions.
You need the full picture to judge the risk.
You also have to track the information after it is retrieved. A restricted document can turn into a summary, a chat response, a log entry, or a draft email. Data lineage is a major issue.
Data security has been at the core of cybersecurity frameworks for decades. Yet it often gets less attention than infrastructure security. Responsibility is spread across IT, security, and business teams, and each sees only part of the picture.
AI gives me another reason to have data security top of mind. Data is both something to protect and something that shapes what the system does.
Last but not least, AI is a new wave and will change the “good old” IT systems everyone is used to.
Think about the familiar enterprise backbone. Three major cloud providers. Microsoft across identity and productivity. Cisco across much of the network. Salesforce, HubSpot, and Pipedrive for CRM. Palo Alto, Fortinet on the networking side.
Plenty of complexity, but a relatively small group of suppliers underneath a large share of it.
I expect a much more mixed picture at the AI application level.
Your sales team may use an assistant inside its CRM. Finance may build an agent to process invoices. Engineering may use coding tools with repository access. Customer support may buy a specialist service. A partner may introduce an AI system into a shared process.
They may run on the same cloud or use the same model. Still, that shared foundation does not mean they will behave the same or have the same authority.
Two applications using the same model can have completely different risks. One drafts public marketing copy. The other reads acquisition plans and can email advisers. Their data, tools, MCP servers, skills, business owners, and business impact are different.
Approving a model provider is one step, but understanding each deployed system is another.
Let’s take an example:
-
A team adds a connector, a developer changes an instruction, or a vendor adds a new feature to an existing subscription. Yesterday’s drafting assistant can now send the message.
-
Systems start to interact. A procurement agent makes a recommendation that a finance agent uses. An internal assistant asks a partner’s system to do a task. Information and authority cross boundaries that a single product review may miss.
Protocols are already developing around that need. A2A supports communication between agents, while MCP connects AI applications to tools and data. The Linux Foundation’s April 2026 A2A update reports support from more than 150 organizations, plus integrations with major cloud platforms.
Cyber Builders, whether running an AI Security program or building software for it, you need to know who owns each system, what data it uses, what it can do, and how to stop it.
A few providers may supply the compute. A few companies may supply the models. The systems running inside a business can still be many, connected, and very different.
Cyber Builders, you already have more security work than people to do it. A broad AI governance program can require months of meetings before it produces a single useful control.
So start where the risk becomes real: one process where money or sensitive information changes hands. Supplier payments, customer refunds, and contract reviews are good places to begin.
After more than 25 years of building cybersecurity products and companies, I still believe the best security discussions begin with the business activity that needs protecting. AI makes that starting point even more important because businesses are giving software more information and more authority to act.
That is the risk I keep coming back to: how much damage can happen before anyone notices. A payment goes through. A confidential answer is sent. A decision is made using false evidence.
This week, choose one workflow and ask its owner: if an AI system made the wrong decision here, how would we know, and who could stop it?
I’d like to hear what you find. Reply with the workflow you are securing or the blind spot you believe deserves more attention.
Laurent 💚
