The trust playbook is being weaponized across identity systems

At a glance

What this is: This is Delinea Labs’ June 2026 outlook on how inherited trust in packages, SaaS, vendor access, and federated identity changed the May threat landscape.

Why it matters: It matters because IAM, NHI, and identity governance teams need to treat trust boundaries, runtime validation, and third-party scope as active control points, not static design assumptions.

By the numbers:

• May recorded 6,308 total CVEs.
• Of those, 523 were identity-related and 78 directly impacted identity products.
• 92% of organizations believe AI will amplify identity-related threats in the coming years.
• The campaign affected 404 versions across npm and PyPI.

👉 Read Delinea's June 2026 outlook on weaponized trust in identity systems

Context

Identity risk now extends beyond stolen credentials and into inherited trust. When packages, SaaS guest accounts, third-party vendor paths, and federated logins behave exactly as configured, attackers can still turn those trust relationships into access and impact.

For IAM and NHI programmes, that shifts the problem from authentication only to trust governance across the full access path. The article argues that May’s incidents exposed a recurring weakness: organisations often secure the identity, but not the assumptions embedded in the system that accepts it.

Key questions

Q: How should security teams reduce risk from inherited trust in packages and SaaS access?

A: Start by treating trusted paths as identities that must be reviewed, bounded, and expired. Signed packages, guest-user endpoints, and third-party access should all pass explicit validation at use time, not just at onboarding. If the control only checks who issued the trust and not how it is consumed, attackers can inherit that trust and turn it into access.

Q: Why do federated identity systems still fail when authentication is working?

A: Federation can fail when issuance is correct but runtime acceptance is too broad. A valid token can still be replayed, routed to the wrong receiver, or accepted outside its intended scope. That means authentication succeeded, but authorization at execution time did not. Teams need receiver validation, audience checks, and session-level boundaries.

Q: What do security teams get wrong about signed software packages?

A: They often treat provenance as a final trust decision instead of one control in a longer chain. A package can be signed, valid, and still malicious if the publishing path or post-install behaviour has been compromised. Security teams need behavioural screening, execution isolation, and rapid revocation paths, not just signature checks.

Q: Who is accountable when third-party access persists beyond its intended purpose?

A: The organisation that owns the access model remains accountable, even when a vendor path is involved. Third-party identities need the same recertification, expiry, and monitoring discipline as internal privileged accounts. If the relationship changes and access remains active, lifecycle governance has failed, not just vendor oversight.

Technical breakdown

Inherited trust in signed packages and provenance

Software supply-chain attacks increasingly exploit trusted distribution rather than broken authentication. In the Mini Shai-Hulud case, malicious package versions were published with valid signed provenance, which meant provenance checks did not stop execution. The attacker did not need to steal credentials first if the ecosystem already trusted the package path. That makes signing necessary but insufficient, because trust in package integrity and trust in package intent are not the same thing. Practical implication: treat package provenance as one control layer, not the final authorization decision.

Practical implication: Review package trust policies so signed artifacts still pass through behavioural and integrity controls before execution.

SaaS guest-user permissions and default API exposure

SaaS compromises often persist because guest-user permissions and default API access create durable trust edges that administrators never revisit. The Delinea article describes a campaign that used a single misconfigured guest-user permission on a default endpoint, which meant the system itself granted the attacker a working path without a software bug. This is a configuration-driven identity problem, not a patching problem. Practical implication: inventory guest and external access paths as first-class identities, then review their default permissions separately from version management.

Practical implication: Audit guest-user and external API permissions as identities with explicit lifecycle and scope controls.

Federated identity and runtime validation failures

Federated identity can fail when issuance is correct but runtime validation is weak. The article’s identity infrastructure examples show why token acceptance, receiver validation, and downstream trust decisions all have to be enforced together. If a token is valid but can be replayed or accepted by an unintended service, federation has become an attack multiplier rather than a control. That problem is especially serious in environments where one identity provider underpins many applications. Practical implication: validate token use at the point of execution, not only at issuance.

Practical implication: Enforce runtime token validation and receiver checks across all federated applications and services.

Threat narrative

Attacker objective: The objective is to convert trusted identity paths into durable access and wider downstream impact without needing to break the front door first.

1. Entry occurred through trusted software distribution, guest-user API exposure, or third-party vendor access rather than obvious credential theft.
2. Escalation followed when valid trust relationships, reusable tokens, or default permissions let attackers move through approved identity paths.
3. Impact came from broad package spread, prolonged vendor-path access, biometric exposure, and federated authentication abuse that widened blast radius.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Trust inheritance is now the attack surface, not a side effect. The article shows attackers moving through signed packages, SaaS guest access, third-party paths, and federated identity without defeating the underlying mechanisms. That means the security problem is no longer just compromise, but acceptance of identity assertions that were never meant to carry that much downstream authority. Practitioners should treat inherited trust as a governance domain in its own right.

Default permissions are a governance failure when they behave like standing access. The guest-user API example demonstrates that a configuration left untouched can become an enduring identity path for attackers. This is not a software defect in the usual sense. It is a lifecycle and scope failure, because access that is never revalidated behaves like privilege granted forever. Practitioners need to understand where default trust is still active.

Runtime validation is the control boundary that now matters most. The identity infrastructure examples make clear that correct issuance does not guarantee safe use if validation is incomplete at the moment of execution. The same token or assertion can become unsafe when accepted by the wrong receiver or reused outside its intended path. The implication is that identity assurance must extend beyond creation and into every trust decision made at runtime.

Identity programmes need a named concept for this pattern: trust inheritance debt. Trust inheritance debt is the accumulation of unreviewed assumptions in signed packages, SaaS defaults, vendor paths, and federated acceptance rules. It grows when organisations rely on the legitimacy of the identity object but do not re-check the legitimacy of the path it takes. Practitioners should use this lens to identify where approved trust has become unbounded authority.

This pattern cuts across human IAM, NHI, and autonomous systems. The article’s incidents are not confined to one identity class. Package publishers, guest users, vendor accounts, and federated tokens all expose the same structural issue: trust is being inherited faster than governance can reassert boundaries. Security leaders should align review, validation, and offboarding controls across all identity types rather than treating them separately.

From our research:

• 92% of organizations believe AI will amplify identity-related threats in the coming years, according to Ultimate Guide to NHIs.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• For the trust problem this article describes, see also 52 NHI Breaches Analysis for the breach patterns that keep repeating.

What this signals

Trust inheritance debt: organisations now have to govern not just identities, but the assumptions attached to each accepted trust path. When signed packages, guest users, vendors, and federated tokens are treated as inherently safe, the control model stops at issuance and never reaches runtime use.

The practical shift is toward tighter review of external access paths and stronger binding between identity, audience, and execution context. The NHI problem is no longer isolated to service accounts because the same logic applies to machine identities, vendor identities, and any delegated trust chain that can outlive its original purpose.

With 80% of identity breaches involving compromised non-human identities such as service accounts and API keys, according to our research, the governance lesson is plain: boundary checks must move closer to execution, where inherited trust actually turns into access.

For practitioners

• Revalidate trust edges in package and CI/CD flows Require security review for package trust paths, provenance gates, and downstream execution triggers before remediation actions can be weaponized. Do not assume a signed package is safe simply because it is signed.
• Audit guest-user permissions as external identities Inventory guest-user API permissions, default endpoint exposure, and any access paths that are enabled by configuration rather than explicit approval. Review them on a fixed cadence as part of lifecycle governance.
• Apply third-party access expiry and session monitoring Treat vendor paths like privileged identities with explicit expiration, session visibility, and reauthorization requirements. If a third party can maintain access for weeks, the access model is too permissive.
• Enforce runtime validation on federated tokens Check receiver validation, token audience, and replay resistance at the point of use, not only at issuance. Any downstream service that accepts the token should be explicitly bound to it.
• Map inherited trust to identity lifecycle controls Link package publishers, vendors, guest accounts, and federated identities to the same offboarding and recertification process so trust does not continue after its legitimate purpose ends.

Key takeaways

• The breach pattern is less about broken authentication and more about trusted paths that were never revalidated.
• The evidence spans package supply chains, guest-user APIs, third-party access, and federated identity, showing the same trust failure across multiple environments.
• Teams should tighten runtime validation, external access lifecycle control, and package trust review before inherited trust becomes standing exposure.

Key terms

• Inherited Trust: Inherited trust is access or acceptance granted because a system believes an upstream identity, artifact, or relationship is already legitimate. In practice, it appears in signed packages, federated assertions, guest access, and vendor paths. The risk is not the trust itself, but the failure to revalidate it at the point where it becomes powerful.
• Runtime Validation: Runtime validation is the check performed when an identity, token, package, or assertion is actually used. It goes beyond issuance and asks whether the receiver, audience, and context are still valid at execution time. This is where many identity failures become exploitable.
• Guest-user Access: Guest-user access is external or non-employee access granted through an application or SaaS platform, often with permissions that differ from internal accounts. It becomes risky when default settings are left unchanged, lifecycle offboarding is weak, or the guest account is allowed to inherit broader trust than intended.
• Trust Inheritance Debt: Trust inheritance debt is the accumulation of unreviewed assumptions embedded in package ecosystems, SaaS defaults, third-party paths, and federated authentication. It grows when organisations assume legitimacy once and never re-check it. Over time, that debt turns ordinary access paths into durable attack routes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Delinea: The trust playbook is getting weaponized. Read the original.