Human approval for OpenAI Agents SDK function calls that move money under NYDFS

How function calls work and where approval can be inserted

In the OpenAI Agents SDK, a developer defines a function tool with a name, a description and a typed parameter schema. The model reads those definitions and, when it judges a tool relevant, produces a structured request to call it with specific arguments. The application then runs the function and returns the result to the model. The model decides to invoke. The application code performs the action.

That split creates four places to insert a control. The first is tool exposure: which agents are given which functions at all. The second is inside the function wrapper, where code can validate arguments before acting. The third is between the model's call request and execution, where an approval or interruption step can pause the run until a person responds. The fourth is outside the application, at a layer every call passes through.

The SDK supplies tool definitions and hooks for application-level checks and approval. These patterns are usually written into each team's code, so thresholds, approver logic and records differ between teams. For a function that moves money, the model's decision to call it is not a sufficient control, and a check that each team re-implements is hard to demonstrate consistently.

Classify money-moving tools by risk and define escalation criteria

Start with an inventory of every function tool that can initiate payments, transfers, refunds or other money movement, and assign each a risk tier. Tie the tiers and escalation criteria to a documented risk assessment. The specific criteria below are design proposals, not Part 500 requirements, and your own risk assessment should set the values.

Four criteria carry most of the weight: amount, whether the payee or account is new, the privilege level of the credentials the function uses, and whether the action can be reversed. A tier model might look like this.

• Tier 1: read-only: Balance or payee-status lookups. Allow, with the call recorded.
• Tier 2: reversible, low value: Refunds to the original payment method under a set amount. Allow within policy limits.
• Tier 3: elevated: Transfers above a threshold, or any payment to a new payee or account. Escalate for human approval.
• Tier 4: irreversible or privileged: Wires, or changes to payee banking details. Escalate to a more restricted approver role, or block for agent use entirely.

How NYDFS Part 500 relates to agent tool calls

Part 500 does not mention agent function calls in the material reviewed for this guide, so the mapping is by analogy to its stated principles. As of November 2026, the Second Amendment, effective November 1, 2023, is the most recent amendment in the consolidated text.

The cybersecurity program must be based on the covered entity's risk assessment. That supports deriving tool tiers and escalation criteria from a documented assessment rather than from engineering preference. Part 500 also requires limiting the number of privileged accounts, limiting their access functions to what the user's job requires, and limiting their use to when those functions are needed. An agent that can initiate payments holds a privileged capability, and the same least-privilege logic applies to which agents get the tool and which people can approve its use.

The program must include procedures for the secure development of in-house applications and for evaluating the security of externally developed ones. Agent code and its tool layer fall into one or both categories, so the approval path should be tested and the results retained. A covered entity must notify the superintendent within 72 hours of determining that a cybersecurity incident has occurred at the entity, its affiliates or a third-party service provider, so incident procedures should account for hosted model and agent providers where the entity determines they qualify. Senior management is responsible for the program and files the annual certification, so approval policy ownership should map to that accountability.

NIST's October 2026 design tenets for agent identity describe human-in-the-loop triggers: organization-defined risk thresholds that start human review, with technology components able to route escalation to the correct authority. NIST also notes that binding agent identity to the human approver's identity is an open question, which makes approver identity in the decision record a deliberate design choice.

Approval design patterns

Thresholds and payee conditions decide whether a call escalates. Combine them rather than relying on amount alone, since a small transfer to a new account can be riskier than a large one to an established payee. Keep the trigger and routing logic separate from the model, so the agent cannot influence whether it is asked to wait.

Approvers should be role-based and limited to the tiers they are authorised for, and the approver should not be the person or process that initiated the request. Send the approver enough context to decide: the tool, the arguments, the amount, the payee and its history, the requesting agent and user, and the policy that triggered escalation. NIST notes that this may require more than the triggering condition alone.

Define denial and timeout behaviour in advance. A denial should return a clear refusal to the agent, and the policy should address whether the agent may retry with changed arguments. For timeouts, default-deny is the conservative choice, but this is an organisational decision. Finally, watch escalation volume. If approvals arrive so often that people approve them habitually, the control has failed in practice. Review approval rates and rubber-stamping patterns, and tune thresholds under a named owner.

• Combine amount, payee novelty, privilege and irreversibility in each trigger
• Use role-based approvers scoped to tool tier, separate from the requester
• Give approvers decision-ready context
• Default to deny on timeout unless risk assessment says otherwise
• Measure approval rates to catch consent fatigue