A Bedrock-connected service identity is a non-human identity used by applications or workloads to invoke Amazon Bedrock and related cloud resources. Its permissions determine which data sources it can reach, which outputs it can store, and how much of the AI workflow it can influence.
Expanded Definition
A Bedrock-connected service identity is the NHI that lets a workload, application, or automation layer call Amazon Bedrock and any adjacent data or storage services it needs to complete an AI task. In practice, it is the credentialed execution path for model invocation, retrieval, logging, and output handling.
Definitions vary across vendors because some teams treat this as a generic cloud service account while others separate the Bedrock caller from the downstream identities used for vector stores, object storage, or eventing. That distinction matters because an AI workflow often spans multiple permissions domains, not just one API key or role. For broader NHI lifecycle guidance, the Ultimate Guide to NHIs explains why governance must follow the identity, not the workload label, and NIST Cybersecurity Framework 2.0 reinforces that access control and continuous monitoring are foundational.
The most common misapplication is giving the Bedrock-connected identity broad read access to source systems and broad write access to output repositories, which occurs when platform teams optimise for fast integration instead of explicit entitlement boundaries.
Examples and Use Cases
Implementing a Bedrock-connected service identity rigorously often introduces more permission design and review overhead, requiring organisations to weigh deployment speed against tighter control of data access and model outputs.
- A retrieval-augmented generation app uses a dedicated identity to read approved documents from S3, invoke Bedrock, and write responses to a governed bucket.
- An internal support agent is limited to one Bedrock model and one ticketing integration, so a compromise cannot fan out into finance, HR, or source-code systems.
- A data enrichment pipeline uses separate identities for embedding generation, vector database updates, and audit logging to preserve least privilege and traceability.
- A cloud operations assistant can call Bedrock but cannot alter IAM, because the identity is scoped to inference and logging only, not administrative actions.
These patterns are easier to defend when the identity is treated as part of the NHI lifecycle, not as a temporary integration detail. The breach lessons in 52 NHI Breaches Analysis and the control lessons in Top 10 NHI Issues show how quickly poorly scoped machine identities become escalation paths. For architecture alignment, NIST Cybersecurity Framework 2.0 is the most useful external baseline for structuring access, logging, and recovery.
Why It Matters in NHI Security
Bedrock-connected service identities become high-value targets because they sit at the junction of secrets, data access, and AI execution authority. If the identity is overprivileged, an attacker can steer prompts, exfiltrate retrieved content, or persist malicious outputs into downstream systems. If it is under-governed, defenders may not know which applications are invoking Bedrock, which data sources are exposed, or which outputs are allowed to leave the workflow.
This is where NHI visibility becomes decisive. NHI Mgmt Group reports that only Ultimate Guide to NHIs says only 5.7% of organisations have full visibility into their service accounts, which helps explain why AI-connected service identities are often discovered only after an incident. For teams building agentic or model-connected workflows, the question is rarely whether the identity exists. The real issue is whether it is bounded by Zero Trust principles and whether its permissions match the actual task surface, including retrieval, storage, and tool use. That is why the NHI incidents discussed in Cisco DevHub NHI breach and AI LLM hijack breach remain relevant as cautionary examples.
Organisations typically encounter the operational impact only after a prompt injection, data leak, or unexpected model action, at which point the Bedrock-connected service identity becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers excessive permissions and secret exposure for machine identities. |
| NIST CSF 2.0 | PR.AC-4 | Addresses access control for systems and services using this identity. |
| NIST Zero Trust (SP 800-207) | JIT access | Zero Trust requires explicit, contextual access for service identities. |
Scope the Bedrock-connected identity to least privilege and review its secrets and entitlements regularly.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
