Best Practices for Building Agents Recap
Arthur

What Security Controls Do Regulators Expect for Agentic AI in Financial Services?

July 31, 20267 min read

Regulators are not writing a separate rulebook for agentic AI yet. They expect financial firms to apply the frameworks they already have, model risk management, cybersecurity, operational resilience, third-party risk, and consumer protection, to AI agents, and to add controls because agents act on their own.

That distinction matters. A traditional model produces an answer and a human decides what to do with it. An agent plans, calls tools, accesses data, and takes actions with limited human intervention. So supervisors are asking a harder question. Not only "was the output accurate?" but "was the agent allowed to take this action, who authorized it, and can you prove what happened?"

The firm stays accountable for what an agent does. The burden is to show the agent acted within its authority, under oversight, with a full record. This post covers the control areas regulators consistently expect, the controls they emphasize specifically for agents, the frameworks shaping those expectations, and how to produce the evidence a reviewer will ask for.

Why agentic AI changes the regulatory picture

Autonomy is the reason agents get treated as higher-risk systems. An agent that can move money, change a customer record, approve a decision, or query a database is closer to a privileged digital employee than to a chatbot. That autonomy creates new exposure: unauthorized transactions, data leaving the environment, unfair outcomes, and weak accountability when something goes wrong.

Traditional model governance assumes a model outputs a result. Agents introduce a second set of questions that governance has to answer:

  • Was the agent authorized to take this action?
  • Who or what policy delegated that authority?
  • Could the agent exceed its intended scope?
  • Can every decision and tool call be reconstructed after the fact?
  • Can the agent be stopped immediately if it behaves unexpectedly?

Supervisors are converging on the same answer to those questions: adopt agents if you want, but only with strong governance, least-privilege access, continuous monitoring, and human accountability proportional to the agent's autonomy and customer impact.

The control areas regulators consistently expect

Across published guidance and supervisory commentary, the same control areas come up repeatedly. Treat this as the baseline map a reviewer will work from.

Governance and accountability. A named business owner, risk owner, and technical owner for each agent. Documented use cases, a risk classification, and senior-management or board visibility into material AI uses. Accountability that holds even when an autonomous agent does the work.

Agent identity and access management. A unique identity for every agent, no shared credentials, least-privilege permissions, short-lived credentials, and role-based or attribute-based access controls (RBAC/ABAC). Separate human identities from machine identities so every action traces back to a specific agent.

Human oversight. Human-in-the-loop approval for high-impact actions such as payments, lending decisions, trading, and account changes. Maker-checker workflows, defined autonomy boundaries, and thresholds that decide when an agent must ask a person.

Tool and action authorization. Restrict which APIs, databases, and systems an agent can call. Enforce transaction limits and approval workflows for sensitive actions, and prevent privilege escalation.

Auditability and traceability. Immutable, tamper-evident logs of prompts, data accessed, tool calls, decisions, approvals, and outcomes. The ability to reconstruct who did what, when, and why.

Monitoring and observability. Continuous behavioral monitoring, anomaly detection, and drift detection, not just infrastructure metrics. The goal is to catch bad behavior as it emerges rather than after a customer reports it.

Data protection. Data classification before an agent gets access, PII controls, encryption, data residency, data minimization, and data lineage showing how information flows through the agent.

Adversarial defense. Prompt injection detection, red-teaming, adversarial testing, and sandboxing of tools so malicious instructions embedded in documents or external content can't hijack the agent.

Model risk management. Validation before deployment, ongoing monitoring, and change management when models, prompts, tools, or data sources change. This aligns with long-standing SR 11-7-style expectations.

Third-party and vendor risk. Due diligence on foundation model providers, agent platforms, and plugins, with contractual security terms, incident notification, and audit rights.

Incident response and containment. A kill switch, circuit breaker, and rollback capability, plus AI-specific playbooks for containment, investigation, and evidence preservation.

The controls regulators emphasize specifically for agents

The list above extends existing risk management. A handful of controls matter more for agents than for static models, and supervisors are focusing on them.

Delegation chain. Prove which person, process, or policy authorized an agent to act. This is the "who allowed this?" question that traditional model governance never had to answer.

Tool governance. Control the APIs, databases, payment rails, and customer systems an agent can reach. The agent's blast radius is defined by what it can touch.

Runtime guardrails. Enforce rules while the agent operates, not only during pre-deployment testing. A control that runs only sometimes, or that a clever input can bypass, gives false confidence.

Human-in-the-loop for consequential decisions. Require approval for actions with customer, financial, legal, or compliance impact.

Immediate revocability and containment. Be able to disable an agent or revoke its permissions instantly, without disrupting other systems.

Frameworks and bodies shaping the expectations

No single agentic AI regulation governs financial services today. Instead, a set of frameworks and supervisors shape what "good" looks like.

The NIST AI Risk Management Framework (govern, map, measure, manage) is the most commonly referenced structure for organizing these controls across the agent lifecycle. Model risk management guidance in the SR 11-7 lineage informs validation and monitoring expectations. Operational resilience regimes such as DORA, cybersecurity rules such as NYDFS Part 500, and the EU AI Act all apply to agents even though none were written specifically for them.

On the supervisory side, bodies including the OCC, Federal Reserve, FDIC, FINRA, FSB, Treasury, MAS, APRA, ECB, and FCA have signaled increased scrutiny of AI use in financial firms, with agent-specific guidance still emerging. The consistent message is that existing obligations already apply, and firms should be ready to demonstrate control, accountability, and resilience proportional to the risk of the process the agent runs.

The regulator-ready baseline

Cutting through the frameworks, supervisory commentary converges on a short list of properties every agent should have. If an agent meets all six, it is in a defensible position for a review. Every agent should be:

  • Identifiable — a unique identity and a named owner
  • Permissioned — least privilege, scoped tool and data access
  • Observable — full telemetry of decisions and actions
  • Auditable — immutable logs and a reconstructable history
  • Constrained — guardrails, approval gates, and transaction limits
  • Revocable — a kill switch and immediate credential revocation

How to produce the evidence

Here is the gap most guidance leaves open. It tells you what regulators expect but not how you demonstrate it. Reviews rarely fail because a firm lacks intent. They fail because the firm cannot produce evidence: the inventory, the audit trail, the monitoring records, the proof that a control was actually running.

Arthur's Agent Security and Governance approach maps to the control areas above and turns each expectation into something you can show a reviewer.

Discovery produces the agent inventory and ownership regulators ask for, including shadow agents that no one registered. Arthur discovers agents across environments through telemetry, MCP monitoring, network analysis, and API-driven methods, so the inventory reflects what is actually running.

Observability produces the audit trail and traceability. End-to-end tracing captures prompts, tool calls, data accessed, and decisions, so you can reconstruct who did what, when, and why.

Continuous evaluations produce the ongoing monitoring and validation. Automated evals run against production traffic to catch hallucinations, policy violations, and drift as they emerge, rather than waiting for a complaint.

Guardrails produce the runtime controls. Pre- and post-LLM guardrails handle PII redaction, prompt injection defense, and action validation while the agent operates, and they emit telemetry so you can show how often each control fired.

Governance produces the accountability layer: named ownership, policy enforcement, and demonstrable controls across the agents a firm builds and the agents it buys. Arthur runs natively inside a customer's own cloud environment, so sensitive data does not have to leave it to be governed.

That is the bridge from "regulators expect these controls" to "here is the evidence they are in place."

Frequently asked questions

Are there specific regulations for agentic AI in financial services yet? Not as a separate rulebook. Regulators expect existing frameworks, model risk, cybersecurity, operational resilience, third-party risk, and consumer protection, to apply to agents, with additional controls wherever autonomy raises risk. Agent-specific guidance is emerging.

What is the single most important control regulators look for? There is no single control, but accountability ties the rest together: a named owner, a delegation chain proving who authorized each action, and an audit trail that reconstructs what the agent did. Autonomy does not remove accountability.

How is agentic AI governance different from traditional model risk management? Model risk management asks whether an output was accurate. Agentic governance adds authorization, delegation, tool access, runtime enforcement, and containment, because agents take actions rather than just producing answers.

What frameworks should we align to? The NIST AI Risk Management Framework is the common organizing structure. Model risk guidance in the SR 11-7 lineage, operational resilience regimes like DORA, cybersecurity rules like NYDFS Part 500, and the EU AI Act all apply depending on jurisdiction and use case.

How do we prove our controls to an examiner or auditor? With evidence, not intent. Maintain an agent inventory with owners, immutable audit logs of every action, records of continuous monitoring, and proof that runtime guardrails are active. Discovery, observability, continuous evals, and guardrails are how firms turn expectations into demonstrable controls.

Key takeaways

  • Regulators apply existing frameworks to agents and add controls for autonomy. They are not writing a separate agentic AI rulebook yet.
  • The consistent control areas are governance, identity and access, human oversight, tool and action authorization, auditability, monitoring, data protection, adversarial defense, model risk, third-party risk, and incident response.
  • Agent-specific emphasis falls on the delegation chain, tool governance, runtime guardrails, and immediate revocability.
  • The regulator-ready baseline: every agent should be identifiable, permissioned, observable, auditable, constrained, and revocable.
  • The hard part is producing evidence. Discovery, observability, continuous evals, and guardrails turn regulator expectations into controls you can demonstrate.

Get started

See how Arthur helps financial firms discover, secure, and govern their agents with the evidence a review demands. Book a demo or explore the Agent Development Toolkit.

SHARE