Securing Microsoft Copilot Studio Agents

Microsoft Copilot Studio security is not a connector review exercise. It is an effective-access problem. Copilot Studio is a low-code platform that lets business users build conversational agents to summarize documents, triage tickets, update records, and act across Microsoft 365 and hundreds of connectors. That accessibility is exactly why security teams struggle with it. When anyone can ship an agent, agents multiply faster than any review process built for software releases, and each one carries credentials.

Sprawl is not a Microsoft failure. It is a shared responsibility gap. Microsoft secures the Copilot Studio infrastructure. You own how agents are configured, who builds them, which connectors they attach, and who is allowed to invoke them. That customer-owned layer is where the security work lives, and it is where most teams have no authoritative system of record. The question a CISO usually cannot answer on demand: which Copilot agents exist in our tenant, who built them, what credentials do they carry, and what data have they actually touched.

How a Copilot Studio agent is put together

Each agent is assembled from a few parts, and every one of them has a security consequence:

• A creator identity, the maker, whose credentials often back connector authentication.
• Knowledge sources such as SharePoint sites, uploaded files, web content, and Dataverse tables.
• Connectors into Microsoft services and third-party apps like Salesforce, ServiceNow, and Jira.
• A publish scope: specific users, org-wide, or a public URL.
• Actions and topics that decide what the agent is permitted to invoke.

Put together, an agent is a non-human identity with credentials, permissions, and a blast radius. It is not a chatbot in the old sense, and treating it like one is how tenants end up with an unmanaged population of machine insiders.

The connector is not the risk. The effective authority behind the connector is. When a maker builds an agent and authenticates a Salesforce connector, that connector often uses the maker's own OAuth token. Every user who later invokes the agent inherits that access path. If the maker is a Salesforce admin, invokers can reach admin-tier data. If the same connector is shared with other agents, the reach extends further with no additional review.

Common exposure paths run through the connector layer:

• SharePoint knowledge sources with broader library permissions than the maker realized.
• Dataverse tables holding HR, finance, or customer records.
• Third-party connectors to Salesforce, ServiceNow, or Zendesk authenticated with admin-level credentials.
• HTTP connectors pointed at unregistered internal domains, creating data paths nobody reviewed.
• High-risk OAuth scopes granted once at setup and never re-examined.

Why the connector list tells you nothing

Reading the connector list tells you which systems an agent can talk to. It does not tell you which invokers can reach which records inside those systems. That answer only exists when you correlate four things at once: the agent, the connector's authentication mode, the invoker's identity, and the target app's actual entitlements. The most dangerous pattern is a combination, not a single setting: a maker-built agent, published org-wide, with a connector reaching sensitive data. Any one factor is manageable. Together they become a critical priority, because the agent quietly turns a low-privilege user into a high-privilege one.

Discovery is the prerequisite for every other conversation. If you cannot list every Copilot Studio agent in your tenant, you cannot govern any of them. A usable inventory answers a fixed set of questions for each agent:

1. Which agents exist across every environment in Copilot Studio?
2. Who created each one, and is that account still active?
3. Which connectors are attached, and in what authentication mode?
4. What is the publish scope: private, org-wide, or public?
5. Which knowledge sources and labeled content does it touch?
6. When was it last invoked, by whom, and against what data?

Native admin views inside Copilot Studio show configuration one environment at a time. They do not correlate identity, connector authentication mode, and downstream entitlements across a tenant. Purview logs exist but need manual stitching to reconstruct who reached what. Practical inventory requires an external system of record that treats each agent as a first-class non-human identity, the same way a mature program already tracks service accounts.

Orphaned agents are the new stale service accounts

The account that built an agent gets disabled at offboarding. The agent keeps running. It still holds the connector authentication the maker set up, so it continues reaching data on credentials that no longer belong to an active employee. These orphaned agents are the AI-era equivalent of the stale service account nobody rotated, and they are among the first things a discovery pass should surface and shut down.

Effective access is what an agent can actually retrieve, on behalf of any invoker, once every entitlement resolves across Microsoft 365 and connected apps. It is almost always broader than the maker pictured when they built the thing.

Take a concrete scenario. A support manager builds an agent to answer "what is the status of my case?" The agent uses a Salesforce connector authenticated with the manager's credentials. That manager also happens to see pipeline data, opportunity notes, and executive accounts. A frontline rep asks the agent a routine status question, and with the right follow-up prompt, pulls pipeline data they were never provisioned for. Nothing was hacked. The identity system was bypassed by design. The agent did exactly what it was configured to do, and the invoker received data at the maker's privilege level.

This is where runtime truth separates from theoretical configuration. The vendor's config page shows the connector and its scopes. It does not show that this agent, acting through this service account, can read these specific Salesforce objects and run these specific actions for a user who has no Salesforce license at all. Correlating an agent's activity to its effective access inside the third-party app is the whole game. Mapping it requires:

• The maker's identity and their entitlements in every connected app.
• The invoker's identity and their entitlements in every connected app.
• The delta between the two, which is the privilege escalation path.
• The agent's configured knowledge sources and their real permission scopes.

Agents move roughly sixteen times more data than a human user does, and industry estimates put around ninety percent of agents in the over-permissioned category. Apply those numbers to a bypass like the one above and the exposure is not theoretical. It is a machine insider operating at scale, and the delta is the number that belongs in a report to the audit committee, not a tenant-level agent count.

The cheapest place to fix a Copilot agent is before it goes live. A governance-before-publish policy narrows how many agents ever reach the point of needing a runtime block:

• Owner attestation. The maker confirms, on the record, that the agent will run with their credentials.
• Publish-scope review. Any org-wide or public publish requires security sign-off rather than a default click.
• Connector authentication review. Fixed-credential connectors touching sensitive data need explicit approval.
• Knowledge-source labeling. Labeled or regulated content triggers automatic review before publish.
• Ownership metadata. Every agent carries a business owner and a technical owner, both tied to active accounts.

Pre-publish controls do not replace runtime enforcement. They lower the volume of agents that runtime enforcement has to catch.

The frameworks that actually apply to you

Copilot Studio inherits Microsoft's platform certifications, covering the infrastructure Microsoft runs. Those certifications say nothing about how your makers configure agents, which is where audit findings actually land. The frameworks that speak to the customer-owned layer are the ones to organize around: the NIST AI Risk Management Framework for AI governance, ISO 42001 for AI management systems, MITRE ATLAS for adversarial threat modeling, and the OWASP low-code and no-code guidance for risks like account impersonation and excessive data access. Map your pre-publish controls to those and the governance story holds up in an audit.

Copilot is one of only two platforms where runtime enforcement is real today. That matters because detection without prevention is expensive logging. Present tense is accurate here: security teams can act inside the request window rather than reconstructing the incident afterward.

Runtime enforcement for Copilot agents means:

• Deterministic guardrails on probabilistic agents. Fixed rules remove action options inside a roughly one-second window, no matter how the agent phrased its intent.
• A block on privilege mismatch. If the invoker's identity does not carry the entitlement the requested action needs, the action does not complete.
• An alert on toxic combinations. A shadow agent with org-wide reach running a sensitive Salesforce query surfaces immediately instead of hiding in logs.
• Confused-deputy prevention. An agent being steered into using elevated permissions for an unauthorized user is stopped before the query returns.

Obsidian is not an inline gateway. It hooks into Copilot Studio's platform APIs and webhooks and runs on an Intel Inside decision-engine model, supplying the block-or-allow verdict without sitting in the data path of every downstream app. No connector into each SaaS system is required, so security teams deploy without chasing IT sign-off on every app an agent might touch. The point is not that Obsidian sees more agents. It is that it knows what authority each agent actually holds and what that agent can do with it.

Where the other platforms stand

Copilot's runtime maturity reflects the depth of Microsoft's platform APIs, not a claim that the underlying risk is higher or lower than anywhere else. Across the rest of the agent landscape the picture is different, and it is important to label it honestly. For platforms such as Salesforce Agentforce, Amazon Bedrock, Google Vertex AI, Snowflake Cortex, ServiceNow Now Assist, Moveworks, and n8n, the available capability today is discovery and governance: inventory the agents, map their effective access, and govern them before and after publish. Runtime enforcement on those platforms is on the roadmap, not a present-tense capability. Treat any vendor claim of live autonomous blocking outside Copilot and Claude with the same skepticism you would apply to any other unverified control.

If an agent is compromised

When an agent shows signs of misuse, work it as a non-human identity incident. Disable the agent in Copilot Studio to stop new invocations. Rotate the maker's credentials and tokens across every connected app. Pull the agent's invocation history and cross-reference invokers against their expected entitlements. Review the connected apps for records touched during the exposure window, and check for shared connectors that other agents inherit. Then report the blast radius at the agent level, not as a tenant-wide metric, because the agent is where the exposure actually happened.