Copilot Studio HTTP Request actions: egress controls for NYDFS-regulated banks

Where outbound data can leave through an HTTP Request action

In general terms, an HTTP request action lets an agent send a request to a URL, with a method, headers and a body, and then use the response in its next step. Each of those elements is a place where data can leave or where control can be lost. The URL can carry data in the path or query string. The body can carry conversation content, variable values or the output of earlier tool calls. Headers and authentication settings determine which identity the destination sees.

Three risk patterns matter for security engineers. The first is SSRF, which OWASP defines as an attack vector that abuses an application to interact with the internal or external network or the machine itself. Applying that definition to agent HTTP tools is an inference, but a direct one: if the destination can be influenced by model output, the agent can be steered toward targets the bank never intended.

The second is excessive agency. OWASP describes it as the vulnerability that enables damaging actions in response to unexpected, ambiguous or manipulated model output, regardless of the cause of the malfunction. The third is injected instructions in content the agent processes. OWASP's incident round-up describes a Microsoft 365 Copilot vulnerability in which instructions embedded in received emails led to internal data being exfiltrated without user action. That case involved a different product, but the pattern is the same one an HTTP tool exposes: untrusted content influences an outbound call. OWASP's secure-coding guidance lists unrestricted URL fetching without egress controls as something to avoid.

What platform controls cover and the residual gap

Power Platform DLP policies, connector restrictions, network isolation and endpoint allow-listing are the right first layer. They govern configuration: which connectors can be used together, which environments can reach which networks, and which endpoints a maker can wire into an agent. For a bank, these controls reduce the number of paths that can exist at all, and they are the baseline an examiner will expect to see.

They do not, by themselves, decide whether a specific call made at runtime is appropriate. A destination can be on an allow-list and still receive a payload it should never see. A permitted agent can be manipulated by content it reads into making a call its designer never anticipated. A configuration review shows what was set up. It does not show what the agent actually sent on a given Tuesday, or why that call was allowed.

This is the residual gap: per-call decisions on destination, payload and authentication, and per-call evidence. OWASP's guidance points the same way, recommending enforced scope, isolated tools and credentials, and monitoring of actual actions rather than relying on configuration alone.

Mapping egress risks to Part 500 expectations

The mapping below is interpretive. DFS states that Covered Entities must implement and maintain risk-informed cybersecurity policies and programs, which is the frame for the whole exercise: the risk assessment should name agent outbound calls as a data path and the controls should follow from it. As of November 2026, no AI-specific expectations should be attributed to NYDFS on the basis of the regulation text alone, so the argument to an examiner is that existing requirements apply to a new kind of system.

The Part 500 text lists access controls, including remote access and identity management. For an agent, that translates to who or what is allowed to call which destination, under which credential, and who approved that scope. It also includes a third-party service provider's access control policies, including its use of multi-factor authentication. Whether an external endpoint an agent calls counts as a third-party service provider is a bank-specific determination to make with compliance counsel, and the destination policy in layer 2 is where that determination should be recorded.

Data protection and audit trail expectations are where per-call evidence matters. A permitted-destination list plus per-call records lets a bank show what nonpublic information was allowed to leave, what was redacted or blocked, and who approved exceptions. For Class A companies, the text also calls for independent audits of the cybersecurity program based on the risk assessment. Auditors can only test what produces records, so evidence design should be settled before the first audit, not after.

Examiners are likely to ask for two things in sequence: what the agent was permitted to do, and what it did. The first is answered by policy and configuration. The second is answered only by per-call records that name the destination, the payload handling decision, the policy applied, any approver and the time.

Where runtime enforcement fits, and what Trussed does

The decision in layer 5 has to be made in the execution path, at the moment the agent attempts the call. A review after the fact can explain an incident, but it cannot stop a payload that has already left. OWASP's guidance to log AI interactions, monitor for anomalous data flows and set policies that prevent AI from executing actions without oversight describes the same requirement from the security side.

Trussed is built for this layer. It enforces policy in the execution path across models, agents, tools and MCP servers, with outcomes of allow, redact, block, rate limit or escalate for human approval. Its scope is individual interactions and tool calls. It does not provide transaction-level governance or end-to-end tracing of agentic workflows, so those questions need other controls.

The enforcement itself generates audit-ready evidence, mapped to frameworks including NYDFS and NIST, so the record of what was permitted and what happened is a product of the decision rather than a separate reconstruction. Trussed supports self-managed deployment in the customer cloud, with configurable retention and data residency, which matters when evidence itself contains sensitive material. It has run continuously in production in a regulated enterprise for 18+ months, with 99.95% uptime on live production traffic. Insurance, a regulated financial sector, is where Trussed is deepest.

For model risk management teams, the useful question is whether each agent tool call can be shown to have passed through an enforced policy and produced a record an examiner can read. Evaluate any approach, Trussed or otherwise, against that test.