Reg S-P Incident Response for Copilot Studio Agents: Detecting Unauthorized Access to Customer Information

What the Reg S-P response program requires

Under 17 CFR 248.30, as amended in the 2024 adopting release, a covered institution must maintain written policies and procedures covering administrative, technical, and physical safeguards for customer information. Those policies must include a program reasonably designed to detect, respond to, and recover from unauthorized access to or use of customer information, including procedures to notify affected individuals. This is the rule's status as of November 2026.

Three parts of the text matter most for agent design. The program must include procedures to assess the nature and scope of an incident and to identify the customer information systems and types of customer information that may have been accessed or used without authorization. It must include procedures to contain and control the incident to prevent further unauthorized access or use. And it must address both access and use: the adopting release says any instance of either triggers the program.

Notification attaches to sensitive customer information that was, or is reasonably likely to have been, accessed or used without authorization. That standard means the institution needs enough evidence to say what an agent did, and to say what it did not do.

Where Copilot Studio agents touch customer information

A Copilot Studio agent is not a single system with a single permission. It can reach customer information through connectors, knowledge sources, plugins, and tool actions, often under broad delegated permissions. Each path is a separate route to data, and each can reach different systems and different types of customer information.

The rule's duty to identify affected systems and data types implies a standing inventory. For every agent, record each access path, the customer information system behind it, the data types it can return, and the identity or delegated permission it uses. Without this mapping, a scope assessment after an incident starts from zero.

Broad delegated permissions create the central problem. A permission may technically allow an agent to read a record that the agent's purpose does not call for. Platform permissions answer what an agent can reach. They do not answer what it is authorized to access or use. The institution has to write that second definition itself.

Define unauthorized access and use at the tool-call level

Because the rule keys on unauthorized access and unauthorized use, no agent interaction can be classed as an incident until the institution has defined what is authorized. Do this per agent, per data type, and per purpose. The detection conditions below are institution-defined, not regulator-defined. Treat them as a starting set to adapt.

Cover both limbs. Access conditions ask whether the agent should have touched the data at all. Use conditions ask whether data the agent legitimately retrieved was then used for a purpose or sent to a destination outside its approved scope.

• Out-of-scope data type: A tool call or knowledge retrieval returns a customer data type outside the agent's approved list.
• Out-of-scope system: A connector or action reaches a customer information system the agent is not mapped to.
• Purpose mismatch: Retrieved customer information is used in a task the agent's approved purpose does not cover.
• Unapproved destination: An agent response or action sends customer information to a recipient, channel, or external tool outside policy.
• Unusual volume or pattern: Retrieval volume or call sequence departs from the agent's normal behavior.
• Missing approval: A sensitive action completes without the human approval that policy requires.

Runtime enforcement: allow, redact, block, escalate

Reviewing agent activity after the fact leaves a gap. By the time a reviewer sees the event, the data has already been returned or the action completed. The rule does not mandate runtime enforcement, but its containment duty is framed as preventing further unauthorized access or use. Policy enforced in the execution path fits that duty more directly than review after the fact.

Four decisions cover most cases at the interaction and tool-call level. Allow the call when it matches the agent's defined scope. Redact specific fields when the agent needs a record but not every element in it. Block the call when it falls outside scope, which contains the event before data leaves. Escalate for human approval when the call is plausible but sensitive enough that a person should decide.

Each decision has a tradeoff. Strict blocking raises false positives and may interrupt legitimate work. Frequent escalation creates approval fatigue and delay. Tune the thresholds per agent and data type, and review the outcomes. Enforcement must also preserve evidence. Containment that discards the record of the attempted call removes what the response team needs to assess scope.

Evaluating a runtime control layer, and where Trussed fits

Before adding a control layer, test it against the response program. Can it act before data is returned or an action completes, rather than only recording the event? Does each decision produce a record that names the agent, system, data type, and policy? Can those records feed the institution's incident assessment and notification workflow? Which access paths does it cover, and which does it leave out? Answer the last question per path, because a layer that covers tool actions but not knowledge sources leaves a gap in the inventory.

Trussed is one option for this layer. It enforces policy in the execution path across models, agents, tools, and MCP servers, with allow, redact, block, rate limit, and escalate for human approval, scoped to individual interactions and tool calls. Enforcement is runtime, not reviewed after the fact, and it generates audit-ready evidence as a by-product. It can be self-managed in the customer's cloud, with configurable retention and data residency. Trussed does not trace entire agentic workflows end to end or provide transaction-level governance, so the institution still owns its own definitions of authorized access and its incident assessment process.

A practical next step is to inventory one high-risk agent, write its authorized scope, and run its tool calls against the detection conditions above.