Running NYDFS Part 500 Privileged Access Reviews for AI Agents with Tool Access

Scope: which agents and permissions are in play

Under 500.7(a), based on the covered entity's risk assessment, access privileges to systems holding nonpublic information must be limited to what each user's job requires. The number of privileged accounts and their access functions must be limited to what is necessary, and use of privileged accounts must be limited to times when the function requires it. All user access privileges must be reviewed periodically, and at minimum annually, with unnecessary access removed or disabled. DFS's requirement checklist extends the review to third-party service providers.

The regulation defines an authorized user as any employee, contractor, agent or other person participating in the covered entity's business operations. It defines a privileged account as any authorized user account or service account that can perform security-relevant functions ordinary users cannot, including adding, changing or removing accounts or making configuration changes to information systems. Part 500 does not address AI agents by name, so the most defensible hook is the service account or credential through which an agent acts. Record that scoping rationale for each agent.

DFS's industry letter on AI-related cybersecurity risk states that it imposes no new requirements beyond Part 500. It explains how to apply the existing framework to AI risk. DFS's May 2026 letter on a heightened threat environment lists privileged access reviews among measures to consider. Both support extending your existing review program to agents rather than creating a parallel one.

Classifying agent tool permissions as privileged or not

Use the regulatory test as your classification rule: can this permission perform a security-relevant function an ordinary user cannot? Applied to an agent, the question is asked per tool, not per agent. A tool that creates or modifies accounts, changes system configuration, alters access policies or deploys code meets the test. So does a code execution environment that can reach those functions, or a ticketing or payment-adjacent integration with administrative scope. This is a practitioner mapping and not DFS guidance, so write it down as your documented rule and apply it consistently.

Non-privileged does not mean unreviewed. A read-only retrieval tool that touches nonpublic information still falls under 500.7(a)(1), which limits access to what the job needs. A workable approach is two tiers. Privileged tools receive the full review, tighter ownership and, for Class A companies, coverage by the privileged access management solution and activity monitoring required by 500.7(c). Other tools receive entitlement-to-purpose validation at the same annual review. Check the effective permission, such as the API scope actually granted or the database role actually assumed, rather than the tool's description.

A repeatable review procedure

Run the review at least annually, as 500.7(a)(4) requires. Add review points when risk-relevant changes occur, because the risk assessment must be updated on material change. DFS's example is a significant change to the software used to run the business. Practical triggers include adding a tool or MCP server, widening a credential's scope, or changing an agent's purpose. The steps below form one cycle.

• 1. Build the inventory: List every agent with its service accounts, credentials, connected tools, data stores and a named human owner. Include agents acting through a third party's service.
• 2. Classify each tool permission: Apply the documented privileged account rule and record the rationale and the resulting tier.
• 3. Validate entitlement to purpose: The owner states what the agent is for. The reviewer confirms each granted permission is necessary for that purpose, per 500.7(a)(1) and (a)(2).
• 4. Remove or disable excess access: Revoke over-scoped, unused or orphaned credentials and tools. Disable access promptly when an agent is retired, treating 500.7(a)(6) as an analogy for departures.
• 5. Handle exceptions: Where necessary access cannot be narrowed, record the business reason, compensating control, approver and an expiry date that forces re-review.
• 6. Sign off and feed the risk assessment: The accountable reviewer approves the outcome. Findings update the risk assessment and the agent access procedures.

What a review can verify and what only runtime enforcement can show

A periodic review inspects granted entitlements: which accounts and credentials exist and what access they hold. That fits the 500.7(a)(4) requirement to remove access no longer necessary. It cannot show how an agent used that access. An agent's effective privileges also depend on runtime behavior, such as which tool it chose, with what arguments, and on whose behalf. Entitlements are a ceiling, not a record of conduct.

That gap is where enforcement in the execution path helps. Trussed enforces policy at runtime on individual interactions and tool calls, with decisions to allow, redact, block, rate limit or escalate for human approval. Each decision produces audit-ready evidence, mapped to NYDFS among other frameworks. For a reviewer, this adds a record of what the agent was allowed to do and did, which can be tested against the entitlement snapshot. Retention and data residency are configurable, and deployment is self-managed in the customer's cloud.

The boundaries matter. Runtime policy does not issue credentials, vault secrets, assign roles or establish agent identity. Those remain with identity, credential and vault controls, and with the privileged access management solution Class A companies must maintain. Enforcement at the tool-call level supports privileged access monitoring and the review. It is not workflow-level or transaction-level tracing, and it should not be described that way to an examiner.

Governance, tradeoffs and open decisions

Add agent access procedures to the annual review and approval cycle for written cybersecurity policies and procedures. Agent review records are also candidate supporting documentation for the annual compliance filing. Document how agent tool access feeds the risk assessment, since the access limits are defined as risk-based.

Expect tradeoffs. Narrow tool scopes reduce review burden and exposure but can slow agent development, so set the exception path before teams need it. Annual review alone leaves long windows where scope can drift, which is why event-driven review points and runtime policy decisions are worth the added effort. Where an agent acts through a third party's service, apply your third-party service provider review language to the contract and its access controls.

Finally, the interpretation that agent credentials are privileged accounts is yours to make and defend. Make it explicitly, record it, and confirm it with counsel against your exemptions and Class A status. This page is not legal advice.