Who is accountable when delegated access crosses trust domains?

Why This Matters for Security Teams

Once delegated access crosses trust domains, accountability stops being a single-owner problem and becomes a chain-of-custody problem. The original principal may have authorised the delegation, but the trustee applies the constraints, and the receiving organisation decides how access is actually enforced. That means identity proof, scope, logging, and revocation all have to survive across organisational boundaries, not just inside one control plane.

This is why NHI governance cannot rely on informal agreements or static trust assumptions. The practical question is whether an auditor can reconstruct who granted what, under what authority, for how long, and what happened if the delegate exceeded scope. The risk shows up in secrets, service accounts, federated workloads, and AI agents alike, especially where access is long-lived or passed through multiple systems. NHI Management Group’s research on Ultimate Guide to NHIs and 52 NHI Breaches Analysis shows that weak visibility, not just weak policy, is what turns delegated access into an incident.

Industry guidance from the OWASP Non-Human Identity Top 10 reinforces that unmanaged machine identities and opaque credential paths create a control gap that crosses teams and vendors. In practice, many security teams discover that delegation failed only after the receiving domain has already used access in ways the original issuer never intended.

How It Works in Practice

The defensible model is to treat every cross-domain delegation as a verifiable transaction, not a blanket permission. The original principal should be bound to the delegation event, the trustee should receive only the minimum scope needed, and the receiving organisation should enforce its own local policy before any action is allowed. Best practice is evolving toward explicit evidence of authority, context, and revocation rather than relying on trust inherited from federation alone.

Operationally, this means four things. First, the delegation should be represented as a distinct identity artifact, such as a token, assertion, or scoped credential, rather than a shared secret. Second, the token should carry tight constraints on audience, purpose, lifetime, and delegation depth. Third, logs must preserve provenance so investigators can trace the action back through each hop. Fourth, revocation must propagate quickly enough that the original principal can actually withdraw trust when a delegate misbehaves.

• Use workload identity for the delegate, not a copied human credential.
• Issue just-in-time access with short TTLs and explicit audience restrictions.
• Record who authorised the delegation, which system enforced it, and when it expired.
• Validate every cross-domain request at runtime using local policy, not only pre-approved trust.

The NHI Management Group DeepSeek breach and the vendor research on LLMjacking: How Attackers Hijack AI Using Compromised NHIs illustrate how quickly delegated or exposed credentials can be abused once they cross control boundaries. External implementation guidance from the OWASP Non-Human Identity Top 10 aligns with this approach by emphasizing strong lifecycle control, least privilege, and continuous validation. These controls tend to break down in loosely federated environments where one side cannot enforce revocation or where audit logs are not mutually trusted.

Common Variations and Edge Cases

Tighter delegation controls often increase operational friction, requiring organisations to balance auditability against developer velocity and partner interoperability. That tradeoff becomes especially visible when access crosses legal entities, cloud tenants, or AI agent boundaries, because each domain may have different identity formats, policy engines, and log retention rules.

There is no universal standard for delegated accountability across all trust domains yet. Current guidance suggests treating the original principal as accountable for authorising the delegation, the trustee as accountable for honoring constraints, and the receiving organisation as accountable for enforcing local policy. But in shared-service and marketplace models, that split can blur. If the receiving side accepts broad upstream trust without its own evaluation, accountability becomes difficult to prove even when the delegation was technically valid.

Edge cases include brokered access, emergency elevation, and agent-to-agent delegation. In those scenarios, the strongest control is usually a short-lived, purpose-bound token paired with immutable provenance logs and an explicit revocation path. Where the delegate is an autonomous system, the burden is higher because the action pattern can change at runtime and chain into other tools. That is why accountability must be documented in both policy and telemetry, not just in contracts.

Where cross-domain delegation depends on opaque third-party connectors or long-lived static secrets, the model breaks down because the original authority can no longer prove what happened after handoff.

Related resources from NHI Mgmt Group

• Who is accountable when a delegated agent performs the wrong tool action?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?