What do security teams get wrong about moving requests across teams?

Why This Matters for Security Teams

Moving requests across teams looks like a simple workflow problem, but it is really a boundary problem. In multi-tenant and shared-service environments, the risk is not only whether a request is legitimate at the source; it is whether the destination team is authorised to receive, inspect, or act on it. If that second check is skipped, data and embedded permissions can cross domains without anyone noticing.

This is why NHI governance and workflow authorization need to be treated together. The Ultimate Guide to NHIs notes that 92% of organisations expose NHIs to third parties, which makes cross-team movement a routine attack path rather than an edge case. Security teams also miss that copied requests can inherit secrets, tokens, and tool context unless the destination is re-evaluated under its own policy. The control point is not just who created the request, but where it is being consumed. That aligns with the boundary and access intent principles in NIST SP 800-53 Rev 5 Security and Privacy Controls. In practice, many security teams encounter cross-team injection only after a downstream workflow has already processed the wrong object.

How It Works in Practice

The right model is to authorise at both ends. Source validation confirms the requestor, object integrity, and upstream context. Destination validation confirms that the target team, queue, project, or tenant is allowed to receive that object at this moment. In practice, this means the request should carry an identity for the object, a tenant or team boundary tag, and a policy decision that is re-checked when it crosses into a new domain.

For human-operated systems, this is often implemented with explicit approval gates and tenant-aware routing. For machine-to-machine workflows, it should include workload identity, scoped tokens, and destination-side policy checks. NHI guidance increasingly treats this as a lifecycle issue, not a one-time access grant. The Ultimate Guide to NHIs is useful here because it frames secrets, rotation, and offboarding as part of the same control surface.

• Validate destination membership before a request enters another team’s queue or datastore.
• Bind requests to tenant, project, or collection identifiers so context is not inferred from the source alone.
• Use short-lived credentials and revoke them after the cross-team action completes.
• Log both the source decision and the destination decision so reviewers can reconstruct the full path.
• Apply least privilege at the receiving boundary, not only at the point of creation.

Where teams need a stronger formal model, NIST SP 800-53 Rev 5 Security and Privacy Controls supports access enforcement, auditability, and system boundary control, which are the practical building blocks for this pattern. These controls tend to break down when routing is implicit, because hidden inheritance lets the destination treat upstream trust as if it were local trust.

Common Variations and Edge Cases

Tighter destination checks often increase workflow friction, requiring organisations to balance speed against boundary assurance. That tradeoff becomes visible in shared platforms, delegated admin tools, and automated ticketing systems where teams expect requests to “just move” between queues. Current guidance suggests that destination policy should be explicit whenever ownership, tenancy, or downstream privileges change, but there is no universal standard for the exact enforcement point.

One common edge case is mirrored data or replicated tickets. A request may be safe to duplicate for visibility but not safe to execute in the destination system. Another is delegated operations, where one team can create a task but cannot approve it for another team’s collection. In those cases, the source may be authenticated, yet the destination still needs independent authorisation. That is especially important when service accounts or API keys are embedded in request payloads, because the receiving workflow may inherit access it never should have had.

Security teams should also watch for “helpful” automation that remaps requests across teams based on labels or metadata alone. Labels are not proof of authorisation. The safer pattern is explicit destination membership, policy evaluation at handoff, and revocation after use. That is the practical lesson echoed across NHI governance and broader control frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls: trust must be re-established at the boundary, not borrowed from the source.

Related resources from NHI Mgmt Group

• What do security teams get wrong about same-origin upload handling?
• What do security teams get wrong about self-service app requests?
• What do security teams get wrong about identity verification for support requests?
• What do security teams get wrong about moving authorization out of application code?