Copilot Studio vs Foundry in financial services governance

At a glance

What this is: This is an analysis of how Microsoft Copilot Studio and Foundry differ for AI agent development in financial services, with the key finding that governance requirements change with user type, agent capability, and runtime risk.

Why it matters: It matters because IAM, PAM, and AI governance teams need to control who can build agents, what those agents can access, and how unsafe actions are blocked before they affect regulated workflows.

By the numbers:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Zenity's analysis of Copilot Studio vs Foundry governance in financial services

Context

Microsoft Copilot Studio and Foundry sit on the same general problem space, but they are not the same governance object. One favours low-code accessibility for business users, while the other supports more complex agent development for technical teams. In financial services, that distinction matters because agent identity, data access, and approval boundaries change with who builds the agent and what the agent is allowed to do.

The security issue is not simply that more agents will exist. It is that organisations will have both unsanctioned business-built agents and highly integrated technical agents operating across regulated workflows, core systems, and sensitive data. That creates a governance problem for AI agents, but also a familiar IAM problem: lifecycle control, access scope, and enforcement gaps that do not disappear just because the interface is easier to use.

In this environment, the starting position is typical, not exceptional. Most enterprises that adopt agent platforms first discover the governance gap after use cases spread faster than policy, inventory, and review processes.

Key questions

Q: How should security teams govern business-built AI agents in low-code platforms?

A: Start with discovery, ownership, and access boundaries. Business-built agents should not reach regulated data or operational systems until they are inventoried, assigned to an accountable owner, and checked against policy. The key control is not just approval at creation, but a repeatable review of what the agent can access and do after it is deployed.

Q: Why do technical AI agents create higher privilege risk than simple workflow bots?

A: Technical agents usually integrate with multiple systems, so a single identity can accumulate broad delegated access across models, data sources, and tools. That expands the blast radius if permissions are not tightly scoped. The risk is highest when the agent can chain actions across systems without an intervening approval or runtime policy check.

Q: What do organisations get wrong about AI agent governance?

A: They often treat agent governance as a build-time review problem. In practice, the dangerous behaviour appears at runtime, when the agent interprets instructions, selects tools, and acts against live data or systems. Governance has to cover discovery, privilege, monitoring, and intervention during execution, not just sign-off before launch.

Q: How should financial services teams decide between Copilot Studio and Foundry controls?

A: Do not choose controls by platform label alone. Decide by the agent’s user base, data access, integrations, and operational criticality. Low-code business agents need strict intake and visibility, while technical agents need deeper privilege review and runtime enforcement. The governance model should follow the risk profile, not the product category.

Technical breakdown

Low-code agent creation expands the shadow AI problem

Copilot Studio lowers the barrier to entry for non-specialist builders, which means agent creation can spread outside central platform and security teams. That is useful for speed, but it also means agent identities may be created with inconsistent naming, permissions, and oversight. The result is shadow AI: agents that perform work in production without being fully visible to IAM, security operations, or compliance teams. In regulated environments, the risk is not only the agent itself, but the absence of a reliable control plane around its lifecycle, ownership, and access boundaries.

Practical implication: security teams need discovery and ownership controls that identify every business-built agent before it reaches sensitive data or regulated workflows.

Technical agents concentrate privilege and integration risk

Foundry supports more complex agent orchestration, which usually means access to models, proprietary data sources, cloud services, and custom tools. That increases the blast radius if permissions are broad or tool access is poorly bounded. In identity terms, the issue is not model sophistication, but delegated authority. An agent that can chain actions across systems can also chain mistakes, so the security model has to consider token scope, data boundaries, tool invocation limits, and real-time policy enforcement across the full execution path.

Practical implication: platform and IAM teams should review every high-privilege integration path for explicit scope limits and runtime enforcement.

Runtime enforcement matters more than pre-build review

Both agent types can look safe at design time and still become unsafe at runtime when they interpret prompts, traverse data sources, or trigger downstream actions in ways the builder did not intend. That is why pre-deployment review is necessary but insufficient. The security boundary must exist during execution, where unsafe requests can be blocked, step-up approval can be enforced, and sensitive operations can be constrained by policy. In financial services, this is especially important because regulatory exposure often comes from what an agent does after deployment, not what it was supposed to do in testing.

Practical implication: teams should add runtime policy enforcement and behavioural monitoring to every agent lifecycle, not just design-time approval.

NHI Mgmt Group analysis

Copilot Studio and Foundry are not one governance problem. Low-code business builders and technical agent developers create different identity risks, but both collapse into the same failure mode when organisations treat agent creation as a feature rollout instead of an access governance event. Financial services teams need to classify who can create agents, what those agents can reach, and which workflows become regulated when the agent goes live. The practitioner takeaway is that platform choice changes the shape of the control problem, not the need for control.

Shadow AI is the named concept this market keeps missing. Business-led agent creation can produce sanctioned-looking systems that never pass through central review, while technical teams can build deeply integrated agents that outgrow their original risk assessment. The common thread is not intent, but visibility gaps across ownership, policy, and monitoring. The practitioner implication is that discovery and lifecycle governance must cover both citizen-developed and engineering-built agents, or the inventory will always lag reality.

Agent governance in financial services now sits at the intersection of IAM, PAM, and data governance. These agents are not just another application layer, because they can act on behalf of people, consume sensitive data, and execute downstream actions. That means access scope, privileged operations, and policy enforcement have to be evaluated together. The practitioner conclusion is that siloed reviews by app teams, IAM teams, and compliance teams will miss the actual risk boundary.

Runtime control is now a governance requirement, not a maturity upgrade. The article’s core message is that approval at build time does not prevent unsafe agent behaviour after deployment. As agents become more capable, the governing question shifts from who approved the build to what was blocked during execution. The practitioner implication is that controls must be able to intervene inside the session, not just record what happened after the fact.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to SailPoint.
• That governance gap is why practitioners should also study OWASP Agentic AI Top 10 for runtime control patterns and abuse scenarios.

What this signals

Shadow AI will become a control-plane problem, not just a discovery problem. Financial services teams that allow low-code agent creation without central inventory will keep finding agents after the risk has already spread. The practical shift is to combine intake, ownership, and policy enforcement so agent creation cannot outrun governance.

Agent governance now needs the same discipline used for privileged access. When an AI agent can reach sensitive data or trigger business actions, its permissions behave like privileged access, even if the builder never intended that outcome. Teams should therefore align agent oversight with NIST AI Risk Management Framework governance principles and treat high-risk agents as first-class privileged identities.

Runtime controls will matter more as use cases move from productivity to regulated execution. Organisations that start with chat-style assistants and later connect them to payments, client records, or compliance workflows will need intervention points inside the session, not just periodic reviews. The governance signal to watch is whether policy can stop an action before the agent completes it.

For practitioners

• Define an agent inventory owner Assign a named owner for every Copilot Studio and Foundry agent, including business-built agents that originate outside central engineering. Record the owner, data sources, downstream systems, and approval path so no agent exists without accountable stewardship.
• Separate business-built and technical agent controls Use different review criteria for low-code citizen-developed agents and technically engineered agents. Business-built agents need strict creation guardrails and inventory checks, while technical agents need deeper integration review, privilege scoping, and change control.
• Enforce runtime policy before sensitive actions Block high-risk actions at execution time, including access to sensitive financial data, outbound sharing, and transactions triggered from agent output. Pair policy enforcement with behavioural monitoring so unsafe actions are stopped before completion.
• Review agent privilege as a lifecycle issue Treat agent permissions as a lifecycle object, not a one-time configuration. Reassess scope when an agent changes purpose, data source, tool set, or business owner, because the original approval no longer matches current exposure.
• Test for shadow AI in regulated workflows Search for agents created outside formal intake channels, especially those connected to HR, client service, operations, and compliance processes. Prioritise any agent that can reach regulated data or trigger actions across multiple systems.

Key takeaways

• AI agent governance in financial services is a lifecycle problem, not a platform selection exercise.
• Low-code and technical agents create different risks, but both fail when ownership, access scope, and runtime controls are weak.
• The organisations that can discover, classify, and intervene on agents in real time will have a materially lower compliance and breach exposure.

Key terms

• Shadow AI: Shadow AI is the set of AI agents or AI-enabled workflows that operate outside formal governance, inventory, or approval processes. In practice, it becomes an identity problem when an unmanaged agent can hold credentials, reach data, or trigger actions without an accountable owner.
• Runtime enforcement: Runtime enforcement is the application of policy while an agent is executing, not just when it is designed or approved. It matters because AI agents can make decisions after deployment, so control has to intercept unsafe actions, restrict tool use, and prevent sensitive data movement in the moment.
• Agent lifecycle governance: Agent lifecycle governance is the set of controls used to create, track, review, modify, and retire AI agents over time. It extends traditional identity lifecycle thinking to non-human actors, so ownership, privilege scope, monitoring, and offboarding remain aligned as the agent changes purpose or risk.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zenity: Considerations for Microsoft Copilot Studio vs. Foundry in Financial Services. Read the original.