They should govern the agent once, then carry that identity, purpose, and policy state across every downstream platform the agent touches. That requires consistent request-level enforcement, cross-platform auditability, and clear ownership for policy changes. If each platform redefines trust independently, the enterprise has no durable control model.
One governing model for one agent across every platform
The operating rule is simple: treat the agent as a single governed actor, even when it moves between Workday, Salesforce, and data platforms. The enterprise should not allow each system to create a separate trust story for the same action stream. If the agent changes systems but not intent, ownership, or approval basis, governance has to follow the request, not restart at each hop.
That means the enterprise needs a stable identity model for the agent, plus a policy envelope that can travel with the request. The practical test is whether a downstream system can see who the agent is, what it is allowed to do, and under what conditions the action was approved. Without that continuity, audit trails become fragmented and access decisions become inconsistent.
For connected SaaS flows, the strongest pattern is to govern the upstream agent and propagate only the minimum authority needed into each downstream platform. That is easier to defend than trying to reconstruct intent after the fact from logs that were never designed to agree. For a Salesforce-heavy estate, the Salesforce Security Guide is a useful parent reference for connected apps, token governance, and access review discipline.
Where governance breaks in cross-platform agent flows
The main failure mode is trust redefinition. If Workday asserts one identity state, Salesforce accepts another, and the data platform applies a third, the organisation no longer has one control model. That creates blind spots in authorization, makes incident reconstruction harder, and increases the chance that a previously approved action continues after the original business context has changed.
Cross-platform agents also tend to accumulate standing access over time. A workflow may start narrow, then gain broader token scope, longer session lifetime, or extra connector permissions as teams try to reduce friction. That is how an agent that was safe at launch becomes overpowered in production. Strong examples of this failure pattern include token reuse and third-party access chains, such as the Gainsight Salesforce breach 2025 and the Salesloft OAuth token breach.
Another common weakness is treating each platform owner as if they can define policy independently. That may work for local administration, but it fails for shared agentic workflows because one system’s approval does not explain the full blast radius. The more systems the agent touches, the more important it becomes to keep a common policy decision record, a common ownership model, and a common revocation path.
How to keep the policy state portable
Portable governance depends on three practical controls: request-level enforcement, centralized auditability, and clear change ownership. Request-level enforcement means every meaningful action is evaluated in context, not just at login. Auditability means the enterprise can reconstruct the path, decision, and entitlement state across systems. Ownership means there is one accountable team for policy changes, exceptions, and revocation decisions.
That approach is especially important when the agent interacts with sensitive records or performs write actions across business systems. The business can tolerate automation only when the action is bounded, attributable, and reversible. Where the workflow depends on third-party connectors or delegated OAuth grants, the enterprise should treat the connector as part of the control surface, not as a passive plumbing layer. The AI Agent Authorisation Guide is relevant here because it frames least privilege, per-action decisions, and delegated authority as the core design pattern.
For multi-agent or multi-hop orchestration, the governance problem is bigger than simple access control. One agent may hand off to another, or a platform workflow may trigger downstream actions that inherit trust implicitly. In those cases, the organisation should define how delegation is represented, how approval is chained, and where the handoff is logged. The Multi-Agent and A2A Security Guide is a useful lens for authentication, delegation chain control, and containment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent governance here centers on portable identity and authority across systems. |
| Recommendation — Enforce per-action authorization and bounded delegation for agent cross-system actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Cross-platform agents can accumulate excessive permissions across SaaS and data platforms. |
| Recommendation — Review and reduce agent permissions before they span multiple platforms. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agents and integrations need consistent authentication across platforms they invoke. |
| AC-6 — Least Privilege | The question asks how to limit an agent's authority as it crosses business systems. | |
| AU-2 — Event Logging | Cross-platform governance requires reconstructable audit trails for agent actions. | |
| Recommendation — Authenticate service and workload actors consistently at every platform boundary. Limit each agent to the minimum permissions required for each approved action. Log agent requests, policy decisions, and downstream actions in a correlated trail. | ||
Practitioner Guidance
What to prioritise: Decide which platform is the system of accountability for the agent’s identity and policy state, then make every downstream system consume that decision instead of redefining it locally. If you cannot name that owner, you do not yet have durable governance.
What to verify: Confirm that a privileged or sensitive action can be traced from the originating request through every platform hop, including who approved it, which policy applied, and what authority was actually used. If any hop cannot produce that evidence, the control model is incomplete.
Decision rule: If a downstream platform changes the agent’s trust or permissions independently, treat that as a governance defect rather than a platform-specific exception. The exception path should be explicit, time-bound, and reviewable, not absorbed into normal operations.
Practitioner takeaway: Cross-platform agents are governed correctly only when identity, purpose, and policy survive every hop unchanged enough to be audited and revoked as one chain of authority.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities in Salesforce?
- How should enterprises govern AI agents across multiple clouds and SaaS platforms?
- How should teams govern AI agents that rely on business context from data platforms?
- How should security teams govern AI agents that reason across multiple data platforms?