Module 5: Securing The Ai Workload

4. Why Bedrock doesn't need an API key

Next →

Description

BedrockManifestExtractorRole (Module 3, lesson 4) has, nowhere in its definition, a field called api_key, secret, or token. The extract-shipment-manifest-fields function invokes bedrock:InvokeModel by signing the request with the temporary credentials Lambda hands it when it assumes that role — the same SigV4 mechanism it already uses to read from S3 or write to DynamoDB — with no new secret to create, rotate, or manage. This lesson explains why that's a real advantage, not an incidental detail, contrasting it with the way most third-party LLM APIs require exactly the opposite — and, with the same honesty as the rest of this guide, names that AWS does, since 2025, offer an alternative API keys mechanism for Bedrock, and why this guide doesn't use it.

Connection to the module

This module reuses cloud-security-and-guardrails-guide's security gate with no change — and that guide, in its complete Module 3, built the secret-management discipline (SSM Parameter Store/Secrets Manager) for the credentials Andes Cargo does need to manage (the customs API, for example). This lesson is the honest counterpart to that work: it precisely names a secret-management surface this guide never had to build, and why.

Most third-party LLM APIs require a secret you have to manage

Almost any language model provider outside AWS's ecosystem — OpenAI, Anthropic direct (without Bedrock), Google AI Studio, among others — authenticates its calls with an API key: a long string, generated once, that the code has to store somewhere and send with every request, typically in an HTTP header (Authorization: Bearer sk-...). That API key is, in practice, a long-lived secret: if it leaks — into a public repository, a log, a misconfigured environment variable — anyone who obtains it can bill against the original owner's account until someone revokes it manually. Managing that key correctly requires the same discipline cloud-security-and-guardrails-guide, Module 3, already built for Andes Cargo's customs API: never in plain text in the repository, periodic rotation, a dedicated secrets manager.

   TYPICAL FLOW OF A THIRD-PARTY LLM API

   code  --Authorization: Bearer sk-abc123...-->  provider's API
              │
              │  the secret travels in every request, as-is
              │  if it leaks, it stays valid until
              │  someone revokes it by hand
              ▼
           a new leak surface, one that has to be managed
           with the same care as any credential

Bedrock, by default, doesn't have that surface: IAM signs the call

bedrock:InvokeModel, invoked the way extract-shipment-manifest-fields does, never sends a long-lived secret in the request. What travels is a SigV4 signature — a cryptographic calculation derived from temporary credentials AWS Security Token Service (STS) issued when Lambda assumed BedrockManifestExtractorRole — not the secret itself. The distinction matters in practice, not just in theory:

   extract-shipment-manifest-fields's FLOW (this guide)

   Lambda assumes BedrockManifestExtractorRole
        │
        │  STS issues TEMPORARY credentials (they expire on their
        │  own, never written to the code or the repository)
        ▼
   The SDK signs the request with SigV4 -- the secret itself
   NEVER travels in the request, only the signature derived from it
        │
        ▼
   bedrock:InvokeModel, evaluated against
   BedrockManifestExtractorRole's policy -- exactly the scoped ARN
   from Module 3, verified with bedrock-least-privilege.rego
   (this module's lesson 3)

This isn't a Bedrock quirk — it's the same IAM mechanism Andes Cargo has already used since terraform-and-iac-guide for process-shipment-manifest to read from S3 or write to DynamoDB, applied here, for the first time, to invoking a language model. No guide in this ecosystem ever needed to manage an "S3 API key" or a "DynamoDB API key" — invoking Bedrock this way inherits that same absence of surface.

The exact honesty: AWS does offer API keys for Bedrock since 2025, and this guide doesn't use them

It would be imprecise to say Bedrock "never" has API keys — that's no longer true. Since July 2025, AWS offers an alternative mechanism, explicitly designed to simplify integration with tools that expect a bearer token-style authentication model (the same pattern as OpenAI/Anthropic direct): "API keys for Amazon Bedrock enable developers to quickly generate access credentials directly within the Amazon Bedrock console or AWS SDK", with two variants — short-lived ("valid for the duration of your console session, or up to 12 hours, whichever is shorter") and long-lived ("give you the flexibility to define key validity duration") —, meant to remove the friction of "manually configure IAM principals and policies" (source: AWS — Amazon Bedrock API keys, see Resources).

This guide does not use that mechanism, for a concrete reason, not an aesthetic preference: adopting it would reintroduce exactly the secret-management surface BedrockManifestExtractorRole avoids by design. Unlike SigV4 — where the secret never travels in the request —, a Bedrock bearer token does travel as-is on every call, the same risk pattern as any third-party API key. Post-launch security research confirms this with real, not hypothetical, evidence:

  • Keys leaked in public repositories, within weeks, not months. Security researchers reported Bedrock API keys leaked publicly within the first two weeks after availability, with an estimated exposure of up to $18,000 per day per region in LLMjacking charges — unauthorized use of a model billed to the victim's account — if a long-lived key falls into the wrong hands.
  • A real case, with an exact date. Between December 4, 2025 and January 26, 2026, an implementation flaw allowed Bedrock's long-lived keys — built on Service Specific Credentials — to evade Service Control Policy (SCP) enforcement: "Denying the permission via SCP did not work for long-term keys". An IAM user with permission for the underlying service could create a credential of this type for themselves and bypass an organizational restriction that, with traditional IAM/SigV4, would have been enforced. AWS fixed the flaw on January 29, 2026, nine days after it was reported, and stated it had not identified any affected customers (source: Sonrai Security, see Resources).

Neither finding says Bedrock's API keys are, in themselves, a bad tool for every context — AWS designed them for a real use case: integrating Bedrock quickly with tools that already speak OpenAI's bearer token protocol, without having to learn IAM first. What they say, precisely, is that for this specific workload, where BedrockManifestExtractorRole already exists, is already scoped by least privilege (this module's lesson 2), and is already automatically verified (lesson 3), adopting an additional bearer token mechanism wouldn't solve any real Andes Cargo problem — and would add back exactly the surface this guide avoided since Module 3: a secret to manage, rotate, and protect from a leak.

Why this matters for this module's security gate

The rest of this module — lesson 3's Rego policy, lesson 5's Trivy scan, lesson 6's cosign signature — exists to verify declared infrastructure and signed artifacts. None of those three tools is designed to watch over the rotation of a long-lived secret, because this project never introduced one to invoke Bedrock. If Andes Cargo had chosen the API keys path, this module would have needed a whole additional piece — the same kind of discipline cloud-security-and-guardrails-guide, Module 3, already built for the customs API: where the key is stored, who can read it, how often it's rotated, what happens if it leaks. None of those questions has an answer this module needs to give, because the question itself doesn't apply.

Common mistakes

Claiming, without nuance, that "Bedrock never has API keys" (generalizing a design decision of this guide as if it were a technical limitation of the service). What happens: someone, after reading the first half of this lesson, repeats in an interview or a technical conversation that Bedrock, as a service, doesn't support API-key authentication. How to spot it: if your explanation of this lesson doesn't mention the API keys mechanism AWS launched in July 2025. How to fix it: the correct, complete claim is that this specific workload, with BedrockManifestExtractorRole already built, doesn't need one — not that the service lacks the option. This lesson's honesty section exists exactly for this distinction.

Assuming Bedrock's API keys are inherently insecure, without context on what they were designed for. What happens: someone, seeing the two cited security findings, concludes AWS launched a flawed feature no one should ever use. How to spot it: if your takeaway from this lesson is "Bedrock's API keys are an AWS mistake," instead of "they're not the right choice for this specific workload." How to fix it: the December 2025–January 2026 flaw was an SCP-enforcement implementation bug, already fixed — not a conceptual failure of the mechanism. Bedrock's API keys remain a reasonable option for the use case AWS declared (fast integration with bearer-token tools), it simply isn't the use case for extract-shipment-manifest-fields, which already has a scoped, verified IAM role.

Confusing "SigV4 signs the request" with "there's no credential involved at all" (over-simplifying). What happens: someone concludes that, because there's no visible API key, Bedrock gets invoked "with no credentials of any kind." How to spot it: if your explanation of this lesson doesn't mention that STS still issues temporary credentials. How to fix it: there are credentials — STS issues them every time Lambda assumes the role — the difference is that they're temporary (they expire on their own, no manual rotation needed) and never travel in the request (only the signature derived from them does). "No secret to manage" doesn't mean "no credential at all" — it means the credential mechanism doesn't require the operational discipline of a long-lived secret.

Exercises

Exercise 1 — Explain, in one sentence, the difference between "the secret travels in the request" (a typical API key) and "only a signature derived from the secret travels" (SigV4). A colleague asks why that seemingly technical distinction has real security consequences.

See solution

With a typical API key, if someone intercepts or gains access to a single request — a misconfigured log, a compromised proxy — they get the complete secret and can reuse it indefinitely until someone revokes it. With SigV4, each signature is valid only for that specific request (the algorithm incorporates the date, method, path, and other parameters of that exact call) — intercepting a signature gives no one the ability to sign future requests, because the underlying secret (STS's temporary credentials) was never transmitted, only used locally to compute the signature.

Exercise 2 — Based on the real December 2025–January 2026 case, explain why an SCP-enforcement flaw in long-lived API keys is a risk traditional SigV4/IAM doesn't share the same way. What would have been different if BedrockManifestExtractorRole, instead of an API key, had been subject to that same SCP?

See solution

An SCP (Service Control Policy) acts as an organizational boundary evaluated against the IAM identity making the call — with traditional IAM/SigV4, that identity is the role itself (BedrockManifestExtractorRole), and the SCP applies directly, a mechanism AWS has proven for years. The real flaw in the cited period happened because long-lived API keys are implemented as Service Specific Credentials tied to an IAM user, and the SCP's evaluation against that specific credential had a gap — not against the IAM user itself, but against the derived credential. BedrockManifestExtractorRole, by not using that mechanism, was never exposed to that specific class of flaw, simply because the code path that contained it never executes for this workload.

Exercise 3 — Design, in prose, a legitimate scenario where Andes Cargo SHOULD consider Bedrock's API keys, despite everything this lesson explained. Think about the use case AWS declared as the mechanism's original purpose.

See solution

A reasonable answer: if Andes Cargo wanted to give an external development team — a contractor building a quick prototype, for example — trial access to Bedrock using a tool that already speaks OpenAI's bearer token protocol (a third-party library, a quick experimentation notebook), without first having to teach them how to correctly configure and assume an IAM role, a short-lived API key (up to 12 hours max, per the cited source) could be a reasonable choice for that specific, time-bounded context — never for a production workload like extract-shipment-manifest-fields, which runs continuously, with no interactive human in the loop, and where the IAM role already exists and is already verified by this module's gate.

Summary and next step

This lesson contrasted extract-shipment-manifest-fields's default authentication model — SigV4, signed with temporary STS credentials issued when it assumes BedrockManifestExtractorRole, with no secret traveling in the request — with the API-key pattern most third-party LLM APIs require. With the same honesty as the rest of this guide, you named that AWS does offer an alternative API keys mechanism for Bedrock since July 2025, and saw two real security findings — keys leaked within two weeks of launch, and an SCP-enforcement flaw between December 2025 and January 2026, already fixed — that explain why this guide, deliberately, doesn't use it for this workload.

Before moving on you should be able to: explain the difference between "the secret travels" and "only the signature travels"; name Bedrock's alternative API keys mechanism and the use case AWS designed it for; and justify, with evidence, why BedrockManifestExtractorRole is the right choice for extract-shipment-manifest-fields specifically.

Lesson 5 returns to code: trivy config, run for real over bedrock.tf and modules/bedrock-guardrail/, the inherited security gate's second control applied to this module's AI infrastructure.

Resources

  1. AWS — Amazon Bedrock introduces API keys for streamlined development — the official source for Bedrock's API keys mechanism, including the verbatim quote used in this lesson.
  2. Sonrai Security — Cracks in the Bedrock: Bypassing SCP Enforcement with Long-Lived API Keys — the real December 2025–January 2026 case cited in this lesson, with the exact date of the flaw and its fix.
  3. AWS Docs — Authentication and access control for Amazon Bedrock — official reference for the IAM/SigV4 authentication model BedrockManifestExtractorRole uses.
  4. This guide's Module 3, lesson 4 (04-hands-on-bedrockmanifestextractorrole-least-privilege.md) — the original construction of the role whose authentication mechanism this lesson explains.
← Previous3. Hands-on: `bedrock-least-privilege.rego`, added to `policy/`Next →5. Hands-on: Trivy on the new Terraform