It’s safe to close your laptop: Host coding agents on Amazon Bedrock AgentCore

Teams used to keep laptops running because a local machine already had a shell, repository clones, credentials and local services — everything a coding agent needs. That shortcut works for experiments, but it’s fragile and risky at scale: credential leaks, port collisions, accidental writes to shared dev servers, and no audit trail. Amazon Bedrock AgentCore Runtime gives organizations a cloud-native alternative that treats agentic workloads like production services: isolated execution, persistent workspaces, centralized identity, VPC controls, and enterprise observability.

Why laptops became the default — and why that’s a problem

Developers left laptops open because they provide the environment agents expect: a terminal (shell), file system, build tools, and tokens. But that convenience comes with four predictable headaches:

• Secrets leakage: long-lived tokens and SSH keys live in a machine an LLM-powered agent can access.
• State collisions: multiple agents touching the same local DB, ports, or files cause nondeterministic failures.
• Fragile persistence: suspending or closing a laptop interrupts runs; restoring state is manual and error-prone.
• Lack of auditability: actions taken by agents are hard to attribute and trace for compliance.

“The laptop became the default because it had the environment agents need (shell, filesystem, repo, deps, tokens) — not because it was the right place to run them.”

AgentCore addresses these failure modes by design, making it practical to run many AI agents in parallel without the risks that come from turning developer machines into runtime platforms.

What AgentCore Runtime provides (feature → business benefit)

Here are the practical capabilities that change how teams host AI agents, with one-line definitions for technical terms at first use.

• Firecracker microVMs — tiny, fast-boot virtual machines that isolate kernel and filesystem per agent.
  
  Why it matters: Agents run in separate kernels so they can’t stomp on each other’s ports, credentials, or local services.
• Persistent workspace (/mnt/workspace) — a storage mount that persists across microVM restarts (public preview retention: 14 days of inactivity).
  
  Why it matters: Agents can pause and resume work without developers keeping laptops awake.
• Interactive PTY-backed shell — a pseudo-terminal for real interactive sessions (agentcore exec –it).
  
  Why it matters: Developers and debugging tools get the same UX as a local terminal while sessions remain isolated.
• Deterministic command execution (InvokeAgentRuntimeCommand) — non-LLM-driven command runs that stream stdout/stderr over HTTP/2.
  
  Why it matters: Commands execute predictably and are recorded for auditing and troubleshooting.
• VPC-native agents — agents run inside your Virtual Private Cloud (VPC).
  
  Why it matters: Network controls enforce allowed registries, domains and egress policies at the network layer.
• Gateway + Identity (Token Vault, Secrets Manager) — centralized secrets and tool access with support for bot, on-behalf-of, and broker auth patterns.
  
  Why it matters: Credentials live outside agent runtimes and actions are attributable to the triggering user or service.
• Storage mounts (S3 Files, EFS) — up to five mounts per runtime for shared artifacts and large datasets.
  
  Why it matters: Agents exchange artifacts through controlled, auditable storage instead of local folders with hidden secrets.
• Observability & audit (CloudWatch, CloudTrail, X‑Ray, ADOT) — every invocation and trace is logged and instrumented.
  
  Why it matters: Platform teams get forensic detail, performance metrics, and retention controls for compliance and debugging.
• Model-agnostic routing (MCP) — route requests via Bedrock or direct provider APIs; Model Context Protocol (MCP) lets you integrate custom LLM gateways.
  
  Why it matters: You can evaluate Anthropic, OpenAI, Nova, Llama, Mistral, Qwen, Kimi, and others without rewriting platform plumbing.

Quick UX example: an interactive session

Developers can attach to a running agent session using a command like:

agentcore exec –it <session-id> — /bin/bash

That opens a PTY-backed shell to the microVM. Commands you run are isolated to that tiny VM and any outputs are written to /mnt/workspace (or streamed back for immediate review).

Identity and secrets: three practical auth patterns

Embedding long-lived tokens into runtime images is a predictable security hole. AgentCore provides three patterns to mediate tool access — choose based on risk profile and workflow:

• Bot — the agent uses a dedicated service identity with narrowly-scoped permissions. Best for autonomous workflows that need fixed, limited access.
• On-behalf-of — the agent acts using the triggering user’s identity (short-lived tokens). Best where auditability and user-level permissions are required.
• Broker — a gateway service holds credentials and performs sensitive actions; the agent requests the broker to act. Best when you must avoid exposing any credentials to the runtime.

For private repository clones, the practical approach is to keep deploy keys or narrow-scoped personal access tokens (PATs) in Secrets Manager or a Token Vault and fetch them into the session dynamically. Rotate these keys regularly and prefer temporary credentials when possible.

Safe parallelism and predictable networking

Run many agents concurrently without collisions: because each session lives in its own microVM with separate mounts and kernels, you avoid shared-port, shared-file, and shared-db conflicts that plague laptop-hosted agents. Configure network egress rules and DNS inside your VPC to enforce which package registries and external domains agents may reach. That gives security teams a deterministic enforcement point — the network — rather than hoping developers remember to restrict .npm or pip installs.

Observability, auditing, and cost visibility

AgentCore integrates with CloudTrail for audit logs and CloudWatch/X‑Ray (and ADOT/OpenTelemetry) for traces and metrics. That means you can:

• Attribute actions to users or service identities for compliance.
• Trace the lifecycle of an agent run; see what commands executed, what network calls were made, and what artifacts were written.
• Track CPU and rolling peak memory used per session for accurate billing and cost attribution.

Observability makes it practical to detect misbehaving agents (e.g., unexpected network egress, excessive compute) and to build automated guardrails and alerts.

Customer signal and a reality check

Early enterprise adopters are reporting significant gains. Thomson Reuters, for example, reported a roughly 15× productivity improvement for certain agentic workflows at initial launch, according to Danilo Tommasina, Distinguished Engineer. That figure is a customer-reported initial measurement and reflects specific workflows and setup choices; results will vary by use case.

Those headline improvements are real where platform controls reduce friction and developers can reliably automate repetitive engineering tasks. But platform teams must still solve governance, cost modeling, and image supply-chain concerns to make gains sustainable.

Pilot checklist — how to move agent workloads off laptops safely

Run a short pilot to validate security, cost, and UX before scaling. Here’s a pragmatic checklist platform teams and CTOs can use.

• Network & VPC: Create a staging VPC and enforce DNS and egress allowlists for package registries and git remotes.
• Identity & secrets: Store deploy keys and PATs in Secrets Manager / Token Vault. Implement short-lived tokens and a rotation cadence.
• Permissions: Create least-privilege roles for bot, on-behalf-of, and broker patterns and test each pattern with a simple agent run.
• Persistence: Verify /mnt/workspace persists across a microVM restart and that artifacts are accessible from mounted S3 Files or EFS volumes.
• Observability: Instrument a sample run with CloudWatch logs, X‑Ray traces, and CloudTrail entries; verify you can reproduce lifecycle events end-to-end.
• Failure and recovery: Kill a microVM mid-run, restore the session, and confirm work resumes and artifacts remain intact.
• Benchmarks: Use the companion race/bench/watch experiments to compare 2–3 agent harnesses and models (Claude Code, Codex, Kiro, Cursor, OpenCode, Gemini CLI) for latency, cost and test success.
• Cost cap: Set concurrency limits and idle timeouts (default idle = 15 minutes, configurable; microVM lifetime configurable up to 8 hours) and measure CPU/memory at 1, 5, and 20 concurrent sessions.
• Policy: Define credential rotation policy, audit log retention, and approval workflows for agents that act on production resources.

Migration steps for teams using laptop-hosted agents

1. Inventory agent types, dependencies, and secrets currently stored on developer machines.
2. Prioritize low-risk projects for the pilot (non-sensitive repos, internal tools).
3. Choose an auth pattern (bot, on-behalf-of, or broker) and move keys into Secrets Manager / Token Vault.
4. Run the race/bench/watch experiments to select a model/harness tradeoff for your needs.
5. Roll out a developer workflow: how to start sessions, persist work, and attach for debugging (agentcore exec –it).
6. Automate retention, rotation, and monitoring; bake these into the CI/CD pipeline for images and runtime configs.

Cost, lock-in, and residual risks

Moving from a laptop-hosted approach shifts costs from ad-hoc developer time and local compute to measured cloud costs. At low scale a laptop can be cheaper; at scale the cloud offers predictable billing, autoscaling, and consolidated observability. Practical guardrails include concurrency caps, idle timeouts, image caching, and billing alerts.

Model-agnostic routing and direct API support reduce model provider lock-in, but centralizing execution does create a platform dependency. Mitigate this with:

• Model-agnostic interfaces (MCP) and pluggable gateways.
• Image supply-chain controls: signed images, approved registries, and vulnerability scanning.
• Policies for data retention and log export so audit data can be preserved independently.

Residual attack surfaces remain: container images, third-party dependencies, and sidecar collectors. Treat agent hosting like any other critical platform: enforce CI for images, run vulnerability scans, and rotate keys aggressively.

Limitations and when not to move off laptops

AgentCore addresses many of the problems with laptop-hosted agents but it isn’t a silver bullet for every scenario:

• Air-gapped or offline development may still require local machines.
• Extremely latency-sensitive local hardware access (e.g., embedded device debugging) might still need local tooling.
• Regulatory constraints that forbid cloud processing for specific datasets can force local execution.

For quick ad-hoc experiments where developers need to try something in minutes and the risk is low, a laptop is still a pragmatic choice. The point is to migrate repeatable, sensitive, or long-lived agentic workflows to a managed platform.

FAQ

What is Amazon Bedrock AgentCore?

AgentCore Runtime is a cloud service that launches isolated Firecracker microVMs for AI agents, provides persistent workspaces, centralized identity and secrets handling, VPC-native networking, and integrated observability for agent orchestration at scale.

How does AgentCore compare to running agents on a laptop?

AgentCore isolates agents in tiny VMs, centralizes secrets, enforces network policies, and provides audit trails — removing the ad-hoc risks of laptop-hosted sessions while enabling safe parallelism and production controls.

How are secrets protected?

Use AgentCore Identity, Secrets Manager and Token Vault to keep credentials out of runtime images. Choose bot, on-behalf-of, or broker patterns to balance autonomy, auditability, and security.

Can I use different LLM providers?

Yes. The runtime is model-agnostic and can route to Bedrock models (Anthropic, OpenAI, Nova, Llama, Mistral, Qwen, Kimi), direct APIs, or a custom LLM gateway via the Model Context Protocol (MCP).

Next steps and a simple CTA

Start with a focused pilot: lock down a staging VPC, move a couple of non-sensitive agent workflows into AgentCore, instrument traces and audits, and run the companion bench experiments to select model/harness tradeoffs. If helpful, request a ready-to-use pilot checklist I can adapt for your platform team — it includes network configs, identity templates, sample commands, and a cost measurement plan.

Contributors and sources: insights from AWS engineers Kosti Vasilakakis, Abhimanyu Siwach, Evandro Franco, Eashan Kaushik, Mark Roy, and Shreyas Subramanian, and in-field learnings from customers such as Thomson Reuters (Danilo Tommasina), Iberdrola, Cox Automotive, Druva, and Kollab.