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

By NHI Mgmt Group Editorial Team Updated October 6, 2026 Domain: Governance, Ownership & Risk

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.

How Bedrock key management should be split between IAM and secrets management

Bedrock key management is not a single-control problem. If the organisation is deciding who can create, attach, or use the key, that is an access governance question. If the organisation is deciding how the credential is stored, rotated, revoked, and exposed to workloads, that is a secrets management question. Treating only one side as “the answer” leaves a practical gap.

The useful way to think about it is to follow the lifecycle of the credential. IAM decides who is allowed to obtain or activate access, while the secrets layer decides how the credential is protected after issuance and how quickly it can be removed or replaced. That split matters most when the key is used by an application, automation, or AI workload rather than a human operator.

For teams building on AWS Bedrock, the control boundary is especially clear when the credential is consumed by services rather than directly typed by users. The concept of non-human identities is useful here because the same key often represents machine-to-machine authority, not just an application setting. In practice, that means the key should be owned, scoped, and reviewed like an access grant, not treated as a static configuration value.

Where IAM ends and secrets management begins

IAM should answer three questions: who can request the key, what can that principal do with it, and under what conditions can it be used. That includes creation rights, attachment rights, usage scope, and any approval or policy checks around production access. If the key can invoke a model, the IAM decision is about whether that invocation is permitted at all.

Secrets management should answer four different questions: where is the key stored, who or what can retrieve it, how often is it rotated, and what happens when it is suspected to be exposed. The most common failure mode is allowing the credential to drift into code, CI/CD output, logs, or shared documentation. The secret sprawl challenge is the right mental model for that failure because the risk is usually not the original issuance, but the uncontrolled copies that follow.

Those two layers should be tied together. A key that is “securely stored” but broadly usable is still dangerous, and a key that is tightly permissioned but widely copied is still operationally weak. The control objective is not to choose one discipline over the other, but to make sure credential lifecycle and model authorisation are governed together.

What good control looks like in practice

Good practice starts with a narrow issuance model. The credential should be created from an approved identity path, bound to a defined workload or role, and limited to the smallest Bedrock scope that still supports the use case. Where possible, prefer short-lived or tightly revocable access paths over keys that live indefinitely in application settings. That is exactly the distinction between static and dynamic credential handling.

Operationally, the secrets layer should be the place where rotation, revocation, and exposure response happen. The fastest way to reduce blast radius is to make replacement routine, not exceptional. A key that cannot be rotated without a deployment emergency is not yet well managed, even if it is technically stored in a vault.

For teams that want a concrete implementation reference, the Secrets Management Guide is useful for the storage and rotation side, while the API Key Management Guide is the cleaner fit when the Bedrock credential behaves like an API key with explicit lifecycle and revocation needs. If the key is tied to broader machine access patterns, the rotation challenges guide helps explain why scale makes manual handling fragile.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CSA Cloud Controls Matrix and NIST SP 800-57 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Bedrock keys are sensitive credentials whose leakage drives misuse risk.
	NHI-05 — Overprivileged NHI	Bedrock credentials should be scoped to the minimum model access needed.
	NHI-07 — Long-Lived Secrets	The key lifecycle and rotation problem is central to Bedrock key management.
Recommendation — Store Bedrock keys outside code and logs, and alert on exposed secrets immediately. Scope Bedrock credentials to the smallest permitted actions and resources. Replace long-lived Bedrock keys with shorter-lived, rotatable credentials where possible.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Bedrock keys require lifecycle control for issuance, rotation, and revocation.
	AC-6 — Least Privilege	Bedrock access should be limited to the minimum allowed model actions.
	SC-12 — Cryptographic Key Establishment and Management	Bedrock key handling depends on secure creation, storage, and replacement of secrets.
Recommendation — Enforce credential lifecycle controls for Bedrock keys, including rotation and revocation. Limit Bedrock key permissions to the minimum required functions and scopes. Manage Bedrock keys through controlled generation, storage, distribution, and replacement.
CSA Cloud Controls Matrix	IAM — Identity & Access Management	The question explicitly splits Bedrock access authority from secret storage.
	DSP — Data Security & Privacy	Secret handling and protection of Bedrock credentials are part of secure data handling.
Recommendation — Use IAM to govern who can create, use, and revoke Bedrock access. Protect Bedrock keys as sensitive data with controlled storage and exposure limits.
NIST SP 800-57	Key Management	The question materially concerns lifecycle handling of a credential used as a key.
Recommendation — Define Bedrock key cryptoperiods, replacement rules, and revocation triggers.

Practitioner Guidance

What to prioritise: Decide whether the Bedrock credential is being managed as an access grant, a stored secret, or both. In most real deployments it is both, so assign IAM ownership for who may use it and secrets ownership for where it is stored and how it is rotated.

What to verify: Confirm that the same credential is not sitting in source code, CI logs, developer notes, or shared environment files. Also verify that revocation can happen without waiting for a full application rewrite or an emergency manual hunt.

Common mistake: Teams often treat the key as a one-time setup item. That is the wrong model, because the risk is not just initial access, it is uncontrolled persistence, copy propagation, and delayed removal after exposure.

Practitioner takeaway: If a Bedrock key can still be used after the original need has changed, the control design is incomplete, regardless of whether the weakness sits in IAM or in secrets handling.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org