How to Monitor AI Agent Activity for Unauthorized Access Under NYDFS Part 500

What Part 500 says, and what it leaves to interpretation

Section 500.14(a)(1) requires each covered entity to implement risk-based policies, procedures and controls designed to monitor the activity of authorized users and detect unauthorized access or use of, or tampering with, nonpublic information by those users. Part 500 defines an authorized user as any employee, contractor, agent or other person that participates in the business operations of a covered entity and is authorized to access and use its information systems and data. An AI agent that authenticates to systems and reaches nonpublic information on behalf of a user or service fits that description comfortably.

The regulation text does not expressly mention AI agents, tool calls or MCP servers. The mappings in this guide are interpretation, and the entity's risk assessment should record why the chosen scope and depth of agent monitoring is reasonable, because the monitoring requirement is risk-based.

DFS guidance on AI-related cybersecurity risk states that it adds no new requirements and applies the existing Part 500 framework. It names robust access controls as a defense against unauthorized access to information systems and nonpublic information, and identifies multi-factor authentication as one of the most effective. It also states that as of November 2025, Part 500 requires MFA for all authorized users accessing information systems or nonpublic information. Agent controls should therefore be justified through existing provisions, not presented as AI-specific mandates. Confirm first which sections apply to your entity, since exemptions under section 500.19 and Class A company status change the list. DFS publishes the current consolidated text as of November 2026.

Mapping Part 500 provisions to agent activity

The table pairs each provision or DFS expectation with a practical reading for agents. The right-hand column is interpretation.

• 500.14(a)(1) monitoring: Monitor each agent as an authorized user. Detect calls that reach nonpublic information outside the agent's granted scope.
• Class A privileged access monitoring: Where applicable, agents holding elevated tool or MCP server permissions belong in the privileged access monitoring population.
• 500.14(b) logging and alerting (Class A): Confirm agent-side events reach the centralized logging and security event alerting used for Part 500 purposes.
• MFA for authorized users: Decide how agent identities authenticate, and avoid letting an agent simply reuse a human user's authenticated session.
• Third-party service provider oversight: Treat third-party models, tools and MCP servers as providers subject to due diligence, contract terms and ongoing monitoring. DFS suggests considering clauses on acceptable AI use and on training with entity data.
• Senior governance: Senior officers and governing bodies must oversee cybersecurity and third-party risk. Agent access boundaries are a reasonable reporting topic.

After-the-fact detection versus runtime enforcement

The following is analysis, not regulatory text. SIEM-based review and post-hoc log analysis are detective controls. They can show that a call happened, but the link between that call and the policy that should have governed it must usually be reconstructed from separate sources. NIST AI 800-4 observes that monitoring deployed AI is often use-case-specific, that human-in-the-loop live monitoring may not keep pace at scale, and that aggregating logs is difficult where components are logically separated. Agents, tools and MCP servers are often distributed in just that way. DFS guidance on heightened threat environments similarly suggests confirming that log and alerting data is captured and that anomalous activity is promptly actioned.

Enforcing policy in the execution path changes the evidence. The policy decision is made before the call completes, and the record is produced by the decision itself. The entity can show not only that an out-of-scope attempt occurred, but that it was blocked, redacted, rate limited or escalated for human approval, and under which policy version.

There are tradeoffs. In-path enforcement adds a dependency to the call path and needs policy authoring and maintenance. Overly strict rules can block legitimate work, and escalation queues need named owners and response expectations. Detective monitoring remains necessary for Class A logging and alerting, so the two approaches complement each other.

Evidence artifacts, retention and mapping

An examiner is likely to want a coherent chain from boundary to outcome. The artifacts to prepare are the agent inventory with granted scope, the policy versions in force, per-call decision records for allow, redact, block and rate-limit outcomes, and escalation records showing who approved or denied a request and when. Each should be mapped to the Part 500 provision it supports, such as 500.14(a)(1) for monitoring, and kept in a form that can be exported.

Retention periods for agent evidence should be set by the entity's own risk assessment and the full Part 500 text, then applied consistently to decision and escalation records. Records should be tamper-resistant and retained under the same discipline as other Part 500 evidence. Extend monitoring of third-party code, applications and permissions to agent tooling, and add acceptable-use and data-training clauses to provider contracts where relevant.

Evaluating runtime enforcement, including Trussed

When evaluating any control that claims to produce agent evidence, test it against concrete questions. Trussed is one option. It enforces policy in the execution path across models, agents, tools and MCP servers, with outcomes of allow, redact, block, rate limit and escalate for human approval, scoped to individual interactions and tool calls. Enforcement generates audit-ready evidence mapped to NYDFS, among other frameworks. It can be self-managed in the customer cloud, with configurable retention and data residency.

Trussed has run 18+ months in continuous production in a regulated enterprise, with 99.95% uptime on live production traffic and 30+ GB of audit evidence generated per day. Its customers are in insurance, pharma, healthcare and education, and it is deepest in insurance. Its value for a CISO in financial services is in examiner scrutiny, model risk management and evidence, and the questions below apply to any approach.

• Can each tool call be attributed to an agent identity, the on-behalf-of user or service, and the policy decision that governed it?
• Does the control act before the call completes, or only record activity for later review?
• What records exist for allow, redact, block, rate-limit and escalation outcomes, and can they be exported and mapped to Part 500 provisions?
• How are inherited user credentials and MCP server resource access constrained and recorded for each agent?
• What retention and tamper-resistance settings apply, and do they align with the entity's Part 500 program?