Microsoft governs the platform. CompFly governs agent behavior.
Agents built by enterprise teams run on Foundry and Copilot Studio. CompFly decides what they may do at the model and tool boundary, and applies the same controls to every other agent platform in use.
Where Microsoft’s boundary ends.
Microsoft ships real agent governance, and CompFly does not replace it. Here is what the platform covers, and what is still yours to answer for.
Agent identity
Entra Agent ID issues each Foundry and Copilot Studio agent its own identity, with permissions, Conditional Access, and lifecycle controls.
Identity says who the agent is, not whether a given call is within its authority. CompFly binds controls to that identity and decides each call against them.
Inventory and ownership
Agent 365 keeps a registry and map of agents, and syncs agents from connected platforms including Amazon Bedrock, Google Vertex AI, and Salesforce Agentforce.
The registry reaches the platforms Microsoft has built a connector for. An agent written in-house, in its own framework and its own container, is not in it, and those are the ones worth finding. CompFly discovers across platforms and pins each version with its models, tools, and data reach.
Content and prompt safety
Content Safety and Prompt Shields filter harmful content and mitigate injection on model input and output.
Content Safety works on text, at the model boundary. Whether this tool call, with these arguments, from this agent version, should execute is a decision one layer down. CompFly makes it at the tool boundary, before the call runs.
Data protection
Purview applies DLP, sensitivity labels, and Compliance Manager mappings; Power Platform DLP restricts connectors per environment.
DLP governs which data and connectors are reachable. Whether the agent can be steered into misusing what it is allowed to reach is a behavioral question, and that is what simulation answers.
Pre-deployment testing
The AI Red Teaming Agent probes Foundry agents for safety and security risks, generating attacks from the agent’s own tools and a policy of prohibited actions.
The result is an attack success rate for one platform. CompFly builds golden datasets from the agent’s own tools and data reach across every platform it governs, regenerates them as the agent changes, and turns every finding into a control the runtime enforces.
Audit evidence
Purview, Defender, Azure Monitor, and Sentinel produce logs, posture, and compliance signal inside the Microsoft estate.
The platform that hosts the agent also produces the evidence about it. CompFly is independent of the platform, and produces one tamper-evident record covering Microsoft and non-Microsoft agents alike.
Agent identity
Entra Agent ID issues each Foundry and Copilot Studio agent its own identity, with permissions, Conditional Access, and lifecycle controls.
Identity says who the agent is, not whether a given call is within its authority. CompFly binds controls to that identity and decides each call against them.
Inventory and ownership
Agent 365 keeps a registry and map of agents, and syncs agents from connected platforms including Amazon Bedrock, Google Vertex AI, and Salesforce Agentforce.
The registry reaches the platforms Microsoft has built a connector for. An agent written in-house, in its own framework and its own container, is not in it, and those are the ones worth finding. CompFly discovers across platforms and pins each version with its models, tools, and data reach.
Content and prompt safety
Content Safety and Prompt Shields filter harmful content and mitigate injection on model input and output.
Content Safety works on text, at the model boundary. Whether this tool call, with these arguments, from this agent version, should execute is a decision one layer down. CompFly makes it at the tool boundary, before the call runs.
Data protection
Purview applies DLP, sensitivity labels, and Compliance Manager mappings; Power Platform DLP restricts connectors per environment.
DLP governs which data and connectors are reachable. Whether the agent can be steered into misusing what it is allowed to reach is a behavioral question, and that is what simulation answers.
Pre-deployment testing
The AI Red Teaming Agent probes Foundry agents for safety and security risks, generating attacks from the agent’s own tools and a policy of prohibited actions.
The result is an attack success rate for one platform. CompFly builds golden datasets from the agent’s own tools and data reach across every platform it governs, regenerates them as the agent changes, and turns every finding into a control the runtime enforces.
Audit evidence
Purview, Defender, Azure Monitor, and Sentinel produce logs, posture, and compliance signal inside the Microsoft estate.
The platform that hosts the agent also produces the evidence about it. CompFly is independent of the platform, and produces one tamper-evident record covering Microsoft and non-Microsoft agents alike.
Each agent version reaches different tools and different data, and behaves differently as a result. A perimeter cannot see that.
Where CompFly attaches.
Three attach points across the two Microsoft platforms. Each puts the decision before the call, and none requires rebuilding the agent.
Point production callers at the governed path and every model call for that version is decided before the provider is reached. Controls attach to the version, not the agent.
One line in the Agent Framework seam governs the agent in process. Microsoft still hosts the container, and nothing has to move.
One connector per tenant, no per-agent secret, and no change to the agent, so employee-built agents get an owner and a risk tier the day they go live.
One line in the Agent Framework seam
# CompFly middleware in the Agent Framework seam from flyedge import ProtectionConfig, protect from flyedge.integrations import agent_framework_middlewares protection = protect(ProtectionConfig(mode="enforce")) agent = Agent(client=foundry_chat_client, tools=tools, middleware=agent_framework_middlewares(protection))
Where the data sits.
Run CompFly fully as SaaS, or deploy the enforcement data plane into the enterprise Azure tenant. Both options run the same controls and tests, and produce the same record. The only thing that changes is where the payloads live.
Foundry agents · Copilot agents · models · tools · knowledge
With the data plane in the tenant, prompts, model responses, tool arguments, and results never leave it. What crosses the boundary is control definitions down and decision evidence up, never the payloads themselves.
Microsoft agents, and everything else in the estate.
Foundry and Copilot agents come under the same inventory, assurance loop, runtime controls, and record as every other agent in the estate, including the ones nobody registered.
Bring us one Microsoft agent.
We will connect one Foundry project or one Copilot Studio tenant, pin a version, run the assurance suite against it, and show the gaps, the controls that close them, and the record they land in.