AI Agents Acting on Your Behalf: Is Your Firm Ready?

Somewhere in a financial services firm right now, an AI agent is drafting an email, pulling data from a portfolio management system, or queuing up a transaction for review — and no one has formally decided what that agent is allowed to do, in whose name, or how to stop it if something goes wrong. That gap is not a technology problem. It is a governance problem, and it is arriving faster than most operations leaders realize.

The Authorization Gap No One Talks About

The conversation around AI in investment management tends to concentrate on productivity gains: faster research synthesis, automated reporting, reduced operational overhead. Those benefits are real. But the governance conversation lags badly behind the deployment conversation.

Most firms that have adopted AI tools — whether embedded in their portfolio management software, their CRM, or their communications platforms — have not answered a foundational question: what is this agent actually authorized to do, and who authorized it?

This is not a hypothetical risk. A recent joint guidance document from NIST, CISA, and the NSA, covered in detail by security researchers examining the identity record problem, treats runaway or misbehaving AI agents as a category of security incident that firms should actively rehearse responding to. The central challenge they identified: when something goes wrong, investigators need to answer whose authority the agent was using — and that answer has to exist somewhere before the incident occurs, not after.

Most firms cannot answer that question today.

What ‘Acting on Your Behalf’ Actually Means

When an AI agent “acts on your behalf,” it is not just retrieving information. It is taking actions — sending communications, accessing systems, modifying records, initiating workflows — using credentials and permissions tied to a person, a service account, or the firm itself.

Think of it this way: if a human employee sends an email to a counterparty, there is a clear record of who sent it, under what authority, and when. When an AI agent sends that same email, those records are often incomplete, ambiguous, or nonexistent.

This matters in several concrete ways for financial services firms:

Regulatory examination exposure. SEC and FINRA examiners increasingly ask about the supervision of automated and AI-driven processes. If an agent executed a client communication or a trade-related workflow, examiners will want to see the supervisory chain — who approved the action, what rules governed it, and how exceptions were logged.
Investor due diligence. Limited partners and institutional allocators are beginning to include questions about AI governance in their operational due diligence questionnaires. A firm that cannot describe its AI authorization framework is increasingly at a disadvantage in that conversation.
Cyber insurance underwriting. Insurers are starting to ask whether AI-driven processes are covered under existing cyber policies, and whether firms have documented the controls around autonomous systems. Vague answers affect coverage terms.

Why the Identity Record Is the Whole Game

In cybersecurity, the concept of an “identity record” refers to the documented link between a set of credentials — a username, an API key, a service token — and the human or system entity those credentials belong to, along with the specific permissions that entity holds.

For AI agents, the identity record is not just a security artifact — it is the audit trail.

When a firm needs to demonstrate to a regulator, an auditor, or an investor that its AI systems operated within defined boundaries, the identity record is the evidence. It answers:

What actions did this agent take, and when?
What data did it access?
Whose authority did it operate under?
Was there a human in the approval loop, and if so, who?

Without that record, firms cannot conduct a meaningful post-incident review, cannot satisfy an examiner’s document request, and cannot credibly claim that their AI systems were supervised. For investment advisers subject to SEC recordkeeping rules, the absence of this documentation is not just an operational gap — it is potentially a compliance deficiency.

The identity record problem is harder for AI agents than for human employees because agents often share credentials, operate across multiple systems simultaneously, and can be spun up or modified without the same onboarding controls that govern human access. Requiring your IT or security team to treat each AI agent as a distinct identity — with its own documented permissions, its own access scope, and its own audit trail — is the starting point.

What Regulators and Auditors Will Ask

Firms should expect that AI agent governance will become a standard examination topic within the next regulatory cycle. The SEC’s Division of Examinations has already signaled interest in how firms supervise automated processes, and the logic extends directly to AI-driven workflows.

Prepare for questions like:

How does the firm identify and inventory AI agents operating in its environment?
What human approval is required before an agent can initiate a client-facing action?
How are agent permissions reviewed and updated when personnel or workflows change?
What is the firm’s incident response procedure when an AI agent behaves unexpectedly?
How are agent actions logged, and how long are those logs retained?

Compliance officers building out their AI incident response frameworks for investment advisers should treat these questions as the baseline, not the ceiling. The firms that will handle an examination well are the ones that can produce a clear, documented answer to each of them — not the ones that will reconstruct the answer after the examiner asks.

Controls to Require Before You Deploy

The goal here is not to slow down AI adoption. It is to ensure that the governance infrastructure keeps pace with the deployment decisions. Operations and compliance leaders can sponsor the following controls without needing to understand the underlying technology in detail:

Require an AI agent inventory. Before any agent is deployed in a production environment — one touching real client data, real communications, or real workflows — it should be registered in a formal inventory that captures what it does, what systems it accesses, and who owns it.
Establish a named human owner for every agent. Every AI agent operating within the firm should have a designated human accountable for its behavior. That person should be able to describe, in plain terms, what the agent is authorized to do.
Require documented permission boundaries. Ask your IT team to verify that each agent operates under a defined and limited set of permissions — access to only the data it needs, and no more. This principle, sometimes called least-privilege access, is standard practice for human user accounts and should apply equally to AI systems.
Build agent actions into your incident response rehearsals. Ask whether your firm’s incident response plan addresses scenarios where an AI agent is the source of a data exposure or unauthorized action. If it does not, add it before the next tabletop exercise.
Add AI governance to your vendor risk reviews. If AI capabilities are embedded in third-party platforms your firm uses — portfolio management tools, communication platforms, data providers — add autonomous AI controls for your investment firm’s vendor reviews. Ask what the vendor logs, how long they retain those logs, and what notification procedures exist if an agent misbehaves.
Tie AI authorization to your change management process. When the firm’s workflows change — a new fund launch, a personnel change, a system migration — AI agent permissions should be reviewed as part of that process, not left to drift.

Final Thought

The question facing financial services operations leaders is not whether AI agents will act on the firm’s behalf. They already are. The question is whether the firm has built the governance structure to demonstrate — to regulators, to investors, to insurers, and to itself — that those actions were authorized, supervised, and documented. AI identity management and compliance are not IT concerns that can be delegated entirely to a security team. They are business governance concerns that belong on the agenda of every COO and compliance officer deploying these tools. The firms that treat AI authorization as a priority now will be far better positioned when the first examiner asks — and the first examiner will ask.

Frequently Asked Questions

What does the SEC expect firms to document when AI agents execute client-facing workflows?

SEC examiners expect firms to produce a supervisory chain showing who approved the AI agent’s action, what rules governed it, and how exceptions were logged. The SEC’s Division of Examinations has already signaled interest in how firms supervise automated processes, and that scrutiny extends directly to AI-driven workflows. Investment advisers subject to SEC recordkeeping rules that cannot produce this documentation face not just an operational gap but a potential compliance deficiency.

How should a financial services firm inventory AI agents operating in its environment?

Every AI agent deployed in a production environment — one touching real client data, communications, or workflows — should be registered in a formal inventory before deployment, capturing what the agent does, which systems it accesses, and who owns it. Each agent should also have a designated human owner accountable for its behavior who can describe, in plain terms, what the agent is authorized to do. This inventory is the foundation regulators, auditors, and cyber insurers will reference when evaluating whether AI systems were properly supervised.

Why do AI agents create a harder identity management problem than human employees?

AI agents often share credentials, operate across multiple systems simultaneously, and can be spun up or modified without the onboarding controls that govern human access, making it difficult to tie specific actions to a specific authorization. Human employees have a clear record of who acted, under what authority, and when; AI agents frequently leave those records incomplete, ambiguous, or nonexistent. Treating each AI agent as a distinct identity — with its own documented permissions, access scope, and audit trail — is the minimum control standard required to close that gap.

What is an AI agent identity record and why does it matter for regulatory audits?

An AI agent identity record is the documented link between a set of credentials — a username, API key, or service token — and the specific permissions that agent holds, along with a log of the actions it took and when. For investment advisers, this record functions as the audit trail that answers what data the agent accessed, whose authority it operated under, and whether a human was in the approval loop. Without it, firms cannot conduct a meaningful post-incident review or satisfy an examiner’s document request.

How are limited partners and institutional allocators incorporating AI governance into operational due diligence?

Institutional allocators are beginning to include questions about AI authorization frameworks in their operational due diligence questionnaires, asking managers to describe how autonomous systems are governed and supervised. A firm that cannot articulate its AI governance structure is increasingly at a disadvantage in those conversations. Documenting agent inventories, permission boundaries, and human oversight procedures directly supports the answers allocators are now expecting.

Does a firm’s existing cyber insurance policy typically cover damage caused by an AI agent acting autonomously?

Cyber insurers are actively asking whether AI-driven processes fall within existing policy scope and whether firms have documented controls around autonomous systems — and vague answers affect coverage terms. Firms should not assume that coverage written before autonomous AI agents were in use extends automatically to incidents those agents cause. Reviewing policy language with the firm’s insurer and presenting documented AI controls — inventories, permission boundaries, incident response procedures — is the appropriate step to confirm coverage applicability.

What does least-privilege access mean when applied to AI agents in an investment firm’s environment?

Least-privilege access, when applied to AI agents, means each agent is provisioned with access to only the data and systems it specifically needs to perform its defined function — no broader permissions. This is standard practice for human user accounts under frameworks such as NIST CSF and should apply equally to AI systems. IT teams should be required to verify and document that each agent’s permission scope is defined and limited before the agent is deployed in a production environment.

When should AI agent permissions be reviewed after a fund launch or personnel change?

AI agent permissions should be reviewed as part of the firm’s standard change management process whenever a new fund launches, a personnel change occurs, or a system migration takes place — not left to drift between reviews. Permissions tied to a departing employee’s credentials or an obsolete workflow create both security exposure and regulatory risk. Tying AI authorization reviews to existing change management checkpoints is the most practical way to prevent permission scope from expanding beyond what was originally authorized.

Should an investment firm’s incident response plan explicitly address scenarios where an AI agent causes a data exposure?

Yes — incident response plans that do not address AI agents as a potential source of data exposure or unauthorized action have a material gap, given that NIST, CISA, and the NSA now treat runaway or misbehaving AI agents as a distinct category of security incident. Firms should add AI agent scenarios to tabletop exercises before an incident occurs, not after. The key pre-requisite is having identity records in place so that, when an agent is the incident, investigators can immediately determine whose authority it was using and what actions it took.