| Anand Salodkar is the Co-Founder of CompFly AI, where he leads product strategy and go-to-market execution. He brings 15 years of deep expertise spanning compliance, audit, M&A, and cybersecurity, having spent his career in the highly regulated, global financial services sector with leadership roles at Ernst & Young, Franklin Templeton Investments, and Dolby Laboratories. Anand has been featured in The AI Journal and TechBullion, and has published research on AI governance on SSRN and FinExtra. He is a member of The Conference Board’s Chief Audit Executives Council and the OpenAI Forum. He holds a CISA certification, a Master’s in Engineering from Lehigh University, and an MBA in Finance from The Wharton School at the University of Pennsylvania. |
Interview
Q1. Anand, thank you for joining us. Can you start by telling readers about your background and what you do today?
Thank you for having me. My background sits at the intersection of audit, compliance, cybersecurity, and enterprise risk. I spent much of my career in highly regulated financial services and technology environments, including roles at Ernst & Young, Franklin Templeton Investments, and Dolby Laboratories.
Today, I’m the Co-Founder of CompFly AI, where I lead product strategy and go-to-market execution. Our work is focused on a very specific problem: as AI agents start acting inside enterprise workflows, companies need a way to understand what those agents can access, what they can do, when they should be allowed to act, and how to produce evidence that the controls actually worked.
That problem is becoming especially urgent in areas like SOX, internal audit, cybersecurity, compliance, and enterprise AI governance.
Q2. What made you focus on auditing AI agents specifically?
Auditing rests on a basic promise: a company should be able to explain what happened, who did it, who approved it, what changed, and show evidence that the control worked.
That promise becomes much harder when the actor is no longer a person using a system, but an AI agent moving across systems, calling tools, retrieving context, using memory, and making decisions inside a workflow.
Traditional audit evidence was built for stable users, defined roles, known systems, and artifacts collected after the fact. AI agents do not fit neatly into that model. They interpret goals, choose tools, delegate work, and often act through service accounts or API tokens that were never designed to represent independent decision-makers.
So the question becomes: can the audit evidence still explain the decision path? In many cases today, the answer is no.
Q3. Why is traditional audit evidence not enough for AI agents?
Screenshots, tickets, approvals, exports, and logs still matter. They are not going away. But they usually capture a state after something happened.
An AI agent creates risk in the movement between states. What instruction did it receive? What context did it retrieve? Did it use stale memory? Which tool did it call? Did another agent influence the decision? Was the action appropriate for that purpose, with that data, at that point in the workflow?
A screenshot can show that an approval existed. It cannot show whether the agent’s recommendation was based on current, complete, and authorized information. A log can show that an API call happened. It cannot show whether the agent should have been allowed to make that call.
That is the core shift. Traditional evidence captures the result. Agentic evidence has to follow the decision path.
Q4. Where do access reviews start to break down?
Access reviews are one of the first places this becomes visible.
A traditional access review asks whether a user, group, role, or service account has appropriate access. That works reasonably well when access maps to a human job responsibility. It is much weaker when an agent acts through an API key, delegated token, service account, workflow integration, or orchestration layer.
An auditor can confirm that a service account was approved and still miss the real control question. The question is not only, ‘Does this account have access?’ The better question is, ‘Should this agent be using this authority right now, for this purpose, with this data, at this point in the process?’
An agent may be allowed to read vendor data for analysis. That does not mean it should update vendor records, draft a payment recommendation, or combine invoice history with bank-account changes. Access has to become contextual.
Q5. You’ve said an API key is not an accountable actor. What do you mean by that?
An API key proves that something authenticated. It does not prove who acted, what goal the agent was pursuing, what context shaped the decision, or whether the authority was still valid when the action occurred.
That distinction matters. In many enterprise environments, multiple workflows, tools, or agents may operate through shared credentials or service accounts. From an audit perspective, that creates a blind spot. The credential may be valid, but accountability is still unclear.
Each agent needs its own owner, purpose, approved scope, permitted tools, and authority boundary. In higher-risk workflows, that authority should also expire or be revalidated. Otherwise, accountability disappears behind a shared credential.
Q6. How does segregation of duties change when agents are involved?
Segregation of duties was designed around clean separation of human responsibility. One person creates the vendor, another approves the payment. One person writes the code, another approves the release.
But agentic workflows often move through chains. One agent gathers data, another summarizes exceptions, another drafts a recommendation, and another moves the workflow forward. On a process map, those steps may look separate. In reality, the agents may share memory, context, tool access, or delegated authority.
That means the risk may not sit in any single step. It may sit in the chain.
You can have three or four individually permitted actions that combine into an outcome no one intended to approve. The control has to evaluate the workflow, not just each link in isolation.
Q7. Can you give an example of that?
Take a vendor exception. A vendor received a temporary approval last quarter because its banking documentation was incomplete but being remediated.
Months later, an agent retrieves that record, treats the exception as still valid, summarizes the vendor as previously approved, and sends the case forward for payment review. Each individual action may appear reasonable. The agent retrieved a record. It summarized the file. It prepared a recommendation. It passed the case forward.
But the chain changed the meaning of the evidence. A temporary exception quietly became current authority.
That is the kind of issue traditional evidence may not catch. The ticket may look clean. The access may look approved. The log may show normal activity. But the real risk was upstream in how the agent interpreted context.
Q8. How does this affect change management and code approvals?
The same issue applies to change management.
A ticket can show that a change was approved, tested, and deployed through the right process. But if an agent wrote part of the code, recommended the configuration, or generated the pull request from stale documentation, the approval may only be reviewing the output, not the reasoning behind it.
That matters because reviewers need enough context to approve intelligently. For agent-generated changes, the question is not only whether the change was approved. It is whether the reviewer could see the agent’s instruction, sources, assumptions, testing, and decision path.
Otherwise, the control can look clean while the real risk sits upstream.
Q9. What kind of evidence should auditors expect for AI agents?
Auditors should expect evidence that is replayable and tied to the decision path.
That includes the original instruction, retrieved context, memory source, tool calls, control checks, handoffs, human review, and final action. For higher-risk activity, auditors should also be able to see what happened before the action executed.
Did the system approve it? Did it challenge it? Did it block it? Did it escalate it? Was the decision based on purpose, authority, data sensitivity, and workflow stage?
The audit trail has to become behavioral. It should explain not just what happened, but why the agent was allowed to do it.
Q10. You argue that evidence has to move closer to the moment of risk. What does that mean?
In traditional audit programs, evidence is often gathered after the fact. The control operated, then someone collects screenshots, tickets, approvals, logs, or exports.
For AI agents, that is too late in many high-risk scenarios.
If an agent is updating vendor bank details, approving a payment, deploying code, or reaching into restricted data, the system should evaluate the action before it runs. The key question is not only whether the action was logged. It is whether the action was challenged, approved, blocked, or escalated at the right moment.
That is the move from static evidence to runtime assurance.
Q11. What role do evals play in the audit evidence package?
Evals become part of the evidence package, especially for higher-risk agent workflows.
An eval should not be a generic AI test. It should show how the agent performed against expected behavior, unsafe tool use, prompt injection, stale data, data leakage, model drift, delegation failures, and segregation-of-duties conflicts.
For higher-risk workflows, evals cannot be one-time tests. They need to be rerun when prompts, tools, models, connected systems, permissions, or workflow logic change.
Otherwise, the organization is relying on evidence from a version of the agent that may no longer exist in practice.
Q12. Does this replace human review?
No. It changes what human review needs to look at.
Human review is still important, especially for irreversible or high-impact actions. But ‘human in the loop’ is not meaningful unless the human has the right context.
If a reviewer only sees a final recommendation, they may not know whether the agent used stale data, skipped a relevant source, relied on unauthorized context, or combined permitted steps into a prohibited outcome.
Good oversight needs to be measurable. What was escalated? What was overridden? What changed over time? What errors still passed through? Without that evidence, human review becomes a comforting phrase rather than a control.
Q13. What should audit and risk teams ask when evaluating agentic workflows?
They should start with a few practical questions.
Who owns the agent? What is its approved purpose? What systems, tools, data, and workflows can it touch? Does its authority expire? Can it delegate work to another agent? Can it use memory? Can it act through a service account? What happens before it performs a high-risk action?
Then they should ask about evidence. Can we replay the decision path? Can we see the instruction, context, memory, tool call, control check, handoff, human review, and final action? Can we prove that the system challenged or blocked the action before execution when needed?
If the answer is only screenshots and logs, the evidence model is probably not ready.
Q14. What is the biggest misconception companies have about auditing AI agents?
The biggest misconception is that this can be solved with another AI checklist.
Checklists may help with readiness, but they do not produce operational evidence. Auditors will need to see how the agent was designed, how it behaved, and what controls operated at the moment it acted.
Most companies will not be short on artifacts. They will have screenshots, approvals, tickets, exports, and logs. The problem is that those artifacts may not prove the agent was allowed to act when it did.
The missing evidence is the decision path.
Q15. What do you think auditors should expect over the next few years?
I think audit programs will move from reviewing static artifacts to reviewing runtime evidence.
Agent identity will become more important. Behavioral access controls will become more important. Evals will become part of audit evidence. Runtime guardrails will carry more weight. And for high-risk workflows, companies will need to prove not only that something was logged, but that the right decision was made before execution.
The broader shift is simple: audit evidence has to become more dynamic because the systems being audited are becoming more dynamic.
Q16. What advice would you give to audit, compliance, and security leaders getting started?
Start by identifying where agents can affect records, money, access, code, customer outcomes, or regulated workflows. Those are the places where static evidence will fail first.
Then map the agent’s identity, owner, purpose, tools, data, memory, delegation paths, and authority boundary. After that, focus on runtime evidence. Can you replay what happened? Can you explain why the action was allowed? Can you prove what the system did before the action ran?
The goal is not to slow AI adoption. The goal is to make adoption defensible. AI agents will move faster than traditional audit evidence was designed to follow. So the evidence has to move with them.
About Anand Salodkar
Anand Salodkar is the Co-Founder of CompFly AI, where he leads product strategy and go-to-market execution. He brings 15 years of deep expertise spanning compliance, audit, M&A, and cybersecurity, having spent his career in the highly regulated, global financial services sector with leadership roles at Ernst & Young, Franklin Templeton Investments, and Dolby Laboratories. Anand has been featured in The AI Journal and TechBullion, and has published research on AI governance on SSRN and FinExtra. He is a member of The Conference Board’s Chief Audit Executives Council and the OpenAI Forum. He holds a CISA certification, a Master’s in Engineering from Lehigh University, and an MBA in Finance from The Wharton School at the University of Pennsylvania.
