As I learn more about proper AI and dig down into its components, the more the old fundamentals seem to hold firm. One of the things that has become increasingly clear is how you should apply security and access controls when working with AI systems. A common mistake is giving an AI access to data it should never see.

AI interacts with the world through what are called tools. These are simply a new posh term for abstraction layers. A tool might be a snippet of SQL, access to a dataset, a link to an external service, or almost anything else the AI can use to answer your query. The AI is designed to choose the most appropriate tool, but the security boundaries must be built into the tools themselves.

For example, if you have a tool that queries a SQL server, the data that the AI agent can access should be restricted at the tool level, not at the AI agent level itself. You would not rely on the AI to write a query that says, get all the data about hamsters but ignore the data about rats. If the two datasets have different security requirements, the tool should only have access to the hamster data in the first place.

AI actions are not hard and fast. They are probabilistic rather than deterministic, which means you cannot rely on a large language model to consistently make the correct security decision for you. Traditional security principles still apply, especially least-privilege access and strong boundary control.

In the era of AI, the technology may be new, but the security fundamentals remain exactly the same.

Note: I have not suddenly become an AI expert; I am just elbows deep in the very serious “end-to-end AI engineering” by Swirl AI. I would recommend it to anyone that wants to get past the glossy rubbish about AI.

Preface.

Before I get going on the subject, I want to make a clear distinction. I am not talking about AI as a financial investment. As it currently stands, that side of things looks as if it is setting itself up quite nicely for a nasty correction, and it is already showing all the hallmarks of another ‘Tulips’ or .com moment. But I do not know enough about that world to comment in any depth. ¹

What I am talking about here is the technological adjustment that will happen when the investment rounds in AI finish, the speculative phase ends, and the technology has to make solid money day after day.

As the media cycle spins on, we keep hearing talk of the AI bubble collapsing, which then becomes talk of the collapse of AI itself. Now I know I swore I was not going to write another thought piece on AI, but here we are.

I don’t think we are going to see a collapse of AI as a technology. We may well see the collapse of a few overextended companies, but what I think we are far more likely to see is a rationalisation of the excess of AI features.

Rather than the dramatic collapse that some people seem to want to hype up, I think it will look much more like what we saw with JavaScript. Those who recognise the word “Netscape” will remember when JavaScript first arrived in browsers and did everything. Then it was discovered that it did everything badly and rather messily, and it was wildly overused. It was clamped down on hard and fell out of favour for a while. Then people realised that actually, this kind of functionality was really useful, as long as it was applied properly, limited in the right places and optimised where it made sense. From there, it grew and grew until it became more popular than ever. I think we are heading for the same kind of correction with AI.

I also think that a lot of the components that make up what people think of as AI will become more visible in their own right. At the moment, most people only think of the big, flashy parts, like Large Language Models. I suspect that things like vector databases will become far more visible. Alternative database technologies will also continue to grow in popularity, particularly NoSQL. Orchestration and model routing will also become things that are simply built into other systems as standard.

What I really think will happen is that people will build applications and want the power that a full AI stack offers, but they will not want to pay full AI prices for everything. If your cloud costs are already around ten thousand a month, you are not going to want to add another ten to fifteen thousand just for the AI layer. You will want it to be cheaper, more targeted, and you will only want to pay for what it is genuinely worth.

Because of that, I think we will see a breakup of the big, all-encompassing AI platforms, leaving only a few players who can truly operate at global scale, such as Salesforce, OpenAI and Google. The rest of us will use smaller, more focused AI components to deliver the specific features we actually need.

I have mentioned this example before, but claims evaluation is still my favourite. You only need a very small language model and your own local data store to do a serious job of evaluating whether claims are fraudulent or not. You do not need it to hold a full conversation. You do not need chat prompts and all the engineering that goes with that. It is still AI driven, but it is focused and cost-effective.

I think we will see more and more of this approach as people take only what they need, rather than paying for vast, Agentic systems that do everything, cost too much, and deliver too little in return.

1. Shares generally terrify me, as I am risk averse, which is why my total shareholding is 3 Games Workshop shares, which I mainly have for the amusement value. [↩]

A smaller version of the normal Salesforce conference, and very definitely targeted at Agentforce. As a change of pace to the normal Salesforce conferences It was very much geared around practical work ¹, and that seemed to be the core theme of the day.

It felt like we have now moved past the over-excitement phase of AI. Everyone is asking the same question: how do we actually make money out of this, and what do we really do with it past a fun proof of concept?

There were quite a few large-scale customer success stories pushing cost savings and value. Also a lot of practical coding sessions on how you actually implement things. One interesting thread ran through the day. Those who are rolling their own, or “DIY AI” as Salesforce calls it, were very much looked down upon as an unnecessary cost and a waste of effort.

The clear message was why bother when you can have prefabbed AI with a set of ready to use tools. Alongside that was a constant emphasis on trust and trustworthiness. A valid point and one that needs making, because if you package up AI and make it opaque on what is going on under the hood, then people really do have to trust the implementation.

My highlight of the day was the Compliance Centre. It is the first truly useful business implementation of AI that I have personally seen. Most other tools feel like clever technology in search of a problem, or thinly disguised cost cutting exercises. Even the usual line of “freeing people up to do interesting work” often feels forced. The Compliance Centre, however, is genuinely useful. Corporations have to do compliance. They hate doing it. The people tasked with it hate doing it. The people they enforce it on tend to hate them for doing it. It is a miserable necessity. So having a tool that takes large regulatory documents, even giant government-produced PDFs, turns them into practical legislation and enforces it inside your data is genuinely powerful. It is exactly the sort of task no one wants a human to do, and no human wants to do it.

I may be slightly coloured by the fact that I genuinely enjoyed the day. It was a smaller event, but I had good company, which always helps. It felt much more like an information dump showing what is coming, rather than a sales drive. They clearly knew that very few organisations had money left to spend at this time of year.

One thing I nearly forgot to mention was the whole “vibe coding” toolkit. It was demoed and had multiple workshops, but in honesty I have seen the same ideas implemented elsewhere in other development environments. Salesforce are largely catching up here. They might see it as a big step forward, but for many developers it felt more like parity.

Overall though, well worth attending. I did not expect much from it, and several colleagues and previous clients skipped it because they assumed it would be too small to bother with. I think they missed out. It was far less hyperactive than the main events and much more focused on practical delivery. I came away with useful tools, new knowledge and a surprisingly positive view of where this part of the platform is heading.

1. , which I suspect is down to the practicalities of it being held in Quarter 4 of the financial year when no one has any money left [↩]