Securing AI in the real world – what RSAC 2026 taught us
From shadow AI to agent security – how to protect the modern AI workspace.


This is my second blog covering my thoughts and key takeaways from RSAC 2026. You can find the first one here.
I’ll admit, I’m usually a huge cynic of most conferences. Not because I don’t enjoy them, but because of the amount of noise you have to cut through to find them genuinely useful.
RSAC is different.
As a global cybersecurity conference, there is still plenty of ‘sell’, but beneath that sits a mecca of tech innovation, and one of the clearest views of the direction of cybersecurity. Under the main theme of the conference, ‘The Power of Community’ sat two core themes:
- How we secure AI
- How we use AI to solve real security challenges.
A practical way to think about AI security
Across RSAC, one thing was clear – AI security isn’t a single issue, it’s a set of challenges that sit across different layers of the organisation and span three horizon points – the ‘now’, as well as ‘medium’ and ‘long’ terms.
We can break this set of challenges down into four areas:
- The AI workspace
- Agents and AI applications
- AI development (including ‘vibe coding’)
- Build-your-own AI
Each comes with its own set of risks, levels of maturity and urgency.
1. The AI workspace – tackling shadow AI first
This is where most organisations should start, looking at the overall ‘AI workspace’ and how users are consuming AI, including ChatGPT, Copilot, Gemini, browser-based tools and mobile apps. In most organisations, this is happening at scale, whether it’s sanctioned or not.
‘Shadow AI’ throws up some major security challenges, the biggest being visibility and control.
Organisations should be asking some key questions:
- What AI tools are actually being used?
- Do our policies cover them?
- Can we enforce those policies?
- Can I see what my employees are doing?
- What’s happening to our data?
This first step should feel familiar within an IT security space, it’s just applied to a new category of tools. The table below is how we tackle these challenges:
|
Challenge |
Approach |
Control method |
|
Lack of visibility |
Use existing or new methods to discover AI usage across apps and browser. |
Endpoint agents, API, browser plugin, or all three. |
|
No guardrails |
Align AI systems in use to current security standards and risk frameworks (e.g. ISO 42001, NIST AI RMF) |
GenAI security platforms. Mapping to common standards and scoring them. |
|
Policy enforcement |
Translate acceptable use into technical controls and build policies to create a secure, innovative environment. |
Blocking, warnings and redirection. |
|
Data exposure risk |
Monitor inputs and outputs. |
Consistent data security policy for DLP, API integrations, identify abnormal behaviour patterns. |
Nothing here is radically new, but the scale and speed of adoption is. For most organisations, getting this layer right will address most of the immediate risk.
2. Agents and AI applications – the next step
If the AI workspace was mentioned a lot at RSAC, agents, model context protocol (MCP) and AI apps came up even more frequently throughout the event.
Agents are the next logical step in AI adoption to get the most out of it, moving from tools that assist, to systems that act. Whether that’s coding, automating workflows or operating inside security tools, they introduce a new level of complexity.
A key enabler here is model context protocol (MCP), commonly known as ‘the USB for AI systems’. MCP creates a common interface, allowing AI systems to securely connect to real business data and tools like Teams, Github or Jira, without requiring custom integrations every time. Prior to MCP, all AI tools were custom built and integrated, limiting the scalability of AI systems. MCP solves this scalability problem but introduces a security issue.
There are two main control points:
Front end – looking at user and agent interaction
- Visibility into how agents are used
- Policy enforcement and guardrails
- Detection and response
- Data protection
This is typically handled through
- Endpoint and browser controls
- IDE (Integrated Development Environment) plugins
- Secure access solutions
Back end – MCP integration layer
This is where things get more interesting. The MCP server effectively becomes a policy enforcement point (PEP), where trust is defined, controlling what an agent can access and do. Some of the most impressive tech I saw at RSAC made use of identity at the MCP server, and the OAuth2 protocol suite. See the figure below:
Two challenges dominate here:
Authentication – is the agent who it claims to be?
Authorisation – should it be allowed to carry out this action?
The most mature approaches use:
- Identity providers (IdP)
- Token-based access (OAuth2)
- ‘Blended identity’ (linking human and agent control, as seen in the diagram above)
This allows organisations to apply delegated access controls, ensuring agents act within defined boundaries.
3. AI development – when everyone becomes a developer
One of the most interesting shifts discussed at RSAC was the rise of ‘vibe coding’, using AI to generate applications from prompts. The implication for organisations is significant. As one CISO put it, “I have an organisation of around 3000 people, originally with a development team of around 50 - now I have 3000 potential developers". AI has effectively expanded the development surface to the entire organisation, which creates two immediate challenges:
1. Controlling how AI-generated apps are created and used
Risks include data exposure, as well as the use of unsanctioned tools, weak identify controls and unmonitored integrations. Vibe coding can be quite powerful in an SME’s hands, however guardrails and sanctions are vital.
2. Securing the development lifecycle itself
This includes code and dependency scanning, secrets management and risks around the software supply chain. Pipeline security is also an issue, with prompt governance required to ensure loss prevention to protect IP.
The key point is that development is no longer a contained function, it’s an organisational capability. Security models need to adapt accordingly – and quickly.
We’ve now built a full picture of what the AI workspace looks like, who is involved and how to secure it.
4. Build-you-own AI – full control, full responsibility
Think ‘IKEA for AI’! At the more advanced end, many organisations are exploring building their own AI environments. I spoke to many at RSAC who are using a range of operating models including:
- Private data centres – for control and compliance
- Co-located or neo-cloud models – for cost savings and flexibility
- GPU-as-a-service – for Opex models, rather than Capex, rolled into an existing CSP agreement.
What stood out to me at RSAC is how quickly security vendors are aligning to this trend, with some of the larger vendors developing AI reference architectures to align a platform of security controls for the AI factory. These include:
- Policy enforcement across agent software stack
- Endpoint protection for local AI agents
- Cloud runtime protection for AI agent deployments
- Identity-based governance for agent access
- Continuous model testing and evaluation
Think of this as applying everything from the previous sections, but within a closed, controlled AI ecosystem.
Security as a priority
The consistent message from RSAC was that AI isn’t a single technology to secure – it’s an ecosystem. The attack surface is expanding rapidly, from how people use AI tools, to how agents operate and how applications are built and deployed.
The organisations that succeed won’t be the ones adopting AI the fastest, they’ll be the ones building security into every layer from the beginning, balancing innovation with control and automation with accountability. AI will definitely be used in your organisation – it’s essential, therefore, to secure it properly.
You can catch up with the first blog here. If you’d like to find out more about Softcat’s services and solutions, please click here.