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 via on-the-wire credential injection, with the key finding that credentials can be injected at request time instead of being stored on the client.

Why it matters: It matters because NHI and IAM teams need to rethink how they govern workload access when usable credentials may exist only for the life of a request, not on the application host.

Context

On-the-wire credential injection changes the trust model for non-human access to cloud services. Instead of placing AWS credentials on the workload and protecting them throughout the client lifecycle, the credential exists only at request time and is inserted into the outbound call path.

For NHI governance, that means the control boundary shifts from secret storage to issuance, scope, and re-signing of each request. The practical question is no longer whether a workload can safely hold a secret, but whether the programme can govern ephemeral use without relying on persistent credential artefacts.

Key questions

Q: What breaks when workloads depend on request-time credential injection for cloud access?

A: What breaks is the assumption that a workload can be governed by finding, rotating, or revoking a stored secret. When credentials are injected per request, the control point moves to issuance, claim validation, and role scope. Teams that keep using storage-centric reviews miss where the actual risk now lives.

Q: Why does ephemeral Bedrock access still need tight role trust controls?

A: Because the workload still reaches Bedrock through IAM permissions, and those permissions are only as safe as the trust chain behind them. If the subject, audience, or allowed resource is too broad, temporary credentials can authorise the wrong request just as effectively as a long-lived key.

Q: How do security teams know whether NHI provisioning is actually governed?

A: Look for three signals: every identity has an owner, every secret lands in an approved storage path, and every new object appears immediately in inventory and lifecycle workflows. If any of those is missing, provisioning is still operating as a delivery process rather than a governance process.

Q: What is the difference between stored AWS keys and just-in-time credential injection?

A: Stored keys are persistent secrets that the workload must hold and protect, while just-in-time injection supplies credentials only when a request is made. The first shifts risk to secret custody, rotation, and leakage, while the second shifts it to runtime trust, claims, and signing integrity.

Technical breakdown

How request-time credential injection changes workload authentication

Credential injection in this pattern occurs at the network boundary, not inside the application process. A workload is associated with an identity, a temporary AWS credential is issued, and the outbound request is re-signed just before transmission. The client application never handles the live secret, but the target service still receives a fully authenticated SigV4 request. That distinction matters because the security property is not “no authentication,” it is “authentication without local secret custody.” In practice, this moves trust to the control plane, the identity binding, and the per-request signing path.

Practical implication: govern the control plane and signing boundary as part of the NHI attack surface, not just the application host.

Why secretless access changes Bedrock role trust design

The AWS side still depends on IAM role permissions and a trust relationship, but the trusted principal is now an external identity source rather than a stored client secret. In the article’s example, the workload exchanges an ID token for temporary credentials and the resulting role assumes permission to invoke a specific Bedrock agent. That means the trust policy, audience, subject claim, and role scope become the real control plane for access. The workload no longer proves itself by presenting a stored key; it proves itself through runtime-issued identity and request-specific authorisation.

Practical implication: review Bedrock trust policies, subject claims, and role scope as a single access chain.

Where short-lived credentials still leave governance risk

Short-lived credentials reduce exposure, but they do not remove governance responsibility. The article still relies on temporary AWS credentials, workload identity binding, and automated refresh when credentials expire. That means any weakness in identity scoping, credential audience, or egress targeting can still produce overbroad access, even without static keys. Secretless does not mean control-less. It means the risk moves from secret theft on disk to mis-scoped issuance and misuse in transit.

Practical implication: validate whether your NHI programme can detect and contain over-scoped ephemeral credentials before they reach the target service.

Threat narrative

Attacker objective: The objective is to gain authenticated cloud-service access through the workload’s request path without needing a persistent secret on the host.

1. Entry occurs when a workload obtains runtime-issued identity and a temporary AWS credential path is established for outbound Bedrock access.
2. Escalation would come from mis-scoped role trust or overbroad service targeting, allowing a workload to call more than the intended Bedrock resource.
3. Impact is unauthorised service invocation or expanded cloud access, even though no long-lived secret was stored on the client.

Breaches seen in the wild

• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Ephemeral credential trust debt: replacing stored secrets with request-time injection removes one class of exposure while creating a new governance debt around issuance, scope, and replay assumptions. A programme that only tracks where secrets live misses the control point that now matters most. The practitioner implication is that secretless access must be governed as an identity issuance problem, not a secret-storage problem.

Runtime re-signing becomes the enforcement boundary: once the client never sees the credential, the decisive control is the system that binds identity to the request and re-signs it at the edge. That shifts assurance toward workload identity, federation claims, and the policy that determines which outbound calls can be signed. Practitioners should treat the signing path as a privileged identity function.

Secretless access does not eliminate least privilege; it relocates it: the entitlement is still expressed through role scope, target service selection, and token audience. If those are too broad, ephemeral delivery simply shortens the exposure window for a still-overprivileged path. The conclusion is that workload identity governance must measure privilege at issuance time, not after secrets are found.

Credential custody is no longer the primary assumption: traditional NHI controls were built around the premise that a workload must hold a credential to use it. That assumption fails when the actor acquires and discards credentials per request, because there is no stable secret artefact to inventory or rotate. The implication is that lifecycle and review processes must move from stored assets to runtime authorisation events.

Bedrock access governance now depends on claim fidelity: the real control question is whether the subject, audience, and role mapping consistently describe the workload that is actually making the call. When those claims drift, secretless transport can still authorise the wrong actor. Practitioners should validate claim-to-role alignment as part of non-human identity governance.

What this signals

Secretless transport changes the governance problem: the security question is no longer how to protect credentials at rest on a client, but how to prove that a runtime-issued identity is narrow enough for the specific request it signs. That is a workload identity problem, not a secrets-hygiene tweak.

The operational boundary moves to the trust chain behind the outbound call. If the role trust, audience, and subject claims are broad or ambiguous, ephemeral credentials simply make the exposure harder to inspect, not safer by default.

For practitioners

• Audit request-time identity issuance paths Map every workload that receives temporary credentials at call time and confirm where identity is minted, signed, and refreshed before the request leaves the host.
• Constrain Bedrock role trust relationships Limit the trusted subject, audience, and resource scope for each role that can invoke a Bedrock agent, and remove broad trust statements that apply across workloads.
• Treat the signing boundary as privileged Review the component that re-signs outbound requests as part of your high-value NHI surface, because it now controls when credentials become usable.
• Verify ephemeral credential refresh behaviour Confirm that temporary credentials expire and renew only for the intended workload and target service, with no reuse across unrelated processes or endpoints.
• Inventory all secretless client integrations Document which applications no longer store AWS keys locally so that you can distinguish true secretless access from hidden credential fallbacks.

Key takeaways

• On-the-wire credential injection removes local secret custody from the client, but it does not remove the need for strong identity governance around the request path.
• The decisive controls shift to workload identity binding, role trust scope, and request-time signing integrity.
• Teams should treat secretless access as a runtime authorisation model and validate it with the same rigor they apply to other high-risk NHI paths.

Key terms

• Connection-Time Credential Injection: A control pattern where the real credential is supplied only when a workload starts an authenticated session. The application does not store or directly handle the durable secret, which reduces exposure and shifts governance to the access event itself.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Runtime re-signing: The act of generating or replacing a request signature immediately before transmission so the target service receives a valid authenticated call. This preserves access without exposing persistent keys to the application, but it also makes the signing component a privileged enforcement point.
• Secretless Access: Secretless access is a pattern where workloads authenticate and receive access without relying on long-lived embedded credentials. It typically uses runtime identity verification, federation, and short-lived authorization decisions. The goal is to reduce exposure from hardcoded or reusable secrets while keeping machine-to-machine access functional.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.