On-the-wire credential injection changes how AWS Bedrock access is governed

At a glance

What this is: This is an analysis of secretless AWS Bedrock access through on-the-wire credential injection, with the key finding that workloads can be authenticated without storing long-lived secrets on the client.

Why it matters: It matters because IAM, NHI, and workload identity teams need controls that govern runtime credential issuance, request signing, and trust boundaries rather than only secret storage.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• Only 38% have automated certificate lifecycle management in place.
• 57% of organisations lack a complete inventory of their machine identities.

👉 Read Riptides' analysis of secretless AWS Bedrock credential injection

Context

On-the-wire credential injection is a workload identity pattern that supplies short-lived credentials at request time instead of storing them in the application or host configuration. The NHI governance question is whether teams are still relying on credential persistence as a prerequisite for service access, especially when workloads call external services such as AWS Bedrock.

Riptides frames this as a secretless alternative to embedding AWS keys, token files, or static role credentials in client environments. That shifts the problem from secret storage to runtime trust, request signing, and workload-to-service authorization, which is where NHI, IAM, and PAM boundaries start to converge.

For teams using SPIFFE-based workload identity, the article sits squarely in the machine identity and federation space. The operational challenge is not whether identity exists, but how it is issued, scoped, refreshed, and enforced without reintroducing the very secrets the model is meant to eliminate.

Key questions

Q: How should security teams govern workloads that use secretless cloud access?

A: Security teams should govern secretless access by treating workload identity, trust relationships, and request signing as one control chain. The key question is not whether a secret is stored locally, but whether the workload is correctly bound to a scoped role, an approved audience, and a monitored service path. Without that, secretless access can still be overprivileged.

Q: Why do short-lived NHI credentials still need strong trust controls?

A: Short-lived credentials reduce exposure time, but they do not remove authorization risk. If role trust is broad, audience claims are weak, or workload matching is ambiguous, an attacker can still obtain valid access during the short window. Strong trust controls are what make ephemeral credentials safe enough to use at scale.

Q: What breaks when workloads depend on stored secrets for API access?

A: Stored secrets create a single point of exposure, revocation delay, and lateral movement risk. Once a secret is copied, it can be reused outside the intended workload boundary until it is rotated or invalidated. That makes the control problem operational, not just cryptographic, and it is especially dangerous for machine identities.

Q: Who should own policy for runtime credential injection and service trust?

A: Ownership should sit with identity and cloud security teams together, because runtime credential injection spans workload identity, IAM role trust, service authorization, and observability. If those controls are split across teams without a common governance model, the result is usually inconsistent trust definitions and weak accountability.

Technical breakdown

How on-the-wire credential injection works for workload identity

On-the-wire credential injection means the credential is added as the request leaves the workload, rather than being read from a local file or environment variable beforehand. In this pattern, the control plane issues a short-lived identity assertion for the workload, the request is signed for the target service, and the client never directly handles the secret material. The practical effect is that identity becomes transport-bound and ephemeral, not application-bound and persistent. That changes the control point from secret distribution to request mediation, which is much closer to how modern machine identity should be governed.

Practical implication: validate where credential material exists in the request path and remove any local storage dependency.

AWS Bedrock access through STS and SigV4

For AWS services, the injected credential still has to satisfy the normal authorization chain. The workload identity is exchanged for temporary AWS credentials through STS, then the request is re-signed with AWS SigV4 so Bedrock accepts it as authenticated. That means the security model still depends on role trust, audience matching, and service-specific signing, even if the application never sees a key. The main architectural change is that the workload becomes a transient credential consumer, not a credential owner.

Practical implication: review STS role trust, SigV4 signing boundaries, and audience claims as one integrated control set.

Why secretless access reduces exposure but not trust complexity

Secretless access removes the storage problem, but it does not eliminate authorization design. The workload still needs an identity, a scoped role, and a trusted external issuer, and each of those must be controlled precisely. In practice, the attack surface moves from leaked keys to mis-scoped trust, weak workload matching, or overly broad service permissions. That is a better place to manage risk, but only if teams treat the runtime identity chain as a first-class governance object rather than a transport convenience.

Practical implication: govern trust relationships, workload selectors, and permission scope with the same rigor you would apply to a privileged service account.

Threat narrative

Attacker objective: The attacker seeks to obtain authenticated access to cloud services such as Amazon Bedrock without needing durable credentials on the client.

1. Entry via exposed credentials or stored secret material is removed when credentials are injected only at request time, eliminating the usual client-side foothold.
2. Escalation is constrained by workload identity scope, STS role trust, and service-specific signing, so abuse depends on breaking the trust chain rather than stealing a local secret.
3. Impact is limited to the permissions of the injected role, but mis-scoped trust can still grant unauthorized service invocation or downstream data access.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Secret persistence is the real failure mode in workload identity governance. The article’s model removes the need for client-side AWS secrets, which is exactly where many NHI incidents begin. When credentials are injected per request, the governance problem moves away from storage and toward runtime trust, scope, and signing. Practitioners should treat persistent secret presence as a control failure, not a convenience.

Request-time identity changes the meaning of least privilege. In a traditional workload model, least privilege is assigned to a long-lived credential or role that can be reviewed later. Here, privilege is materialised only for the specific request path and then discarded, which makes static review cycles less useful than runtime policy validation. The implication is that NHI governance must track ephemeral entitlement rather than credential inventory alone.

On-the-wire injection is a named runtime trust-bypass pattern only if trust is left implicit. The concept worth naming here is ephemeral credential trust debt: the hidden governance cost of relying on short-lived credentials while leaving role trust, workload selectors, and service audiences loosely defined. That debt accumulates when teams celebrate secretlessness but do not tighten the control plane and service authorization model. Practitioners should regard the trust chain as the asset, not the credential.

SPIFFE-style workload identity becomes the anchor for cross-cloud consistency. The article shows why external services can be reached safely only when the workload identity is stable, portable, and policy-bound. That matters because the same governance logic has to survive AWS, GCP, Azure, and service-to-service patterns without reintroducing static secrets. The practitioner conclusion is to standardise the identity layer before scaling the service layer.

Machine identity programmes should stop measuring success by secret count alone. A workload can be technically secretless and still be dangerously over-authorised if the IAM role trust is broad or the identity binding is weak. The better governance question is whether the workload can prove who it is, what it may call, and under which runtime conditions. Practitioners should measure control quality at the trust boundary, not the vault boundary.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• The Critical Gaps in Machine Identity Management report found that 57% of organisations lack a complete inventory of their machine identities, according to SailPoint's Critical Gaps in Machine Identity Management report.
• For teams formalising workload identity, Guide to SPIFFE and SPIRE explains the workload identity model that underpins request-scoped trust and portable identity enforcement.

What this signals

Ephemeral credential trust debt: secretless access reduces exposure, but it can also hide weak trust definitions behind a cleaner operational story. If your programme still measures success by whether keys are stored locally, you are watching the wrong control boundary. The governance focus should move to workload identity binding, audience scoping, and trust-chain monitoring.

The broader signal for IAM teams is that machine identity strategy is becoming more transport-aware. Access decisions are no longer just about who can authenticate, but about where the credential is issued, how it is injected, and whether the service accepts the identity without broadening its trust surface.

With 66% of identity experts saying machine identities pose higher security risks than human identities, per The Critical Gaps in Machine Identity Management report, the operational message is clear: trust management, not secret handling alone, will define the next phase of NHI governance.

For practitioners

• Map every workload credential dependency Inventory where client applications still depend on local AWS keys, token files, or secret stores, then classify each dependency by runtime exposure and revocation difficulty. Focus first on services that invoke cloud APIs from outside the cloud boundary.
• Constrain trust at the workload identity layer Require explicit workload selectors, audience claims, and role trust policies for every injected credential path. Treat the workload identity binding as the control that determines whether secretless access is actually safe.
• Separate request signing from secret storage Ensure SigV4 or equivalent service signing happens inside the identity mediation path rather than inside application code. This keeps credential material out of the workload while preserving service authentication requirements.
• Review ephemeral access as a governance control Assess whether your review process can still see entitlements that exist only for a single request or short session. If it cannot, shift oversight to policy validation and trust-chain monitoring instead of relying on periodic certification.

Key takeaways

• On-the-wire credential injection removes local secret storage, but it shifts governance pressure to workload identity, trust, and request signing.
• The article’s model is only as strong as the scope of the injected role and the precision of the workload-to-service binding.
• For IAM and NHI teams, the practical control question is whether runtime trust is explicit enough to survive secretless access at scale.

Key terms

• Workload Identity: A workload identity is the cryptographic or policy-backed identity assigned to a non-human process so it can prove who it is to services and platforms. In mature implementations, it is issued, scoped, and revoked independently of application code, which makes it the foundation for machine identity governance.
• On-The-Wire Credential Injection: On-the-wire credential injection is a method of supplying credentials at the moment a request is sent rather than storing them inside the workload. It reduces secret exposure by moving authentication into the request path, but it still requires strict trust controls, audience matching, and service-side authorization.
• Request Signing: Request signing is the process of attaching a cryptographic signature that proves a request came from an authorised identity and has not been altered. For machine identities, signing is often the step that lets ephemeral credentials work without exposing long-lived secrets to the application or host.
• Trust Chain: A trust chain is the set of linked assertions that allow a service to accept an identity, from issuer and audience through role assumptions and runtime context. For NHIs, weakness in any link can turn short-lived credentials into effective standing privilege.

Deepen your knowledge

NHI governance, workload identity security, and secrets management 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 programme maturity, it is worth exploring.

This post draws on content published by Riptides: Federation On-the-Wire Credential Injection, Secretless AWS Bedrock Access example. Read the original.