Topic starter
25/06/2026 12:04 am
TL;DR: Financial services teams are adopting Microsoft Copilot Studio and Foundry for AI agents, but Zenity’s analysis shows the governance problem is not platform choice alone: business-led low-code agents and technical mission-critical agents create different security and compliance pressures, especially around shadow AI, excessive privilege, and runtime enforcement. The decisive gap is governance that follows the agent lifecycle, not just the build platform.
Editorial analysis by NHI Mgmt Group, based on content published by Zenity: “Considerations for Microsoft Copilot Studio vs. Foundry in Financial Services”.
Key questions
A: Governance becomes fragmented, because business users and technical teams create agents with different risk profiles, ownership patterns, and privilege expectations.
Q: Why do agent platforms increase risk when they can act on behalf of users in regulated workflows?
A: Because the agent can combine access, data, and actions faster than a traditional review process can track.
Q: How do security teams know if agent governance is actually working?
A: It is working only if the team can answer three questions quickly for any agent: what it can reach, what it did recently, and whether that behaviour matches intent.
Practitioner guidance
- Map agent builders by operating model Separate business-led Copilot Studio creators from technical Foundry teams, then assign governance responsibilities, review paths, and escalation routes for each group.
- Inventory all agent instances continuously Track every published agent, owner, data source, and connected system so unsanctioned or duplicate agents do not remain invisible to the security team.
- Scope privileges to the smallest viable workflow Review what each agent can read, write, trigger, and export, then remove broad access that is only justified by convenience or temporary business need.
Bottom line: Financial services agent governance must distinguish between low-code business builders and technical teams because the risk profile changes with who creates the agent.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 8:53 am
Agent governance is now a lifecycle problem, not a platform problem. The article shows that Copilot Studio and Foundry create different build patterns, but the underlying issue is the same: organisations need to govern the agent from creation through privilege assignment to runtime behaviour. Financial services cannot rely on one approval checkpoint at build time because risk changes as the agent is used, modified, and connected to data. The conclusion is that lifecycle governance has to follow the agent, not the tool used to create it.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Should organisations govern low-code business agents and technical agents the same way?
A: No. They should use one governance model, but not one identical control profile. Low-code business agents need tight discovery, ownership, and access boundaries because creation is decentralised. Technical mission-critical agents need stronger testing, runtime enforcement, and change control because they orchestrate more sensitive workflows and data paths.
👉 Read our full editorial: Copilot Studio vs Foundry in financial services governance