Agent-to-Agent Delegation: Anand Salodkar on the Control Problem Hidden Inside Autonomous Workflows

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.

Q1. Anand, many companies are thinking about what AI agents should be allowed to do. You argue the harder question is different. What is it?

Most teams start with the permission question: what can this agent access, what tools can it call, and what actions can it perform?

That is important, but it is not the hardest part.

The harder question is: when should that authority disappear?

Agent workflows do not behave like traditional software sessions. They move across steps, tools, systems, and sometimes other agents. Authority that was valid at one point in the workflow may become unnecessary, or even dangerous, a few seconds later.

So the real control problem is not only granting the right authority. It is removing authority at the exact moment it is no longer justified.

Q2. Why does agent-to-agent delegation create a new control problem?

Because agent workflows are chains.

One agent may search. Another may negotiate. Another may pay. Another may configure an account. Another may send a confirmation email. Each step may be legitimate on its own.

The problem starts when authority granted for one step quietly survives into the next. It may remain in orchestration state, a cached tool binding, a memory entry, or a delegation token that has not expired yet.

Now the downstream agent is holding power that was only justified upstream. Technically, no rule may have been broken. But the workflow has accumulated authority it no longer needs.

That is where risk hides.

Q3. Can you give a simple example?

Think about a checkout flow with three agents.

The first agent finds the best deal. It searches inventory, compares sellers, and applies discounts. It does not need payment authority.

The second agent handles payment. For a narrow window, it may legitimately need authority to charge a specific card, for a specific merchant, item, and amount.

The third agent handles what comes after payment: seat selection, delivery preferences, loyalty points, account configuration, or confirmation emails. It may need order metadata, but it does not need payment authority.

The transaction may still be open, but the justification for payment access is over.

That distinction matters. The workflow continues. The authority should not.

Q4. Why is “least privilege” not enough for agentic workflows?

Least privilege is still the right principle, but the way it is implemented has to change.

In traditional systems, least privilege is often defined before execution. You assign the minimum access a user or service account needs, and then that permission remains relatively stable.

Agents are different. The minimum necessary authority changes as the work progresses.

Once the deal is selected, broad search access should narrow. Once payment clears, payment authority should disappear. Once a configuration is complete, write access may no longer be needed.

Least privilege for agents cannot be static. It has to be continuously recalculated.

Q5. What goes wrong if downstream agents inherit too much authority?

You get authority drift.

A downstream agent may begin with a narrow task, but because it inherits context or authority from an upstream agent, it ends up carrying permissions it does not need.

That is dangerous because downstream steps often look harmless. Selecting a seat, sending an email, updating preferences, or configuring an account may not seem high risk. But if the agent still has payment authority, customer data access, admin scope, or write access from a prior step, the blast radius changes.

The agent is no longer just completing the next step. It is completing the next step while carrying leftover power from the previous one.

That is not least privilege. That is privilege accumulation.

Q6. You compare bad delegation to passing a baton. What is wrong with that model?

A baton model says: the next agent receives what the previous agent had.

That is simple, but it is wrong for high-consequence workflows.

Agent delegation should look less like passing a baton and more like issuing a new, smaller set of keys at every step.

Each handoff should ask: What has already been completed? What authority has already been used? What should now be revoked? What does the next agent need to finish only the remaining task?

Without that reset, every handoff becomes a place where unnecessary authority can leak forward.

Q7. Don’t short-lived tokens solve this?

They help, but they are not enough.

A token that expires in thirty minutes may still be too generous if the workflow state changed after thirty seconds.

The issue is not only time. It is state.

If payment has already cleared, the payment token should not remain valid simply because the clock has not run out. If checkout failed, you may need a new payment-scoped token, but only after checking what actually happened.

Expiration on a clock is useful. Expiration on workflow state is more precise.

Q8. What does state-aware authority mean in practice?

It means authority should be recomputed based on where the workflow is right now.

Has the search step ended? Has the vendor been selected? Has payment cleared? Has the task timed out? Has the agent handed work to another agent? Has the workflow entered a different risk stage?

Those state changes should affect what the next agent can do.

A downstream agent should not automatically inherit what the upstream agent had. It should receive authority based on the remaining job, not the original intent of the user or the maximum authority used earlier in the workflow.

That is state-aware delegation.

Q9. How does this change the way companies should think about agent permissions?

Companies need to stop treating agent permissions as something assigned once at the beginning of a workflow.

For multi-agent systems, every handoff is a control point.

When one agent passes work to another, the system should decide what authority moves forward, what gets stripped away, what must be reapproved, and what needs to be logged.

That makes delegation its own control surface. It is not just an orchestration detail. It is one of the most important places to govern agent autonomy.

Q10. What kinds of authority should be removed as workflows progress?

Anything that is no longer justified by the current state of the work.

That could include payment authority, write access, admin privileges, access to sensitive records, customer data, source code, production systems, memory, or external communication tools.

For example, an agent that needed payment authority for checkout should not keep it during post-purchase configuration. An agent that needed access to a customer record for verification should not keep broad customer-data access once verification is complete.

The rule should be simple: completed steps should shed authority.

Q11. How does this apply beyond consumer checkout flows?

The same pattern exists across enterprise workflows.

In finance, one agent may analyze invoices, another may recommend payment, and another may initiate execution. In IT, one agent may investigate an incident, another may suggest remediation, and another may deploy a change. In procurement, one agent may compare vendors, another may negotiate terms, and another may update the system of record.

Each step may require different authority. The danger is allowing authority from one step to bleed into the next.

That is especially risky when agents touch money, records, access, infrastructure, customer communications, or regulated workflows.

Q12. What should enterprises log during agent-to-agent delegation?

They need to capture more than the fact that a handoff occurred.

They should log which agent delegated, which agent received the task, what authority was carried forward, what authority was revoked, what state triggered the change, what data or tools were included, and what the next agent was allowed to do.

The audit question is not just, “Did agent B act after agent A?”

The better question is, “Why did agent B receive this authority, and why was everything else removed?”

That is what makes delegation auditable.

Q13. What is the risk of treating delegation as only an orchestration problem?

Orchestration tools are designed to move work forward. Controls are designed to decide whether work should move forward under the current authority.

Those are not the same problem.

If delegation is treated only as orchestration, the system may optimize for task completion while ignoring whether the downstream agent should still carry the upstream authority.

That can create very clean-looking workflows with very messy control boundaries.

The workflow runs. The logs exist. The steps complete. But authority has quietly accumulated in the background.

Q14. How should companies design safer agent handoffs?

Start with a simple assumption: no authority should survive a handoff by default.

At every handoff, the system should recompute the minimum authority required for the next step. It should actively revoke what is no longer needed, issue new scoped authority where appropriate, and record the decision.

The handoff should be scoped, state-aware, and auditable.

That means downstream agents inherit only what the remaining task requires, not everything the prior agent had available.

Q15. What is the broader point for AI governance?

The governance question is moving from “What is this agent allowed to do?” to “How does this agent’s authority change as work moves forward?”

That is a major shift.

Autonomous workflows are not static. They branch, delegate, recover from failure, retry tasks, use memory, and move across systems. The control model has to be just as dynamic.

Governing agent autonomy will depend less on broad permissions at the start and more on how cleanly authority is reduced, revoked, and reissued during execution.

Q16. What advice would you give to teams building or adopting multi-agent systems?

Do not start with the assumption that agent handoffs are safe because each individual step looks reasonable.

Map the chain. Identify where authority is granted, where it should expire, where it can be inherited, and where it must be recomputed.

Then ask the practical questions: What authority is this agent still carrying? Has the state changed? What should be removed? What does the next agent actually need? Can we prove the handoff was scoped correctly?

The companies that get this right will not just grant agents authority. They will teach their systems how to take authority away.

That is what makes autonomy governable.

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.