AWS Bedrock API keys turn GenAI access into an NHI governance issue

At a glance

What this is: AWS Bedrock API keys simplify access to GenAI models but expand the NHI surface by introducing short-term and long-term keys with different exposure windows.

Why it matters: IAM, PAM, and NHI teams need to treat Bedrock API keys as governed identities because unmanaged issuance, hardcoding, and weak rotation can create persistent model-access risk.

By the numbers:

• Short-term keys are valid for up to 12 hours.

Context

AWS Bedrock API keys are a non-human identity problem because they create model access credentials outside the normal IAM role pattern. In practice, that changes the control point from user provisioning to credential lifecycle management.

The governance gap is not access to generative AI itself. It is the ease with which a new credential type can be issued, copied, embedded in code, and left to persist without clear ownership or rotation discipline.

For security teams, the key question is whether GenAI onboarding is creating a parallel identity estate that is visible to IAM, PAM, and secrets tooling. If it is not, organisations will lose track of who or what can call the models.

Key questions

Q: How should teams govern Bedrock API keys that support GenAI workflows?

A: Treat them as non-human identities with a full lifecycle, not as convenience tokens. That means inventoried ownership, explicit expiration, rotation, revocation, and detection across code, logs, and pipelines. If the key can call a model directly, it needs the same governance discipline as any other privileged machine credential.

Q: Why do long-lived API keys create more risk for AI agents?

A: Long-lived API keys increase risk because they persist across tasks, deployments, and runtime changes. If one is exposed in a container, pipeline, or config file, the attacker can reuse it until it is manually revoked. For AI agents, that persistence creates a larger blast radius than the workload actually needs.

Q: What breaks when API keys are embedded in repositories or pipelines?

A: The identity program loses visibility, ownership, and revocation speed. Once a Bedrock key is hardcoded or logged, it can spread beyond the control of the original team and persist after the intended use ends. Discovery must therefore happen across engineering and collaboration systems, not just in the identity platform.

Q: Should organisations treat Bedrock key management as IAM or secrets management?

A: Both, but neither alone is sufficient. IAM establishes who may create and use the credential, while secrets management controls where the key lives and how it is rotated or revoked. For GenAI access, the operational answer is to bind the two so credential lifecycle and model authorisation are governed together.

Technical breakdown

Why Bedrock API keys behave like a new NHI class

A Bedrock API key is a machine-consumable credential that authorises direct access to generative AI services. Unlike a human login, it is not a session for a person but a reusable secret that can be copied into repositories, pipelines, or collaboration tools. That makes the credential itself the control boundary. The technical issue is not that the model is unsafe by default. It is that a new identity artefact has appeared with its own issuance, expiry, and revocation semantics, and those semantics can diverge from standard IAM governance if teams do not inventory it explicitly.

Practical implication: Treat Bedrock API keys as governed non-human identities, not as convenience tokens hidden inside application code.

Short-term and long-term keys change exposure windows

AWS’s two key types create different governance profiles. Short-term keys reduce the lifetime of abuse by expiring within hours, while long-term keys can persist until revoked or manually expired. That distinction matters because exposure is driven by how long a key remains valid after it is issued, leaked, or copied. In identity terms, long-lived secrets extend the blast radius of a mistake, while short-lived credentials compress it. The control problem is therefore not only whether a key exists, but whether its lifetime matches the operational need that justified creating it.

Practical implication: Align key lifetime to task duration and prevent standing long-lived Bedrock credentials from becoming default access paths.

Discovery and attribution are part of the control plane

Bedrock API keys become hard to govern when they spread across code, logs, and pipelines without central visibility. Once that happens, access control alone is not enough because teams cannot revoke what they cannot find or associate to an owner. The interesting property noted in the article, namely that the key name is embedded in the token, creates an attribution opportunity for detection and incident response. That is useful, but only if discovery and ownership mapping are built into the normal NHI control process rather than treated as after-the-fact forensics.

Practical implication: Extend secret discovery and ownership mapping to Bedrock keys so revocation and accountability happen before exposure becomes persistent.

Threat narrative

Attacker objective: Use exposed Bedrock API keys to gain unauthorized access to generative AI services for misuse, leakage, or cost amplification.

1. Entry occurs when a Bedrock API key is created and then copied into code, logs, or a pipeline outside governed storage.
2. Credential access follows when the exposed key is recovered from one of those locations or reused from an unmanaged development workflow.
3. Escalation happens when the stolen key is used to call Bedrock services directly and invoke model access at scale without IAM oversight.
4. Impact is unauthorized model usage, information disclosure, and resource misuse that persists until the key is found and revoked.

Breaches seen in the wild

• OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

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

NHI Mgmt Group analysis

Bedrock API keys turn GenAI access into a non-human identity governance issue. AWS has introduced a credential class that behaves like a machine identity, not a user session, so the governing question moves from authentication convenience to lifecycle control. The practical implication is that organisations must extend NHI inventory, ownership, and revocation logic to GenAI access paths.

Long-lived Bedrock keys create trust debt, not just convenience. Short-term keys compress exposure, but the option for keys with no expiration creates a standing secret that can survive well beyond the reason it was issued. That is the same structural weakness seen in other unmanaged machine credentials. Practitioners should treat no-expiration keys as a governance exception, not a default operating mode.

Identity visibility fails when the credential can live in code and collaboration tools. The article is explicit that keys can be hardcoded into repositories, logs, and pipelines, which means IAM alone does not see the full lifecycle. The named concept here is GenAI credential shadowing: a state where model access exists outside the authoritative identity record. Teams need to recognise that shadowed keys are already part of the attack surface.

Attribution becomes a control, not just an incident-response convenience. If the token reveals key naming details, that metadata can help teams trace ownership and speed containment. But attribution only matters when paired with revocation discipline and clear operational responsibility. The implication is that ownership mapping must be built into NHI governance for AI services from day one.

Agentic AI adoption is widening the NHI perimeter faster than traditional IAM models can absorb. Bedrock API keys are one sign that model access is no longer a special-case engineering problem. It is becoming a repeatable identity pattern with its own governance burden. Security teams should assume more AI services will follow this path and design for credential sprawl now.

From our research library:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: API Key Management Guide

What this signals

GenAI credential shadowing: model access now behaves like any other hidden machine identity when teams can issue keys faster than they can inventory them. The governance question is no longer whether a model can be reached, but whether every key that can reach it is owned, expired, and revocable before it becomes persistent risk.

Short-lived credentials help compress exposure, but they do not solve the larger lifecycle problem if teams still allow long-lived keys, hardcoded secrets, and orphaned ownership. Security programmes need a review path that treats model access as part of the broader NHI estate, not as an AI exception.

For practitioners

• Classify Bedrock API keys as governed NHI credentials Add Bedrock-issued credentials to the same inventory, ownership, and review process used for service accounts and API keys so they do not sit outside the identity estate.
• Prefer short-lived keys for production use Use the shortest viable credential lifetime for model access and reserve longer-lived keys only for tightly controlled exceptions with explicit justification.
• Block hardcoding and pipeline leakage Scan repositories, logs, CI/CD systems, and collaboration tools for embedded Bedrock keys and remove them from uncontrolled storage paths.
• Require explicit expiration on every long-term key Set a documented expiry on any long-term Bedrock key and review renewal before the key becomes a standing secret with no lifecycle owner.
• Tie key ownership to detection and revocation Use attribution data to route detected Bedrock keys to a named owner or team, then revoke anything that lacks an approved business use.

Key takeaways

• Bedrock API keys introduce a machine-identity control problem because they move GenAI access outside the normal human-login model.
• The most dangerous condition is not the existence of the key itself but unmanaged lifetime, unclear ownership, and uncontrolled spread into code and pipelines.
• The practical response is to govern Bedrock credentials as NHIs, with discovery, expiry, rotation, and revocation tied to identity ownership.

Key terms

• Amazon Bedrock API Key: A Bedrock API key is a bearer credential used to access Amazon Bedrock services without a traditional interactive login flow. In this context, the key is tied to an AWS IAM user, so its effective power comes from that user’s permissions and lifetime controls.
• Long-Lived Secret: A long-lived secret is a credential, token, API key, or certificate that remains valid for an extended period without frequent renewal. In NHI environments, it creates durable exposure because one leaked secret can keep granting access long after the original use case has changed.
• Credential Shadowing: Credential shadowing is the state where a secret or connector credential continues to work while sitting outside the normal ownership, review, or rotation process. It creates hidden operational trust. In identity programmes, the risk is not just exposure, but the loss of clear governance over an active credential.
• Lifecycle Control: Lifecycle control is the set of processes that govern access from onboarding through change and removal. In identity programmes, it ensures that provisioning, review, and offboarding stay aligned as applications and permissions evolve. A connector that cannot support lifecycle control may sync data, but it does not fully govern access.

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 building or maturing an IAM programme, it is worth exploring.