Revoking a Copilot Studio Agent's Connector Access Mid-Session Under NYDFS Part 500

The gap between revoking access and stopping an action

A Copilot Studio agent reaches enterprise systems through connectors. When a covered entity decides to cut that access, the decision and the effect are separate events. Revocation changes a record: a connection is deleted, a policy is edited, a credential is disabled. Whether a running session stops depends on where that record is checked and how long the result is cached.

In general, a control evaluated only when a connection is established or a token is issued does not affect a call that was already authorized. A token that has already been issued usually remains usable until it expires or until the receiving system re-evaluates it. These are general properties of token-based access, not claims about any one lever, so the runbook below treats time-to-effect as something to measure in your own tenant and record for each lever, rather than assume.

The practical consequence is that revocation needs two properties: a defined sequence that covers every access path, and a way to show the moment access actually ended, not just the moment someone clicked revoke.

Native revocation levers and what each one changes

Each lever acts at a different layer. The question for an in-flight session is which layer is consulted on the next call and which layer only matters at the start of a session.

• Connection removal: Acts on the connection object the agent uses to call a system. Confirm whether calls already in progress and any cached credentials continue after removal.
• Power Platform data policy change: Acts on which connectors may be used together or at all in an environment. Test whether it is re-evaluated for running sessions or only at design and publish time.
• Entra credential or token revocation: Acts on the identity behind the connection. Already-issued tokens may stay valid until expiry unless the target system checks revocation.
• Agent unpublishing: Acts on the agent's availability to users. It does not by itself revoke credentials or connections the agent holds.
• Environment-level restriction: Acts broadly across everything in the environment. Useful as a containment step, but it affects other agents and needs an owner who can authorize it.

Mapping the levers to Part 500

Section 500.7 requires covered entities, based on their risk assessment, to limit user access privileges to information systems that provide access to nonpublic information to only those necessary for the user's job. It also requires periodic review of access privileges, at a minimum annually, and removal or disabling of access that is no longer necessary. An agent acting through a connector is an access path to those systems, so scoping connectors narrowly and removing them when the need ends is the direct application of 500.7. The risk-based rationale for each connector scope and each revocation threshold should be documented.

Section 500.12 requires multi-factor authentication for any individual accessing covered-entity information systems. NYDFS's October 16, 2024 AI industry letter adds that the regulation requires access controls beyond MFA to limit the nonpublic information a threat actor can reach if MFA fails, and that entities should, to the extent possible and appropriate to their risks, require authentication each time a user accesses an information system holding nonpublic information. That letter does not address long-lived agent sessions or cached tokens, so the design of session-level cutoff is a judgment each entity has to document. NYDFS FAQs also note that push-based MFA is not phishing-resistant, which is one reason access may need to be cut after authentication has already succeeded.

NYDFS's third-party service provider guidance is the most useful checklist for the revocation itself. It names identity federation (SSO, OAuth tokens), API integrations, service accounts and cached datasets as the artifacts to revoke or confirm removed, and it warns about residual or unmonitored access points outside routine provisioning systems. Apply that list to every path an agent uses, as of November 2026.

Where per-call enforcement complements native revocation

Native revocation is the baseline and should stay in place. Its limit is that it acts on credentials, connections and configuration, whose effect on a running session depends on caching and propagation. Enforcing policy at the tool-call level adds a decision on every call the agent makes, so a block applies to each subsequent call whatever the state of the token behind it. Escalation for human approval also lets a team narrow what an agent can do during an investigation without ending the session outright. Redaction limits what nonpublic information leaves a system on calls that are still permitted.

Trussed enforces policy in the execution path of individual interactions and tool calls, across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate-for-approval decisions enforced at runtime, not reviewed after the fact. Each decision generates audit-ready evidence, mapped to NYDFS among other frameworks, and deployment is self-managed in the customer cloud with configurable retention and data residency. Its scope is individual interactions and tool calls. It does not replace identity revocation, and it does not provide end-to-end tracing of agentic workflows.

The value to a covered entity lies in examiner scrutiny: showing the permitted scope, the calls attempted and the decision applied to each, with a timestamp for the point at which calls stopped succeeding. Whether you use Trussed or another mechanism, test the runbook on a schedule and tie the results to your 500.7 access reviews.