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.
At a glance
What this is: This is a governance analysis of Microsoft Copilot Studio versus Foundry in financial services, with the key finding that business-led and technical agent builds create different security and compliance pressures.
Why it matters: IAM, PAM, and NHI teams need a governance model that tracks how agents are built, who can create them, and what runtime enforcement exists before those agents touch sensitive data or regulated workflows.
Context
Copilot Studio and Foundry are both agent-building platforms, but they are not governed the same way. One supports low-code business users and process automation, while the other supports more complex, technically engineered agents that interact with proprietary data, cloud services, and custom tools.
In financial services, that difference matters because the control problem is not just who can build an agent. It is how discovery, privilege scoping, monitoring, and runtime enforcement adapt when citizen development and mission-critical automation coexist in the same ecosystem.
The governance gap is broader than platform choice. Financial institutions need to understand where agent creation is decentralised, where sensitive access is issued, and where policy enforcement has to move from review to runtime.
Key questions
A: Governance becomes fragmented, because business users and technical teams create agents with different risk profiles, ownership patterns, and privilege expectations. Security teams then lose a consistent way to inventory, review, and enforce policy across the agent estate. The result is blind spots that show up first as shadow AI, excessive access, and inconsistent compliance coverage.
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. Once an agent is trusted to operate inside a business process, a prompt injection, overbroad permission, or misconfiguration can turn that trust into unauthorised action or data exposure. Runtime enforcement is what separates intention from impact.
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. If any of those answers require manual reconstruction, governance exists on paper but not in operations.
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.
Technical breakdown
Low-code agent building changes the governance surface
Copilot Studio lowers the barrier to entry by letting business users build conversational agents and workflow helpers without deep technical skill. That shifts risk from a small central development group to a wider population that may not understand data boundaries, approval paths, or privilege design. The security issue is not the low-code model itself. It is that the build process can outpace governance if discovery and policy are still centralised around traditional IT workflows. In practice, the attack surface grows when business units can create agents that touch internal systems before security teams have inventory, review, and enforcement in place.
Practical implication: treat low-code agent creation as a governance intake problem, not a software delivery problem.
Mission-critical agents need stronger runtime controls than workflow bots
Foundry is positioned for more advanced agents that orchestrate across data sources, models, and internal services. That means the control burden is heavier because these agents may make decisions, combine tools, and act across regulated workflows. In a financial services setting, this is where policy boundaries, testing discipline, and runtime enforcement matter most. Static approval is not enough if an agent can keep operating after initial review. The technical distinction is that mission-critical agents are not just automations with a UI. They are execution layers that can concentrate privilege and amplify mistakes across multiple systems.
Practical implication: apply stronger authorization, logging, and runtime policy controls to mission-critical agents than to simple productivity assistants.
Shadow AI emerges when agent creation is decentralised
When non-specialists can build agents quickly, organisations lose line of sight into what exists, who owns it, and what data it can reach. That is the shadow AI problem in practice: unsanctioned or poorly governed agents appear faster than security teams can inventory them. In financial services, the risk is not only unauthorised tooling. It is inconsistent control design, because some agents will be created outside standard development and approval pathways. This creates blind spots for monitoring, recertification, and incident response, especially when agents are tied to business processes that security teams do not directly own.
Practical implication: continuous discovery and ownership tracking are mandatory once business users can create agents independently.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
- McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Low-code access expands the governance perimeter faster than security teams can review it. Business-led creation changes the ownership model because more people can publish agents without the same engineering controls used by central IT. That creates a larger inventory, more inconsistent privilege decisions, and a bigger chance that agents become shadow AI. The practitioner takeaway is that discovery and policy enforcement must move closer to creation, not remain dependent on periodic review.
Runtime enforcement is the decisive control when agents can act on behalf of users. The article correctly identifies prompt injection, excessive privileges, and data exfiltration as shared risks. Those risks are not fully addressed by pre-deployment review because the harmful action often occurs after the agent is already trusted. Financial services programmes should therefore treat runtime policy as the control that determines whether the agent can actually do harm.
Access review assumptions weaken when the subject is an autonomous workflow layer. Access reviews were designed for identities whose permissions persist long enough to be inspected on a schedule. When an agent can be created quickly, altered often, and used in multiple workflows, the review cycle can lag behind the operational reality. The implication is not simply better review cadence. It is that governance has to observe agent behaviour continuously and not assume a stable identity posture.
Unified governance is becoming a category requirement in regulated industries. The article points to a market direction where separate treatment for business-built and technical agents is no longer sustainable. Financial institutions need one governance model that can cover citizen-developed assistants, developer-built orchestration layers, and the data access they share. Practitioners should expect the market to reward controls that unify inventory, privilege scope, and enforcement across both platforms.
From our research library:
- 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.
- Read next: Agentic AI Security Guide
What this signals
Governance has to follow the agent lifecycle. In financial services, the important question is no longer which platform produced the agent, but how discovery, privilege scope, and enforcement move as that agent is created, changed, and used. Programme teams should assume that policy written only at build time will lag once business users and developers are both creating agents.
Shadow AI becomes a governance by-product when creation is decentralised. The more people who can build agents, the more likely it is that some will sit outside central visibility or be owned informally. That means security teams need continuous inventory, ownership attribution, and runtime guardrails rather than periodic clean-up after the fact.
Runtime control is where the governance model becomes real. Access review alone is too slow if the agent can initiate actions, combine tools, and operate on sensitive data before the next review cycle. Organisations should treat policy enforcement at execution time as a required layer, not an optional enhancement.
For practitioners
- 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.
- Move enforcement into runtime policy Block unsafe tool calls, data access, and transaction steps while the agent is operating, rather than relying only on pre-deployment approval.
- Tie monitoring to agent ownership Require a named business or technical owner for every agent so monitoring, recertification, and incident response have an accountable destination.
Key takeaways
- Financial services agent governance must distinguish between low-code business builders and technical teams because the risk profile changes with who creates the agent.
- Shadow AI is a predictable outcome when agent creation spreads beyond central IT and security teams do not maintain continuous inventory and ownership.
- Runtime enforcement matters because the main failure mode is not just who built the agent, but what the agent can do once it is trusted in a live workflow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on agents acting on behalf of users with excessive or inconsistent privilege. |
| Recommendation — Constrain agent privileges to the minimum required and review every delegated action path. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agent access scope is a central risk when business and technical users can create agents quickly. |
| Recommendation — Audit agent entitlements for overprivilege and remove access that exceeds the stated use case. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governance structure, ownership, and oversight for AI agents. |
| Recommendation — Define accountable ownership and oversight for every agent across its full lifecycle. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Privilege scoping and authorisation boundaries are central to the article's governance concerns. |
| Recommendation — Apply entitlement controls to ensure each agent can access only approved data and actions. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The article discusses prompt injection, privilege abuse, and data exposure as adverse outcomes. |
| Recommendation — Map agent abuse scenarios to credential access and impact tactics in detection and response planning. | ||
Key terms
- Agent Lifecycle Management: The process of provisioning, governing, updating, and retiring an AI agent or other non-human identity. It includes credential issuance, permission changes, logging, rotation, and offboarding. Without lifecycle control, agents can retain access after their business purpose ends, creating persistent risk.
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
- Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
- Agent Privilege Scope: Agent privilege scope is the set of tools, data sources, and actions an AI agent is allowed to use. When scope is too broad, a successful prompt attack can turn into a data access or workflow incident, making privilege boundaries a core AI governance control.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org