4 Ways to Secure Bedrock Agent-Initiated Actions with Teleport

AI Agents are Everywhere Already

AI agents powered by Amazon Bedrock are playing an increasingly central role in cloud operations. These agents can interact directly with core AWS services like S3, Lambda, RDS, and EC2 to perform tasks such as data retrieval, automation orchestration, and resource provisioning.

Many teams rely on the Model Context Protocol (MCP) to structure agent behavior and convert natural language into actionable commands. But here’s the catch: MCP doesn’t care who makes the request or whether it should happen in the first place. It’s just the messenger, and without guardrails, you risk unauthorized access to sensitive data by users or bots.

In this blog, we’ll show how Teleport enables secure identity, policy enforcement, and auditing for agent-initiated infrastructure actions using MCP.

Any Unmanaged Access is Risky, Human or Not

If MCP servers and agents share the same admin credentials, there’s no way to distinguish one from the other — and no way to limit what they can or cannot do. To make matters worse, these credentials don’t rotate or expire unless someone intervenes manually.

What is considered standard security hygiene for humans becomes difficult or, in many cases, impossible to properly enforce for agents. For example, revoking access after misfired tasks, or identifying who or what touched production data last Tuesday morning.

How to Secure Agentic AI and Embrace Automation

The secret to retaining the flexibility of MCP and Bedrock (without compounding security debt) starts with identity. In this context, “identity” refers to assigning unique identifiers to each AI agent and server within the system. This allows for precise control and auditing of their actions.

Teleport plays a crucial role in securing MCP-based systems. It achieves this by registering each MCP server with a unique identity using AWS IAM roles and x.509 certificates. This process enhances security and builds confidence in the system’s robustness.

When an AI agent starts a task, the MCP server sends a request to Teleport with the context, including the agent ID, target resource, and task description. Teleport verifies the request against policy and, if approved, issues a short-lived certificate for that session. This ensures dynamic, per-task access for agents with full audit logging using the same security framework as for humans and machines (such as Git runners or CI/CD automation).

This ensures all agent activity follows the appropriate guardrails. Actions are transparent and fully traceable to a specific agent identity. Let’s examine four ways to apply this model via Bedrock across common AWS services.

1. Safely invoking Lambda functions with support agents

A Bedrock-powered support agent must trigger AWS Lambda functions to perform support tasks, such as password resets and credit issuance. Wide MCP server permissions allow this agent to invoke any Lambda function, including those outside of the support function.

Steps to implement

1. Define a policy in Teleport that allows access to only specific Lambda ARNs used by the support agent.
2. Register the MCP server with Teleport and associate it with the correct identity and permissions.
3. When the agent sends a task request (e.g., reset password), the MCP server includes metadata and calls Teleport to request access.
4. Teleport verifies the request and issues a short-lived token, valid only for the approved Lambda function.

2. Just-in-time EC2 access for remediation agents

An incident response agent must connect to multiple EC2 instances to perform diagnostics or implement fixes. This agent requires secure, temporary access to production instances tagged for remediation only.

Allowing broad EC2 access can increase the risk of AI overreach, especially if the agent can access non-production or nearby production systems beyond its designated role.

Steps to implement

1. Define a Teleport role that provides a clear and enforceable access policy, allowing access only to EC2 nodes with specific tags (e.g., env=prod, purpose=remediation).
2. Enroll the MCP server in Teleport so that it can request access based on the agent task context.
3. When a remediation task starts, the MCP server, which acts as a gateway for agent requests, sends a request to Teleport with details such as the agent ID and target node labels. The MCP server mediates access requests, ensuring they comply with policy.
4. Teleport checks the policy, approves the session, and enables temporary access via AWS Systems Manager.

Beyond MCP and Bedrock, Teleport also extends consistent just-in-time access and least privilege enforcement across AWS. Read our latest blog to learn how to apply just-in-time access to AWS resources to accelerate engineering velocity.

3. Controlled S3 access for AI training pipelines

An agent is used to prepare datasets for model training, which requires read-only access to specific S3 paths. Without controlled access, the MCP server may use long-lived S3 credentials that allow the agent to explore or modify unrelated data.

Steps to implement

1. Create a policy in Teleport that allows access only to the intended S3 prefix (e.g., s3://ml-datasets/project-x/raw/) and restricts the agent to the s3:GetObject action.
2. Register the MCP server in Teleport, using AWS IAM integration and x.509-based identity.
3. When the agent requests access for a preprocessing task, the MCP server passes the task context to Teleport.
4. If the request aligns with policy, Teleport issues a short-lived, read-only token valid only for the allowed S3 path.

4. Secure RDS access for finance agents

An agent is responsible for generating monthly financial reports by querying data from Amazon RDS. With stock MCP controls, this agent would likely operate using a long-lived credential, exposing the database to unnecessary risk, making it challenging to enforce task-specific access, and preventing reliable attribution of queries to a specific agent or report.

Steps to implement

1. Use Teleport’s AWS integration to register the MCP server and assign it a unique identity using IAM roles and x.509 certificates.
2. Create a Teleport role that allows access only to specific RDS databases (transactions, ledger) under a readonly user, with a short session time-to-live and optional MFA enforcement.
3. When the agent is ready to generate a report, the MCP server submits a session request to Teleport with metadata, such as agent_id=finance.report.001 and task=generate_monthly_summary.
4. Teleport evaluates the request, approves it if it matches policy, and issues a short-lived certificate for the duration of the session.

Why This Matters for AI Innovation

Because AI agents act autonomously, we must treat them in the same manner as we treat human operators. That means providing them with scoped, auditable access instead of broad, persistent permissions.

Teleport makes this possible — and more.

Each access request is evaluated. Each session is separate. Each action is connected to a purpose. This provides platform and security teams with confidence to scale agentic automation while maintaining control and visibility.

Ready to Secure AI Agents with Teleport?

Learn more about Teleport for securing AI infrastructure, or continue exploring how Teleport secures and simplifies AWS.

Teleport for AI
Get a Demo