Implementation Guide

    Building a Copilot Studio agent evidence pack for a FINRA or NYDFS exam

    A Copilot Studio agent evidence pack is a durable record, per agent, of what the agent was permitted to do, which tools, connectors and data it could reach, and what it actually did. It has five parts: inventory and scope, policy and permission baseline, tool and connector actions, human approval records, and retention and access controls. Some of it is assembled from documents. The rest is best generated by policy enforcement at runtime, so stated controls and observed behavior can be reconciled.

    What the evidence pack should contain

    • Agent inventory and scope: a unique agent identifier, business purpose, owner, intended users, and the boundaries of its intended scope.
    • Policy and permission baseline: the policies in force, the permissions granted, and a version history showing what applied at any given time.
    • Tool, connector and data source map: every tool, connector and data source the agent could reach, with the permitted operations for each.
    • Action records: per-interaction and per-tool-call records showing what the agent did and what decision was applied.
    • Human approval records: where approval is required, the request, the approver's identity, the decision, and the timestamp.
    • Retention and access controls: how long each record class is kept, where, who can read it, and who can alter or delete it.

    Start from what an examiner is likely to ask

    The most reliable way to scope an evidence pack is to work backward from examiner requests. For AI agents, those requests tend to cluster around a few questions. What is each agent for, and who owns it? What was it permitted to do? Which tools, connectors and data sources could it reach? Did a human validate its actions where one was required? Can you show what it did on a given date, under which policy?

    FINRA's 2026 Annual Regulatory Oversight Report gives these questions a regulatory shape. It lists risks of AI agents that could adversely affect investors, firms or markets, including autonomy, meaning agents acting without human validation and approval, and scope and authority, meaning agents acting beyond the user's actual or intended scope. An examiner reading that language will want evidence of the approval design and of the boundaries the agent operated within.

    This is also a model risk management exercise. Model risk practice expects a documented intended use, defined limits, ongoing monitoring, and evidence that the limits held. The pack is how you demonstrate each of those for an agent.

    Mapping artifacts to FINRA and NYDFS expectations

    On the FINRA side, three anchors matter. Rule 3110 requires a supervisory system reasonably designed to achieve compliance, with review by a registered principal evidenced in writing, either electronically or on paper, for transactions and for correspondence and internal communications. The inventory, ownership assignments and approval records are the natural artifacts for supervision. Whether a particular agent output is correspondence or an internal communication is a determination for your supervisory procedures and counsel.

    Rule 4511(a) requires members to make and preserve books and records as required under FINRA rules, the Exchange Act and the applicable Exchange Act rules. FINRA's books and records checklist summarizes some of what broker-dealers must create and retain under SEA Rules 17a-3 and 17a-4, and it is not exhaustive. Classify each pack artifact against your firm's record categories and confirm retention treatment with counsel before you set retention periods.

    For NYDFS, examiners will look at the same artifacts through a cybersecurity lens under 23 NYCRR Part 500. Map access controls, action records and approval evidence to the specific provisions your counsel identifies, and keep that mapping inside the pack so one set of records serves both examiners. As of November 2026, no change to Rules 3110 or 4511 has come to our attention.

    Where native platform records tend to fall short

    Most teams begin with what the platform already provides: agent configuration records, platform audit logs, and written policy documents. Each is useful. The difficulty is that they live in different systems, were created for different purposes, and rarely share an identifier or a policy version.

    Configuration records show what was set up. Audit logs show that activity occurred. Policy documents state intent. None of them, on its own, proves that the stated control was the control actually applied to a specific action. An examiner asking whether an agent acted beyond its intended scope is asking for a reconciliation, and assembling one by hand under exam timelines is where inconsistencies appear.

    Before an exam, test your own pack with a single sample. Pick one agent action from a past date. Can you show the agent's scope at that time, the policy version in force, the decision applied, any approval, and the retention status of the record? Gaps in that exercise show where additional evidence generation is needed.

    Evidence from documents versus evidence from enforcement

    Two kinds of evidence belong in the pack, and they should be kept distinct. Assembled evidence comes from documents: the inventory, owner assignments, written policies, supervisory procedures and retention schedules. It describes design and intent, and it is only as current as the last update.

    Generated evidence comes from runtime enforcement. When policy is enforced in the execution path, each interaction and tool call receives a decision before it takes effect: allow, redact, block, or escalate for human approval. That decision can be written as a record at the moment it is made, not reconstructed afterward.

    A useful enforcement record carries a common agent identifier, the tool or connector identifier, the policy version applied, the decision, redaction detail where data was masked, the escalation outcome and approver identity where a human was involved, and a timestamp. These fields are a design recommendation rather than a regulatory prescription. They are chosen because they let a reviewer join the permission baseline to observed actions. They also align with the NIST AI RMF emphasis on documented, measurable controls and with model risk management expectations for evidence that limits were applied.

    Set retention for these records against the books-and-records categories you identified, and restrict write and delete access so the records are credible as evidence.

    Where Trussed fits

    Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with decisions to allow, redact, block, rate limit, or escalate for human approval. The scope is individual interactions and tool calls. The enforcement itself generates continuous, audit-ready evidence, which is mapped to NYDFS and NIST, among other frameworks. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.

    This addresses one part of the pack: the action records, approval records and policy-version linkage that are hard to assemble from documents. It does not replace the inventory, supervisory procedures or counsel's retention determinations. Trussed does not provide end-to-end tracing of agentic workflows or transaction-level governance, so those questions need to be answered by other means.

    Trussed has run continuously in production at a regulated enterprise for more than 18 months, and its customers are in insurance, pharma, healthcare and education. Insurance, a regulated financial sector, is where it is deepest. It has no financial-services customers to cite in the broker-dealer or banking context. The evidence design above is a way to evaluate any approach, including this one, against examiner scrutiny.

    From examiner request to evidence artifact

    What was the agent allowed to do?

    Inventory, owner, scope, and permission baseline.

    What could it reach?

    Tools, connectors, and data sources, tied to a policy version.

    What did it do?

    Per-action decisions: allow, redact, block, or escalate.

    Who approved it, and how long is it kept?

    Approval records, retention, and access controls.

    Test your evidence pack against a real agent action

    Walk through how enforcement at the tool-call level produces policy-versioned, audit-ready evidence for your agents.

    Explore Agent and Tool-Call Enforcement
    Next step

    How does your AI governance program compare?

    See where your program has gaps in less than 2 minutes.