When Agents Become the Front Door: The Data Security Bill Nobody Budgeted For
Everyone wants agentic AI: data teams, application owners, IT. But the funding model doesn’t match the architecture slides!
Less of a core security post, but very relevant to recognise a change currently taking place! Something subtle is happening in enterprise tech stacks. The tools we’ve always treated as “where work happens” are starting to look like endpoints. Meanwhile, agentic AI is being pitched as the new front door: you ask in plain English, it pulls context from your data platform, then triggers the right workflows in your systems of record.
On paper, it’s clean and modern. In the real world, it collides with two things that don’t fit neatly on a slide: trust and cost.
And once you add data security into the mix, the question stops being “where does the centre of the stack live?” and becomes “who owns the blast radius when it goes wrong?”
The tidy architecture everyone keeps drawing
After a couple of years of enterprise AI hype, a familiar pattern has settled in:
Execution layer (systems of record): Salesforce, Workday, SAP/Oracle, ServiceNow. These hold the authoritative record, run workflows, and keep audit trails.
Context layer (data platform): Snowflake, Databricks, Fabric, and similar. These unify data, enrich context, and support analytics and ML work.
Intelligence and interaction layer (agents): Natural language requests, context retrieval, orchestration, and workflow triggers back into the systems of record.
It makes sense in theory. It’s also not how most organisations are funded or governed.
Most teams are still wrestling with data foundations and app sprawl. Adding agentic AI isn’t just “one more tool”. It’s another moving layer that touches identity, data access, workflow execution, and accountability.
“Agents replace apps” sounds nice… until you need the truth
One practical pushback keeps coming up: transactional systems don’t vanish, because they’re where work actually executes and where accountability lives.
If a sales rep asks an agent for the “truth” about CRM data, they’ll still want to verify it against the authoritative record. That verification needs a clear path back to the CRM system of record, not a vague answer that can’t be traced.
From a data security angle, that link back matters even more. When you’re challenged on a decision later, the question won’t be “what did the agent say?”. It’ll be:
What was the source of truth?
Who changed it?
What evidence exists that controls were followed?
Agents can change the interface. They don’t remove the need for governed execution.
The messier reality: systems of record are already being treated like endpoints
There’s also a grounded counterpoint: plenty of Snowflake and Databricks estates already have agents and point solutions orbiting around them. Conversation intelligence tools, workflow automation, and specialised assistants often sit “above” the stack, with systems of record increasingly treated as endpoints.
That’s the real shape of “unbundling”:
The system of record stays essential.
But it stops being the place people spend their day.
The agent layer becomes the surface users actually touch.
Once that happens, uncomfortable commercial questions show up fast:
Do you still pay per seat for Salesforce if fewer people log in?
Does value shift to the agent layer because that’s where behaviour changes?
Does the data platform start looking like the operating system for work?
None of that resolves cleanly, because pricing models tend to lag behind how people actually work.
The awkward question vendors dodge: who pays for cross-system AI?
Here’s where it gets real.
Agentic AI is cross-system by design. But most enterprises are organised in silos by budget, accountability, and risk. So when someone presents the elegant “agent layer spanning the enterprise” vision, the operational question is painfully simple:
Who signs the PO?
Data platforms are often funded under analytics budgets, measured on quality, reliability, and cost control. They rarely own end-to-end user outcomes.
Transactional applications are owned by departments. Sales ops funds Salesforce, HR owns Workday, finance owns ERP. Each has its own priorities and tolerance for change.
Central IT is expected to enable and standardise, but often doesn’t hold the budgets for the apps that matter most day-to-day. Or budget to SECURE THEM!
This is how you get the classic “everyone agrees, nobody funds it” pattern.
Why systems of record still hold the ground that matters
Even if agents become the interface, systems of record keep strategic gravity for four reasons:
They remain the authoritative record
When an agent answers questions about customers, contracts, patients, or finances, verification matters. The organisation expects truth to live in a governed system with ownership and stewardship.They execute workflows with state and control
“Doing the work” isn’t the same as “moving data”. Approvals, segregation of duties, exception handling, rollback paths, and audit evidence are hard-earned capabilities.They carry process meaning, not just APIs
The hard part isn’t connecting systems. It’s agreeing what a “customer”, “order”, or “employee” means across them, and how processes really work when exceptions hit.They own the user relationship and operational muscle memory
Teams have trained people, built processes, and carry accountability for outcomes. Even if the screen changes, the ownership doesn’t evaporate.
In regulated industries, this becomes non-negotiable. You can’t have probabilistic systems updating critical records without strong controls, traceability, and clear accountability.
Everyone wants to own orchestration (because that’s where leverage lives)
The orchestration layer is where user experience lives, where behaviour changes, and where commercial leverage tends to land. That’s why multiple players can make plausible claims:
Microsoft can push Copilot as the horizontal interface because it sits across identity and day-to-day work surfaces. The challenge is depth across wildly different business rules and data models.
Salesforce can position Agentforce because it already sits in customer execution paths. The challenge is persuading organisations a CRM vendor should own the wider agent strategy.
ServiceNow has a strong story where work spans systems and needs control, especially across IT and operations. The challenge is expanding beyond its historic core.
ERP and HCM platforms (SAP, Oracle, Workday) bring deep governance in their domains. The challenge is orchestrating beyond their ecosystems without building another garden wall.
The likely outcome isn’t one orchestration layer. It’s multiple orchestration surfaces aligned to organisational boundaries, because that’s how budgets, accountability, and risk management already work.
The data effects nobody should ignore: context changes risk
Agents thrive on context. Context is built from data. And data rarely behaves the way the slide deck suggests.
When you unify context in a data platform, you also create new security and governance pressure points:
Data lineage becomes a security requirement, not a “nice to have”
If an agent makes a recommendation, you’ll want to know which datasets shaped it and whether they were current.Access patterns shift from “user opens app” to “agent queries everything”
That changes the threat model. It’s no longer just interactive access; it’s automated, cross-system, and often high volume.The risk of inappropriate disclosure rises quietly
A single prompt can pull sensitive context into a response. That’s a data privacy problem as much as it is a security problem.
This is where “Generative AI security” stops being a headline and becomes day-to-day operational design.
So what’s the cost, really?
There’s the obvious cost: licences, platforms, implementation, and ongoing operations.
But the harder cost is the one that shows up later:
Duplicated spend as departments buy their own agents and point solutions “just to move faster”
Higher data platform bills because warehouse usage grows when it becomes the context engine (try defending a 40% increase because it “enables other teams”)
Governance overhead because security, legal, and compliance will require controls that many early agent deployments don’t include
Incident cost when the wrong action is taken, the wrong record is updated, or sensitive context is exposed
And then there’s the cost nobody likes naming: ownership. If an agent acts across systems, the organisation needs to agree who owns outcomes, who owns failures, and who carries audit responsibility.
Governance is the forcing function most demos underplay
Every agentic architecture quietly assumes the same thing: agents can query context here, execute there, and update elsewhere.
That’s not how regulated environments run once security, legal, and compliance lean in. The questions become direct:
Where is the audit trail?
What identity executed the action?
What data was used as context?
Was the agent authorised to access that data in that moment?
What controls prevent exfiltration or inappropriate disclosure?
What policy constrains high-risk workflows?
What evidence exists for an auditor?
In the real world, governance isn’t an overlay. It’s the shape of the system.
If agents must operate through governed platforms rather than around them, systems of record keep their commercial gravity even if the interface becomes more agent-driven.
Where this lands: architecture is easy, operating models are hard
Right now, most organisations are still in the architecture phase, not the operating model phase:
People still work inside the same apps they’ve always used.
Data platforms are being modernised to support departmental AI initiatives.
Agentic tooling is adopted opportunistically, often without coordination.
Governance and security lag in less regulated areas, and clamp down quickly in regulated ones.
The clean “agent layer across the enterprise” story might come later. But the path there runs through cost models, ownership, security and governance that actually fits how enterprises are funded and audited.
If you’re exploring AI cybersecurity tools, incident summarisation with AI, or broader cyber threat response automation, the best move is to treat agents like what they really are: a new interface to your data and execution systems. That interface can be brilliant. It can also be expensive and risky if you don’t design for trust from day one.
If you’re seeing this play out in your own stack, I’d love to hear what’s getting in the way: funding, identity, data quality, or the sheer politics of “who owns it”.
Tags #
#MicrosoftSecurity
#MicrosoftLearn
#CyberSecurity
#MicrosoftSecurityCopilot
#Microsoft
#MSPartnerUK
#msftadvocate
WordCloud #
Secure AI Foundry
Secure AI Agent Foundry
AI Security Foundry
Secure Agentic AI
Enterprise AI Agent Security
Secure AI Operations
Secure AI at Scale
AI Safety by Design
AI-SecOps
AI-native SecOps
Microsoft Defender for AI agents
Microsoft Defender for AI security
Microsoft Agent 365 security
Secure Microsoft AI agents
Microsoft AI agent posture management
Defender AI agents Ignite
Microsoft secure AI development
Azure AI Foundry security
Secure Azure AI Foundry patterns
Azure AI agent security best practices



This tension between architecture diagrams and funding realities is spot on. The "who signs the PO" question is usually where these multi-system agent strategies collapse. Seen this play out where the data platform team builds the context layer, app owners refuse to fund agents they don't control, and IT ends up with unfunded mandates for governance. The audit trail requirements around cross-system actions are gonna force alot of architectures to get way more explicit about delegation and authorization boundaries.