Scoping OpenAI Agents SDK MCP Tool Filters to Least Privilege Under NYDFS Part 500

The problem: MCP servers expose more than a task needs

An MCP server publishes a catalog of tools sized for many consumers. An agent built with the OpenAI Agents SDK that connects to it can, by default, be offered all of them, even when its task needs two or three. That gap between what is exposed and what is necessary is the least-privilege problem.

For a covered entity under 23 NYCRR Part 500, the text as of November 2026 is specific about the principle. Section 500.7 requires limiting user access privileges to information systems that provide access to nonpublic information to only those necessary to perform the user's job. It also requires limiting the number of privileged accounts, limiting their access functions to what the job needs, and limiting their use to when those functions are being performed. Privileges must be reviewed at least annually, and accounts and access that are no longer necessary must be removed or disabled.

Section 500.6 requires covered entities to securely maintain audit-trail systems that, to the extent applicable and based on the entity's risk assessment, meet the listed requirements. The regulation does not discuss AI agents. Applying 500.7 and 500.6 to an agent acting through MCP is therefore your entity's interpretation under its risk assessment, and it should be documented that way.

NIST's published design tenets for agent identity point the same direction: zero standing privilege, access bounded to the minimum scope for a designated task, and separation of duties so that no single agent holds conflicting privileges. Those tenets favor per-agent, per-task tool exposure over one broad tool set shared across agents.

Step 1 and 2: Inventory and classify the tools

Start by enumerating the tools each MCP server exposes, per server and per environment, and store the result as a versioned artifact. Tool names and descriptions are supplied by the server, so your team should assign the classification rather than inherit it from the server's own description. Re-run the inventory on a schedule, because a server can add tools after your filters were written.

Classify each tool on two axes. The first is action risk: read-only, write, or open-ended, such as code execution. The second is data sensitivity: whether the tool can reach nonpublic information, and whether outputs from several tools could be aggregated into something more sensitive than any one source. NIST material on agent tool use recommends strict tool scopes, restricted-interaction tools over open-ended ones, and limiting write access. Treating write-capable tools and tools that touch nonpublic information as higher risk is a reasonable inference from 500.7, not a stated requirement.

• Tier 1: read-only, no nonpublic information: Candidate for static allowlisting with standard review.
• Tier 2: read access to nonpublic information: Allowlist per role, with redaction and rate limits considered.
• Tier 3: write or state-changing: Narrow role scope and human approval for sensitive calls.
• Tier 4: open-ended or high-blast-radius: Exclude by default. Require documented justification.

Step 3: Translate classification into SDK filters

SDK tool filtering gives you three mechanisms. A static allowlist names the tools an agent can see. A blocklist removes named tools. A dynamic filter function decides at run time, using context available to the application, such as the agent, the user or the task.

Prefer allowlists. A blocklist leaves every newly added server tool visible until someone notices, which is the opposite of least privilege. Use dynamic filters where exposure legitimately varies, for example when a tool is appropriate for one task type or one user population but not another. Define one tool set per agent role, derived directly from the classification, and avoid combining tools in one role that confer conflicting privileges, such as the ability to both initiate and approve a change.

Finally, test denial behavior. For each role, write tests that attempt to call a tool outside its set and confirm the call fails, then keep the results. Because agent requirements are not always fully predictable at deployment, start narrow and widen through a recorded change rather than starting broad and trimming.

Where SDK filters stop being sufficient

SDK filters are a necessary first layer, not a flaw. They reduce what an agent can see. Their limits come from where they live: in application code. A filter configuration does not by itself evidence what an agent was permitted to call on a given date, and a code change can alter it without a separate record. It decides visibility, not what happens inside a permitted call: it cannot redact a sensitive field from a response, cap call frequency, or pause a sensitive call for a person to approve.

Those gaps matter to an examiner. A configuration file shows intent. It does not show that a denial was enforced, or that a sensitive call was approved by a named person.

A runtime enforcement layer addresses this by sitting in the execution path and evaluating each tool call against policy. Trussed is one such layer. It enforces policy across models, agents, tools and MCP servers, with decisions to allow, redact, block, rate limit, or escalate for human approval, at the level of individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, and the enforcement generates audit-ready evidence that Trussed maps to NYDFS, among other frameworks. Its scope is the individual tool call. It does not provide transaction-level governance across tasks and agents.

Mapping configuration and evidence to Part 500

The table pairs each artifact with the provision it most plausibly supports and the layer that can produce it. The mappings are an interpretation for your risk assessment, and they should be confirmed against the full regulation text and your counsel's reading.

• Permitted tool set per agent role, with change history: Supports 500.7 limits on access to what is necessary. SDK configuration under version control gives the set. Runtime policy adds an enforced record.
• Denied and blocked calls: Supports 500.6 audit trail and shows enforcement. SDK tests show denial in test. Runtime enforcement records denials on live traffic.
• Human approvals and rate-limit decisions: Supports 500.7 limits on privileged use. Requires runtime enforcement, since filters cannot escalate.
• Annual access review records: Supports the 500.7 minimum annual review and removal of unneeded access. A process artifact covering each role's tool set.
• Tool inventory snapshots: Shows what each server exposed versus what each role was allowed. Produced by your inventory job.