Bedrock agent actions need scoped identity, not shared credentials

At a glance

What this is: This is a Teleport analysis of how Bedrock agent-initiated AWS actions become risky when MCP requests run through shared credentials instead of unique, short-lived identities.

Why it matters: IAM, PAM and NHI teams need to treat agent requests as distinct sessions so they can enforce least privilege, audit origin, and prevent broad access from becoming invisible overreach.

👉 Read Teleport's analysis of scoped identity for Bedrock agent actions

Context

Bedrock agents change the access model because they can act directly on cloud services rather than simply assist a human operator. That creates an identity and governance problem: the system must know which agent requested an action, what it was authorised to touch, and how long that permission should exist.

The failure mode is not automation by itself. It is shared credentials, persistent access, and weak attribution in a workflow where requests are translated into infrastructure actions at runtime. For IAM and NHI programmes, that means the governance boundary moves from user login to per-task authorisation and session control.

Key questions

Q: What breaks when Bedrock agents use shared credentials for cloud actions?

A: Shared credentials remove the identity boundary that tells you which agent requested an action, so authorisation, logging and accountability all collapse into one indistinct service account. In practice, that makes scope control impossible to prove and turns every task into a potential overreach event.

Q: Why do short-lived sessions matter for agent-initiated infrastructure actions?

A: They ensure the agent receives access only for the specific task in progress, which prevents standing privilege from becoming a permanent route into cloud services. This is the difference between controlled execution and an access model that outlives the work it was meant to support.

Q: How can security teams tell if agent privilege is actually constrained?

A: Look for per-call token exchange, audience binding, and an audit record that includes both the human subject and the acting agent. If the same bearer token survives across multiple calls or services, privilege is still standing rather than task-scoped, and the control is not doing its job.

Q: What should security teams do when an AI agent touches multiple AWS services?

A: Treat each service as a separate authorisation decision rather than one shared privilege set. Lambda, EC2, S3 and RDS have different risk profiles, so the agent should receive only the narrowest permission set needed for the task and nothing broader.

Technical breakdown

Why shared credentials break agent identity traceability

Shared admin credentials collapse the distinction between a requesting agent, the MCP server relaying the request, and the resource being touched. When multiple actors use the same credential, logging can show that an action happened, but not which identity initiated it or whether the request aligned with the intended task. That makes policy enforcement, incident review, and blast-radius control depend on assumptions that the identity layer can no longer prove. In an NHI model, a credential is not just an authenticator; it is the boundary that links authority to a specific machine or agent subject. Once that boundary is shared, attribution weakens and access scope becomes difficult to reason about.

Practical implication: assign each agent and MCP server a unique identity so requests can be authorised and audited per actor, not per shared secret.

How short-lived sessions constrain Bedrock and MCP actions

Teleport's model uses request context, policy checks, and short-lived certificates to turn an agent task into a bounded session. The important mechanism is not the certificate itself, but the fact that access is issued only after the request is evaluated against identity, target resource, and purpose. That shifts control from standing privilege to just-in-time authorisation. For cloud operations, this matters because Lambda invocations, EC2 access, S3 reads, and RDS queries are not equivalent permissions. Each action path needs a separate policy boundary if you want to keep a support task, remediation task, training job, or finance query from expanding into unrelated access.

Practical implication: scope agent sessions to one task, one resource class, and one time window, then revoke access automatically when the task ends.

Why Bedrock workflows need policy at request time, not after the fact

MCP structures natural language into commands, but it does not decide whether the request should be allowed. That distinction matters because an agent can generate a valid-looking action that is still out of scope for the actor performing it. Request-time policy evaluation prevents the access decision from being deferred until after the action has already been issued. In practical terms, the control is closer to entitlement issuance than monitoring. Once access is granted broadly, audit logs may help explain what happened, but they do not prevent overreach. The architecture therefore needs pre-execution authorisation tied to agent identity, task context, and resource constraints.

Practical implication: move approval logic in front of execution and verify agent intent, target resource, and policy fit before any cloud action is permitted.

Threat narrative

Attacker objective: The objective is to gain indistinguishable, durable access to cloud resources so agent-initiated actions cannot be reliably constrained or traced.

1. Entry occurs when a Bedrock agent or MCP server submits a valid-looking infrastructure request that is accepted because the platform trusts the shared credential behind it.
2. Credential abuse follows when the same admin identity can reach multiple AWS services, including Lambda, EC2, S3 and RDS, without a unique session boundary.
3. Escalation happens when long-lived access lets the request extend beyond the original task and touch unrelated resources or production data.
4. Impact is loss of attribution, overbroad access, and the inability to prove which agent touched which system or data set.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

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

NHI Mgmt Group analysis

Scoped identity is the control plane for agentic cloud action. Bedrock agents that trigger infrastructure changes are not just automation jobs; they are identity subjects that need a verifiable boundary between request, approval, and execution. Shared credentials destroy that boundary because the platform can no longer prove who asked for what. The practitioner implication is simple: identity must be attached to the action, not left behind in a shared service account.

Agentic access invalidates the assumption that standing privilege is reviewable after use. Access review processes were designed for access that persists long enough to be certified, recertified, and revoked. A Bedrock task can request, execute, and complete within the same short session, which means the governance event occurs at issuance time, not in the next review cycle. Practitioners need to rethink whether their current approval model can even observe the privilege before it disappears.

Identity blast radius is the right concept for Bedrock governance. The critical question is not whether an agent can automate work, but how far a single agent identity can move across Lambda, EC2, S3 and RDS before control boundaries fail. A shared credential turns a narrow task into a broad trust zone, which makes one request look like every other request. The practical conclusion is that scope, purpose and resource class must be enforced as separate limits.

MCP is a transport for intent, not a substitute for authorisation. Translating language into commands does not answer whether the actor should receive access to the target system. That is why agentic governance must sit at the policy layer, where unique identity, time-limited sessions and resource-specific permissions can be evaluated together. The programme implication is that observability without per-task access control is only better logging, not better security.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Security Guide

What this signals

Identity blast radius: The useful governance question is no longer whether an agent can act, but how far one agent identity can reach before policy and audit controls lose precision. For Bedrock-style workflows, that means moving enforcement to request time and treating every action as a scoped entitlement rather than a generic automation event.

When MCP acts as a messenger, access control has to live above it. Otherwise the system can record activity without actually proving that the actor had the right to perform it, which leaves security teams with visibility but not control.

For practitioners

• Define unique identities for each agent and MCP server Register every Bedrock-facing agent and gateway with a distinct identity so requests are attributable to one runtime subject instead of a shared secret.
• Issue short-lived sessions for each task Replace standing access with per-task certificates or tokens that expire when the approved action window closes.
• Scope cloud permissions by resource class Separate Lambda, EC2, S3 and RDS permissions so an agent approved for one service cannot silently operate across the others.
• Log request context with the action Capture agent ID, task description, target resource and approval outcome so later review can reconstruct why access was granted.
• Test revocation after misfired tasks Validate that access can be withdrawn immediately when an agent action is incorrect, redundant or outside the approved workflow.

Key takeaways

• Bedrock agent actions become risky when shared credentials erase the boundary between requester, gateway and target service.
• The issue is not automation in the abstract but whether access is bounded per task, per resource and per session.
• The most effective control is a unique identity plus short-lived, policy-checked access that can be audited at the action level.

Key terms

• Agent-Initiated Action: An agent-initiated action is a task in which software acting on behalf of an AI system directly requests or performs a cloud operation. In governance terms, the important control question is who authorised the request, what identity was used, and whether the action stayed within a bounded session.
• Scoped identity: An identity that is constrained to a specific task, workflow, or service boundary. For AI systems, the concept is essential because it ties access to purpose, limits blast radius, and makes revocation and audit meaningful.
• Short-Lived Attested Credential: A short-lived attested credential is a token or certificate issued for a specific run or workload after the platform verifies who or what is asking. It reduces replay risk because the credential is only useful within a narrow window and is tied to claims that can be checked at runtime.
• Identity Traceability: Identity traceability is the ability to link each action back to a specific identity, authorisation path, and time window. It is essential when humans, service accounts, and AI agents all operate in the same environment and auditors need a defensible record.

What's in the full article

Teleport's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples for scoping Lambda, EC2, S3 and RDS permissions to specific Bedrock agent tasks
• The exact Teleport workflow for issuing short-lived certificates after request-time policy evaluation
• How the article maps agent context, target resource and task description into an auditable access request
• Implementation notes for using AWS IAM roles and x.509 certificates in the MCP access flow

👉 The full Teleport blog shows the per-service examples and short-lived access flow for agent-initiated AWS actions.

Deepen your knowledge

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