Prudence Tracewell describes herself as "the person whose signature means the firm thought about it." As Head of Supervisory Compliance at a mid-tier broker-dealer, she has spent fourteen years ensuring that when regulators come asking questions, the answers already exist in the record. Before that, she spent six years as an SEC examiner. She knows what those questions sound like from both sides of the table.
We spoke with Tracewell the week after she was asked, for the first time, to approve an agent workflow for production deployment. The system would close support tickets, update customer records, and send outbound communications, all "on behalf of" authorized users.
She had questions.
Tracewell is a fictional composite. No actual compliance officers were harmed in the making of this interview, though several would recognize the frustrations. Her concerns are drawn from real regulatory frameworks and the operational gaps they expose.
You were asked to sign off on an agent workflow. What was your first question?
Prudence: Same question I've asked about every system for fourteen years: if this goes wrong, what evidence survives?
The answer I got was a demo.
What was wrong with the demo?
Prudence: Nothing. That's the problem. The demo was beautiful. The agent logged in, navigated to the ticket, assessed the status, closed it, updated the record, sent the customer a confirmation. Thirty seconds. Everyone in the room was impressed.
And I'm sitting there thinking: who authorized the closure?
They said, "The user approved it." I said, "Show me the approval." They showed me a modal dialog that said "Approve?" with a green button. And I said, okay, but what did the user approve? The plan to close the ticket? The action of closing the ticket? Because those are different things, and they happened at different times, and between those two moments the page could have changed, the ticket state could have changed, the customer could have added a new message.
That seems like a fine distinction.
Prudence: It's the distinction that matters. NIST defines authentication as establishing that a claimant controls authenticators bound to an account.1 That proves who's at the keyboard when the session opens. It does not prove that every subsequent browser action was intended by that person rather than delegated to software. NIST even separates "authentication intent," did you mean to log in, from authorization of any specific downstream action.2
So when someone tells me "the user approved it," I need to know: approved what, approved when, and does the approval artifact actually bind to the action that was executed? A click on a green button two steps before the agent navigated to a changed page is not approval. It's a receipt for a different transaction.
Let's make this concrete. The agent closes a support ticket.
Prudence: In financial services, closing a ticket isn't housekeeping. There are compliance-critical steps embedded in that workflow. Identity verification before account changes. Required disclosures during dispute resolution. Mandatory escalation triggers for fraud claims. Did the agent verify all of those? In the right order? Can I prove it?
And here's what I keep circling back to: FINRA's 2026 Oversight Report specifically identifies agents acting "beyond the user's actual or intended scope and authority" as a risk.3 They're not being philosophical. They're telling firms: you need to track agent actions and decisions, you need human-in-the-loop oversight protocols, and you need to be able to explain what happened.
So I ask the engineering team: what identity does the downstream system see when this agent closes the ticket? The user? The agent? A service account? A browser session cookie?
Silence.
Because if the answer is "a browser session cookie," then we have no delegation record. We have a session that was authenticated at 9:00 AM being used by software at 2:47 PM to take an action the user may or may not have specifically intended. That's not delegation. That's session hijacking with better PR.
The agent also sends customer messages. That seems more straightforward.
Prudence: [laughs] It's actually the most legally acute scenario of the three.
SEC Rule 17a-4(b) requires us to preserve originals of all communications sent and any approvals thereof.4 When an agent sends a message to a customer, that message is a business communication under 17a-4. Which means the approval must also be preserved. But what does that approval record look like?
If it's a screenshot of a modal dialog that says "Send message?" — that tells a regulator someone clicked something. It does not tell them that a specific person approved this specific message to this specific customer about this specific matter. I've watched examiners pull apart weaker distinctions than that.
And the message has to be retained in a human-readable, reasonably usable format for regulators upon request. The two most recent years immediately accessible.4 So now I need the agent's outbound communication, the approval artifact, and the linkage between them, all preserved in tamper-evident storage.
Has anyone built that? Because the demo didn't show it.
What about the scenario where an agent updates a customer record?
Prudence: That's where I started drawing diagrams on a whiteboard and the engineering team got quiet.
When a human changes a record, the audit trail is clean: this person, authenticated with these credentials, at this time, changed this field from X to Y. Four elements. Done.
When an agent changes a record, I need: which human requested it, which software identity executed it, what credential was used, was that credential scoped to this specific action, what was the record state before and after, was the approval bound to the executed action or to an earlier plan, and can I reconstruct the sequence six months from now when an examiner asks.
That's seven elements. The current system captures maybe two. And the engineering team looked at me like I was asking them to build a time machine, when really I was asking them to build a filing cabinet.
You sound like you're going to reject the workflow.
Prudence: I sound like I'm going to approve it with conditions that will make the engineering team wish I'd rejected it.
What would "good" look like?
Prudence: Approval that binds to the actual action at the moment of execution, not to a plan formulated three steps earlier. Delegation credentials scoped to the specific action surface, with expiry, that I can revoke without disabling the human's account. An audit record that separately attributes request, approval, agent action, resource, and final state.
And this part matters most: the ability for the human approver to see the exact action about to be taken, understand its consequence, and stop it.5
The EU AI Act calls this "effective human oversight."5 I call it the minimum.
If the human can't inspect what they're approving, approval is theater. And approval theater gets worse at scale, because too many low-quality approvals train people to stop reading. You end up with autonomy by exhaustion — formally human-reviewed, functionally unsupervised.
I've seen this pattern before, long before agents. It's how every rubber-stamp process starts. Someone builds in a review step, calls it oversight, and then makes the review so frequent and so low-friction that the reviewer's eyes glaze over by 10 AM. Agents just accelerate the timeline.
One last question. Are agents fundamentally different from other automated systems you've approved?
Prudence: The obligations haven't changed. Books and records, supervisory review, identity attribution. Those requirements were written for paper ledgers and they survived the transition to electronic trading. They'll survive this.
What changed is the action surface. A traditional automation does one thing. An agent turns "close this ticket" into a dozen actions across multiple systems, any one of which might trigger a regulatory obligation. The compliance math is the same. The exponents are different.
I spent six years as an examiner. I know what the first question is going to be when they walk in. It's always the same question.
Show me the record.
And right now, for agent workflows, most firms don't have one worth showing.
Footnotes
-
NIST SP 800-63B-4, Digital Identity Guidelines — Authentication and Lifecycle Management. https://pages.nist.gov/800-63-4/sp800-63b.html ↩
-
NIST SP 800-63 FAQ, "Authentication Intent" definition. https://pages.nist.gov/800-63-FAQ/ ↩
-
FINRA 2026 Annual Regulatory Oversight Report, Generative AI section. https://www.finra.org/rules-guidance/guidance/reports/2026-finra-annual-regulatory-oversight-report/gen-ai ↩
-
SEC Rule 17a-4, Records Preservation requirements for broker-dealers. See also Smarsh regulatory summary: https://www.smarsh.com/regulations/sec-rule-17a-4-records-preservation/ ↩ ↩2
-
EU AI Act, Article 14 (Human Oversight) and Article 12 (Record-Keeping). See also Tech Policy Press analysis: https://www.techpolicy.press/understanding-right-to-explanation-and-automated-decisionmaking-in-europes-gdpr-and-ai-act/ ↩ ↩2