{{item.title}}
{{item.text}}
{{item.text}}
A global technology company deploys autonomous agents across its enterprise stack to accelerate its contact-to-cash cycle and streamline back-office operations. A Salesforce agent qualifies inbound leads, creates opportunities, and generates quotes. When a deal closes, it triggers a handoff to an Oracle agent that posts the revenue recognition entries. A Workday agent automatically onboards new sales hires, updates commission plans, recommends compensation adjustments, and surfaces workforce actions based on sales performance and organizational data. An SAP agent procures third-party services needed for fulfillment.
Each agent operates within its own platform. Permissions are reviewed and approved by the respective platform security team. No single agent has conflicting access. Every access review passes.
For nine months, no issue is flagged—until an internal audit discovers a pattern no control was designed to catch.
As deals closed in Salesforce, the agent chain set other actions in motion. Revenue recognition was posted in Oracle for contracts requiring third-party fulfillment before the related costs were fully visible. Third-party services were procured through SAP, adding fulfillment costs to the transaction. Commission tiers were updated and bonus eligibility accelerated in Workday based on the same transactions.
Each action was authorized when viewed in isolation. But viewed as a chain, the orchestration had created a cycle—deal closure, revenue posting, procurement commitment, and compensation adjustment—without human review of the end-to-end economics of the transactions. In 87 cases, commission payments exceeded deal margin after third-party costs. The company paid more in commissions than it earned.
Segregation of duty (SoD) controls never flagged the conflict because it didn’t exist within any single system. It existed in the space between Salesforce, Oracle, SAP, and Workday—in the orchestration layer that coordinated them.
No alert fired. No exception report caught it. The pattern surfaced only when a manual margin analysis happened to look across the right data at the right time.
This isn’t a breach or a hack. It’s the normal, intended operation of an agentic architecture that no one thought to govern. The controls didn’t fail. They weren’t built for this.
Enterprise controls were built on three assumptions: Humans performed actions, systems enforced rules, and auditors reviewed logs. Agentic AI breaks all three at once. Platform controls stop at the platform boundary. The transaction doesn’t.
Closing this gap requires controls to follow the transaction, not the platform. As agentic AI scales, trust should be engineered across the full chain of agent activity, with governance that extends to handoffs, interactions, and decisions between systems. Trust AI helps frame this shift, particularly as AI regulatory frameworks worldwide raise expectations for secure and defensible AI.
What does this shift look like in practice?
The five practices below address what no platform can see on its own: the full landscape of agents, the handoffs between them, the full transaction chain, and the orchestration layer that coordinates them.
These five practices define an approach to governing beyond individual platforms. The next step is to test where governance may need to adapt.
The questions below can help your organization surface gaps between platform-level controls and cross-platform execution.
If your answer to any of these is “no” or “not sure,” the gap exists today. The question is whether your organization closes it proactively or waits for an auditor to find it.
The space between platforms is where agent-driven transactions cross boundaries, beyond the scope of any single system’s controls or accountability. The risk is in that space — and so is the opportunity. Organizations that govern it now can define what responsible, audit-ready agentic AI looks like at enterprise scale, while protecting the value these systems are designed to create.
{{item.text}}
{{item.text}}