AWS Agents Run 14 Days. The Session Is the Only Wall.

If you move an agent workload from AgentCore's microVMs to its new Instances compute type, you are not upgrading your infrastructure. You are trading away a security boundary that AWS used to own, and picking up three obligations your platform team has to write code for. AWS made the Instances compute type generally available on August 6, 2026. Every write-up since has led with the capabilities — 14-day sessions, GPUs, agents collaborating on a shared filesystem, your own Savings Plans. The same documentation set, published the same week, states plainly that agents sharing an instance are not isolated from each other, that the platform does not verify a session ID belongs to the caller, and that the billable EC2 instances behind it all are hidden from your console by default.

None of that is a vulnerability. It is a design, documented in the open. The problem is that it is documented in three places nobody reads before a proof of concept, and the decision it governs — which compute type your agents run on — cannot be changed after a runtime is created.

---

What AWS Actually Shipped on August 6

Instances is a second compute type for AgentCore Runtime that runs your agents on EC2 instances AWS provisions and operates inside your own AWS account. You define the hardware with a capacity provider — a reusable template specifying the operating system, allowed instance types, VPC and subnets, EBS volumes, and the IAM roles used to launch and access the instances. AgentCore handles provisioning, patching, scaling and teardown. The release notes entry confirms Linux on x86_64 and arm64 at launch; the GA announcement lists nine Regions.

The capability delta against the default microVM model is real, and it is why people will move. Maximum session duration goes from 8 hours to 14 days. GPU instance families are supported — g4dn, g5, g6, g6e, gr6, g6f, gr6f, g7e and inf2 — with AgentCore provisioning the drivers, so stock CUDA container images work unmodified. And where a microVM runtime hosts exactly one agent, an Instances session hosts many: invoke a second runtime that shares the same capacity provider with the same runtimeSessionId and that agent lands on the same box, sharing a filesystem with the first. AWS's own launch post by Sébastien Stormacq demonstrates a code-writer agent and a code-reviewer agent passing Python files to each other through that shared filesystem instead of through API calls.

That is a genuinely useful primitive. It is also the exact mechanism that removes the boundary.

The Isolation Unit Changed, and It Got Coarser

Under microVMs, AWS owned the wall. Under Instances, you choose where the wall goes — and if you choose wrong, there is no wall at all.

The Runtime-wide security guidance describes the microVM model in strong terms: "Each user session runs in a dedicated microVM with isolated CPU, memory, and filesystem. Commands and agent code cannot access other customers' workloads or escape the VM boundary. After session completion, the entire microVM is terminated and memory is sanitized."

The Instances security page says something different. "Agents on an instance are not isolated from each other — Multiple agents can run on the same instance and share its filesystem. Agents run on the instance either in containers or, for directly deployed agents, as processes directly on the instance — neither provides a security boundary between workloads on the same instance. All agents that share an instance must be mutually trusted."

Read that last sentence as an operating requirement, not a caveat. Containers are explicitly disclaimed as a boundary here. If you were planning to run a customer-supplied agent, a third-party MCP tool server, or anything that executes model-authored code next to a first-party agent holding production credentials, the session is the only thing separating them — and AWS defines a session as the combination of capacity provider plus session ID, mapping 1:1 to one EC2 instance. Two agents you want isolated must not share a session. That is the whole control.

It compounds with duration. A microVM session tops out at 8 hours and its memory is sanitized on termination. An Instances session runs up to 14 days, and where the capacity provider defines an EBS volume and the runtime mounts it, that volume survives session stops entirely — AgentCore terminates the instance at the limit but retains the volume, then re-attaches it when you invoke with the same session ID. Anything an agent wrote to that filesystem persists across the restart. Anything a compromised agent wrote persists too.

The Session ID Was Never Bound to the Caller

Here is the correction to the story most people will tell about this launch: the session-ownership gap is not new, and it is not specific to Instances. It is the blast radius that changed.

AgentCore authorizes invocations against the agent runtime resource ARN, not against individual sessions. The Instances security documentation states it directly: AgentCore "validates the format of that session ID but does not verify that it belongs to the calling identity," and marks the consequence as Important — "In deployments where a single IAM principal invokes on behalf of multiple end users, the platform does not enforce that a sessionId belongs to the calling user. You are responsible for ensuring your backend passes the correct sessionId per user."

The same constraint already sat in the microVM guidance, in one line: "AgentCore does not enforce session-to-user mappings." It is listed under your responsibilities in the shared responsibility model, alongside agent code security and input validation. So a team that got this wrong was already exposed on microVMs — one authenticated user could supply another user's session ID and route a request into that user's session.

What Instances changes is what a successful cross-routing gets you. On microVMs it reaches a single-tenant sandbox that dies within 8 hours with its memory wiped. On Instances it reaches a long-lived EC2 instance with a persistent EBS volume, possibly co-resident agents, and live credentials — AgentCore "vends execution role credentials to the agents running on the instance and refreshes them periodically," and "any code running on the instance can read the credentials available to it."

AWS names two mitigations and ranks them. Application-level session-to-user binding — treat runtimeSessionId as a server-side value derived from the authenticated user, never accepted from client input — is the minimum. Distinct IAM principals per user or per tenant group is the one AWS calls "the strongest control," because then IAM enforces session scoping rather than your backend. If you have ever shipped a bug where an object ID from a request body was trusted without an ownership check, you already know which of those two survives a rushed sprint.

Your Longest-Running Compute Is Hidden From Your Console

The instances backing your sessions are Amazon EC2 managed instances — the same category EKS Auto Mode, ECS Managed Instances, Lambda and WorkSpaces Core use. AWS's note on the default is short and expensive: "By default, Amazon EC2 hides managed resources for accounts that did not have managed resources before visibility settings became available. For accounts that already had managed resources, Amazon EC2 sets the visibility setting to Visible to preserve existing workflows."

Read that as a fork. If your account already runs EKS Auto Mode or ECS Managed Instances, AgentCore's instances show up in your console. If it does not — a greenfield agent account, a new sandbox, a dedicated workload account, which is exactly how most teams will pilot this — they are hidden, and the setting applies to every IAM principal uniformly — AWS's own page calls the scope Region-wide in a Note and account-wide under Limitations, so check both. Instances, launch templates, EBS volumes and ENIs all disappear from console views and API list operations at once.

AWS is explicit that hiding is cosmetic in the direction that costs you money: "Hidden resources remain fully operational and billable," and "Hiding them from console views does not reduce costs." They stay in your bill and your Cost and Usage Report. What they leave is a gap between what your inventory tooling sees and what you are paying for — and the documentation lists that gap as a feature, citing "prevent false positives in cloud security posture management (CSPM) scanners (for example, Qualys) that flag managed resources as customer misconfigurations." That is a reasonable trade for an EKS node group. It is a different trade for a GPU instance running a 14-day agent session with a persistent volume and vended credentials.

The escape hatches exist and are cheap. aws ec2 get-managed-resource-visibility tells you where you stand; modify-managed-resource-visibility flips it. describe-instances --filters "Name=operator.managed,Values=true" enumerates them, and a direct query by instance ID returns a hidden resource regardless of the setting. You just have to know to run them.

The Money Is Not Where Your FinOps Model Expects It

Instances bills on a completely different axis from microVMs, and the difference is idle time.

microVMs are consumption-based and billed by AgentCore — $0.0895 per vCPU-hour and $0.00945 per GB-hour on active resource use. Instances are EC2 in your account plus a management fee charged as a percentage of the EC2 On-Demand price, per instance-hour: 12% in AWS's own worked example, and a reduced 7.8% for G-series GPU families including Graviton-based gr6. Your Savings Plans, Reserved Instances and ODCRs apply to the EC2 portion; the management fee does not move.

The headline percentage is not the risk. Duration is. AWS's pricing example runs 1,000 monthly jobs of 3 hours each on a c7g.2xlarge at $0.289/hour On-Demand, landing at roughly $971 a month. Take that same instance to the documented maximum — 336 hours — and one session costs about $109 before you have run a second. A hundred concurrent long-lived tenant sessions is a five-figure monthly line item generated by a runtimeSessionId your application chose, on instances your console does not list by default.

There are stop levers, and they are less settled than they look. AgentCore Runtime's lifecycle settings define an idleRuntimeSessionTimeout defaulting to 15 minutes, StopRuntimeSession terminates a session on demand, and the management fee is billed only "from provisioning (boot) until the instance is stopped or terminated." But both lifecycle values are capped at 28,800 seconds — exactly the microVM's 8-hour ceiling — and the page defining them describes microVMs throughout. Nothing published states how a 15-minute idle default maps onto a session advertised at 14 days. Until it does, treat session lifecycle as application logic you own: call StopRuntimeSession yourself rather than assume a timer will, the same way you own GPU utilization on any other fleet.

---

The Case for Instances Anyway

The strongest version of the other side is straightforward, and it is right for a large class of workloads.

If every agent on a capacity provider is first-party code you wrote, reviewed and deployed, "mutually trusted" is a description of your environment rather than a constraint on it — and you gain a shared filesystem, 14-day continuity, GPU access without driver plumbing, and your negotiated EC2 rates instead of a platform markup. The instances genuinely do run in your account, under your SCPs, permission boundaries and VPC controls, with CloudTrail and VPC Flow Logs you already collect. EBS volumes can be encrypted with a customer managed KMS key you rotate and audit, which is more key control than the serverless path offers. And AWS has published a real multi-tenancy blueprint — the pool-model pattern from June 23, 2026, which binds tenant context through JWT claims and a token-vending pattern that assumes a role with session tags for attribute-based access control.

What that blueprint does not do is remove the obligation. It shows you how to meet it. The failure mode here is not a team that reads these documents and decides Instances fits. It is a team that reads a launch summary — independent coverage on August 10 described the capabilities and the pricing shape without a single security or governance caveat — and treats a new compute type as a checkbox on an existing runtime.

What to Do

This Week:

1. Run aws ec2 get-managed-resource-visibility in every account and Region where anyone might pilot AgentCore. If it returns hidden, decide deliberately whether to flip it — and tell your CSPM and asset-inventory owners either way, because the setting applies to all principals uniformly.
2. Inventory what already exists: aws ec2 describe-instances --filters "Name=operator.managed,Values=true". If instances come back that nobody on the call recognizes, you found the gap before the invoice did.
3. Answer one question in writing: does a single IAM principal in your backend invoke agents on behalf of more than one end user? If yes, you are in the shared-principal case AWS flags, and runtimeSessionId must be derived server-side from the authenticated user today — on microVMs as much as on Instances.

This Month:

4. Write down the trust set for every capacity provider you plan to create. Any agent that runs model-authored code, executes customer-supplied tools, or comes from a third party gets its own session — not its own container, its own session. Containers are explicitly not a boundary here.
5. Scope the infrastructure role with IAM conditions on specific VPCs, subnets and instance types. It grants AgentCore the ability to launch compute in your account; the console will happily create a default for you.
6. Add a CloudTrail detection for cross-principal session routing. InvokeAgentRuntime records both the authenticated principal and the target sessionId in the same event, which makes "principal A routed to a session created by principal B" a query you can alarm on rather than a theory. Wire it into whatever you already use for agent observability.

Before You Move a Tenant-Facing Workload:

7. Price the per-tenant IAM principal path properly. AWS calls it the strongest control, and it is the only option where IAM — not your backend — enforces which sessions a caller can reach. If your identity architecture cannot support it, say so explicitly in the design doc and name the compensating control.
8. Confirm the capacity provider configuration before you create it. Only the description is editable afterward; everything else requires duplicating the provider, and deleting one stops and deletes all its sessions and their persistent storage.

The Bottom Line

Every cloud platform eventually offers you the same bargain: more control and better economics, in exchange for taking back responsibilities the managed tier was quietly handling. It happened with Lambda to Fargate to EC2, with RDS to self-managed Postgres, with EKS Auto Mode to self-managed node groups. Nobody was tricked. Teams just kept reading the capability table and skipping the responsibility table, because the capability table is the one in the launch post.

AgentCore Instances is that bargain applied to agent runtimes, and the documentation is unusually honest about it — the phrase "you are responsible" appears without hedging, and "all agents that share an instance must be mutually trusted" is as clear a statement of a security model as any vendor writes. The 14-day session is the feature. The 14-day blast radius is the price. Both are in the same document, and only one of them made the launch post.

Pick your isolation unit on purpose. You cannot change the compute type later — and Amazon Bedrock will not ask you again.

Continue Reading

• One Agent Escalated Another. Every Call Was Authorized.
• AWS Kills Q Business, Kendra, Bedrock Agents: 90-Day Plan
• AWS Agent Payments: 200ms USDC Beats Card Networks
• AI Agents Have Admin Access. 57% of Firms Aren't Ready.
• Your AI Agents Need Identity Management—Before They Need You
• Shadow AI Agents: 82% of Enterprises Have Unknown Agents
• Best AI Agent Monitoring: Langfuse, Then a Real Kill Switch
• Why 54% Had AI Agent Incidents. 86% of GPUs Run Half-Empty.