11 Jun 2026

Zscaler's new zero trust platform for agentic AI sounds like an IT infrastructure story. It isn't. For anyone running or planning to run AI agents in consumer credit, this is a compliance and conduct risk story wearing a cybersecurity jacket.

The specific thing that matters here is MCP (Model Context Protocol) communications between agents. In a loan origination context, AI agents aren't just doing one job. They're querying affordability data, pulling credit files, writing decisions back to systems, and potentially triggering downstream actions with third-party APIs. Each of those connections is a point where data can leak, be manipulated, or operate outside the boundaries your governance framework assumes it's working within.

The FCA's expectations on AI governance are tightening, even if the formal rules are still catching up. The Consumer Duty requires you to demonstrate that your outcomes for customers are intentional and controlled. An AI agent that operates across multiple data sources and systems, without proper access controls or audit trails, is essentially ungovernable from a conduct perspective. You can't demonstrate good outcomes if you can't trace exactly what the agent accessed, when, and why.

Two things stand out from what Zscaler is shipping:

• AI Access Graph, which maps what agents can reach, matters enormously for data minimisation obligations under UK GDPR. Do your agents have access to more customer data than they need to complete their task?
• Prompt extraction and AI red teaming as product features signals that adversarial manipulation of agents is now considered a real attack surface, not a theoretical one.

Most credit businesses I speak to are still treating agentic AI as a capability question. They're asking what agents can do for them. The smarter question is what governance and security infrastructure needs to exist before agents touch regulated customer journeys at all.

If your IT and risk teams aren't in the same conversation about this, that gap is worth closing before your first agentic deployment goes live.

Salesforce didn't add an AI coding assistant to their workflow. They rebuilt the workflow around the agent and removed the guardrails that would have kept it in a supporting role. No token limits means no artificial ceiling on how much context the agent can hold, how deep it can reason through a codebase, or how far it can run without human check-ins. That's a fundamentally different operating model.

The angle that matters for UK consumer finance technology leaders isn't the Salesforce-specific tooling. It's the organisational commitment the decision represents.

Most financial services engineering teams are running AI assistants as productivity sprinkles on top of unchanged processes. A developer writes a ticket, gets some autocomplete, maybe generates a test. The backlog, the sprint planning, the review gates, all of it stays the same. Salesforce made the opposite call: let the agent own the lifecycle and redesign the human role around that.

For a loan origination platform, the implications are significant. We carry enormous amounts of legacy logic — affordability rules, bureau integration quirks, FCA-mandated audit trails. The argument against agentic development in regulated environments has always been that the compliance surface area is too wide to trust autonomous generation. I'm not sure that holds anymore, and here's why:

• An agent with full codebase context and no token constraints can reason about downstream compliance impact better than a developer holding a mental model of three interconnected services
• The audit trail an agent produces, every decision, every change, every rationale, is often more legible than what comes out of a human sprint

The real blocker isn't technical risk. It's that most technology leaders in financial services are still framing agentic AI as a tool their developers use, rather than a participant in the system that developers now supervise.

Salesforce had the engineering scale and appetite to force that reframe. Smaller consumer credit businesses won't copy the implementation, but the question their CTO should be sitting with is a simple one: are we designing our development processes for the team we have today, or for the one we'll actually be running in 18 months?