An Agent Security Review before a wealth manager rolls out Copilot Studio agents

A Connecticut investment adviser with about 90 staff wanted assistants for client service, research and onboarding, built in Copilot Studio. A few had already been built by staff and connected to tools without a review. The chief compliance officer asked a simple set of questions that nobody could answer from records: how many agents exist, which identity does each run as, what data can each reach, and what is logged if one misbehaves. The firm wanted facts for its counsel before it widened the rollout.

We began with an inventory from the tenant itself: each agent, its owner, the identity it runs as, its connectors and knowledge sources, and the client data those reach. We also wrote down the visibility ceiling. What a tenant can see about its agents depends on its Microsoft licences, and agents or tools outside that view are visible only through audit and sign-in logs or not at all. The firm got that limit in writing, with the list of agents and tools that sat on the far side of it, so nobody would assume coverage that did not exist.

The six MCP servers were next. MCP servers are the plug-in servers that connect an agent to tools and data. We reviewed them against the MCP authorization specification, revision 2026-07-28, and its security best practices: whether tokens are issued for the right audience, that no server passes a token through to another service, how scopes are set, and which local servers take credentials from the environment and leave no authorization log. Scanners read descriptions and configuration, so we treated their output as one input. Two servers were removed because no agent needed them.

The red team ran under a signed scope. A crafted email planted in a test mailbox steered an onboarding agent toward a request it should not have made (ASI01 Agent Goal Hijack). A research agent could be talked into calling a connector with parameters its owner never intended (ASI02 Tool Misuse). One agent ran as a shared service account with far more reach than its job needed (ASI03 Identity and Privilege Abuse). Each finding carried its OWASP identifier, reproduction steps and evidence, and a table showed which attacks the firm's logs had recorded and which they had not.

Remediation was done with the firm's IT staff: separate least-privilege identities, narrower connectors, and a person who confirms any message before it leaves the firm. We then set three approval tiers: agents that may act alone, agents that need a person to confirm each action, and uses that are not allowed. We retested every finding. The figures in this illustrative case are modeled, and a test shows what was found in scope and time, not that an agent is safe. What the firm keeps is an inventory, a test report and an approval record. Our article on the OWASP agentic list explains the categories in plain language.