Those relationships become the paths attackers exploit to move quickly and blend into normal activity. The environment may still look controlled at the edge, but the internal trust graph remains open. The result is reduced confidence, slower detection, and a governance model that cannot explain how access really moves through the business.
How unmanaged trust turns into an attack path
When trust is not governed, each approved relationship becomes a shortcut an attacker can reuse after one compromise. That can include user-to-service delegation, service-to-service trust, federated access, and AI agents acting with inherited authority. The issue is not just access, it is the absence of clear boundaries on how trust is granted, inherited, and retired.
In practice, unmanaged trust creates a graph that is hard to reason about during incidents. A control at the edge may still look strong, while the internal pathing between accounts, tokens, and delegated actions remains broad enough for abuse. That gap is what lets malicious activity blend into normal business flows.
Well-governed trust relationships make the security model legible, because they define who can act for whom, under what conditions, and with what limits. Without that discipline, even legitimate automation can become indistinguishable from unauthorized movement once an attacker obtains a foothold.
Why trust sprawl is especially dangerous across humans, services, and agents
Users, services, and AI agents fail differently, but the risk compounds when they share the same trust fabric. A user credential can authorize a service, a service can expose a downstream API, and an agent can chain both of those into actions that were never intended to be open-ended. If those links are not explicitly governed, the blast radius grows faster than most teams expect.
This is also where “trusted by default” assumptions break down. An access relationship may be valid at creation time, yet become dangerous later because the original business context changed, the automation expanded, or the agent’s task scope drifted. The more cross-domain the trust path, the harder it is to detect when a valid relationship has become an attacker’s route.
For AI agents in particular, the trust question is not whether the system can act, but whether its authority is bounded tightly enough that one compromised agent, token, or delegated workflow cannot impersonate normal business activity at scale. AI Agent Authorisation Guide is useful here because it treats per-action decisions, task-scoped access, and human approval as design choices rather than afterthoughts.
What governance has to define before trust can be safe
Trust governance is strongest when it answers four practical questions: who is allowed to trust whom, what can be delegated, how long that delegation lasts, and what evidence proves the path is still valid. If any of those are vague, the organisation ends up with a trust relationship that exists technically but cannot be defended operationally.
Good governance also separates discovery from approval. You need a current inventory of trust paths, but you also need a decision model for whether a path should still exist, whether it should be narrowed, and whether it should require stronger proof at runtime. That is especially important where federated trust, cross-tenant access, or multi-agent interaction can extend privilege beyond the original system boundary. NHIMG’s Federation and Trust Relationships Guide is a useful starting point for the relationship types that commonly need this treatment.
For AI-driven environments, governance should also include agent identity, delegated authority, and retirement. An agent that still possesses valid tokens, stale permissions, or an old trust grant after its task is finished is not governed trust, it is residual access. That is why Agentic AI Identity Guide is relevant to the trust problem, not just the identity problem.
Risk and Threat Considerations
Unmanaged trust relationships create hidden attack routes that are harder to spot than direct account compromise. Once an attacker lands in one trusted spot, they can often move laterally by using legitimate-looking relationships, delegated permissions, or agent actions that appear normal in logs.
Failure mechanism: Trust is granted more broadly than it is monitored or revoked, so a single compromise can ride existing user, service, or agent relationships into other systems without triggering obvious policy violations.
Impact: Detection slows, confidence in access reviews drops, and the organisation may not be able to explain which actions were truly authorized versus inherited through an old trust path. Over time, that weakens incident response and makes business controls look stronger than they actually are.
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 | Covers delegated agent authority and privilege misuse across trust chains. |
| Recommendation — Enforce per-action authorization and limit agent privilege to the task scope. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Trust sprawl often leaves service and agent identities with excessive reusable access. |
| Recommendation — Reduce standing privilege and remove unnecessary cross-system trust grants. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Trust governance depends on enforcing who may use inherited access paths. |
| IA-9 — Service Identification and Authentication | Service and agent trust relationships require authenticating non-human principals to each other. | |
| IA-5 — Authenticator Management | Stale tokens and secrets keep trust paths alive after intended retirement. | |
| Recommendation — Enforce access decisions at each trust boundary rather than relying on initial authentication. Authenticate services and agents explicitly before allowing cross-system trust. Rotate and revoke authenticators when trust relationships change or expire. | ||
Practitioner Guidance
What to verify: Validate the full trust path, not just the login event. For each important relationship, confirm the principal, the delegated scope, the expiration or revocation condition, and the downstream systems that trust the result. If any of those are missing, treat the path as incomplete governance, not simply as an access issue.
Decision rule: If a trust relationship can be used to act across system boundaries, require an explicit owner and a revocation path. If an AI agent, service account, or federated principal can still operate after the original business need has ended, rotate or retire that path before investigating whether it has already been abused.
What practitioners underestimate: The hardest part is not creating trust, it is proving that trust still matches current business intent. At scale, stale delegation and cross-system inheritance become more dangerous than classic password misuse because they look legitimate while carrying broad, reusable authority.
Practitioner takeaway: Treat trust as a controlled business dependency, not an invisible convenience layer. If you cannot explain how access moves, you cannot reliably govern how it will be abused.
Related resources from NHI Mgmt Group
- Who should own continuous trust across people, devices, services, and AI agents?
- How should organisations design identity for AI agents that act on behalf of users across many services?
- What happens when AI agents operate across endpoints, local tools, and cloud services without a single control layer?
- How should organizations approach the governance of AI agents?