Overview

HUB International is a top-five global insurance broker headquartered in Chicago. Its developers were already working with Claude Code, and the company had picked Amazon Bedrock AgentCore as the platform for its AI build. What it didn't have was a way to run a coding agent that its CISO could stand behind: one that held no credentials of its own, reached only the tools a developer was entitled to, and left a named person behind every action.

In September 2026, HUB's TechOps organization, AWS, and Act Security spent two days in one conference room and built exactly that. The environment went from requirements to architecture to a working deployment inside HUB's own AWS account, under HUB's normal change-control process, with security policies deployed and validated.

Opportunity | A pilot that couldn't grow

A coding agent running on a developer's laptop inherits the developer's entire ambient authority: cached cloud credentials, source-control tokens, ticketing sessions, VPN reach. It has no identity of its own, so nothing it does can be scoped, attributed or revoked independently of the person running it. That is workable for a handful of early adopters. It is not a model a regulated enterprise can scale, because the control plane for the agent is the laptop, and the laptop was never designed to be one.

That was the problem HUB International ran into. Developers who had tried Claude Code wanted more of it, and HUB's technology organization wanted to move quickly on an AgentCore environment that would give them a proper landing spot in the cloud. Security wanted clarity on credential management before expanding the rollout, while engineering wanted to align on the approach early to avoid changes after launch. So before anything was built, HUB brought in Act Security, whose platform maps and enforces least privilege in cloud environments, and put one question to the team: what does least privilege actually look like for an agent that writes code?

The constraints were real. HUB runs Microsoft Entra as its identity provider, so the authentication flow needed to work with its existing identity setup. Its AWS networking is closed by default, with no internet gateway and interface endpoints only. Every production change goes through a change request approved by three people. And the work was deliberately confined to a dedicated AgentCore account, with the right change controls in place, so the teams could move freely during the workshop without creating risk elsewhere in the environment.

Solution | Two days, hands on keyboard

HUB's cloud and infrastructure team organized an onsite around one design rule that Act brought to the table: the agent holds no credentials. Everything it can reach is registered, evaluated and logged outside the agent's own code, so a prompt-injected session has nothing to steal and nowhere unexpected to go.

In practice, that rule breaks down into a handful of mechanisms, all of them native AWS primitives:

• Login through the corporate identity provider. The developer's CLI runs an OIDC device flow against Entra and stores the token locally. Nobody using the system needs an AWS account. The JWT is checked for issuer, audience and allowed client before any compute exists.
  ‍
• One sandbox per session. AgentCore Runtime provisions an isolated machine for each session: a microVM by default, an EC2 capacity provider for heavier work. The first verified identity owns the session, anyone else is refused. Files live on an encrypted per-session volume, and memory is name-spaced per user with IAM condition keys.
  ‍
• No inbound path. The sandbox accepts no inbound connections. The CLI opens a bidirectional stream through the platform's WebSocket, and SSH and VS Code Remote ride the same connection, so developers keep the terminal and IDE they already use.
  ‍
• A user credential minted per tool call. Every tool call leaves the sandbox through AgentCore Gateway, the only registered path to GitHub, Jira, Confluence and Bitbucket. For each call, AgentCore Identity exchanges the caller's login for that caller's own grant, so GitHub sees the developer, not a service account. Tokens live in the vault and are never written to disk.
  ‍
• Policy at the boundary. A Cedar policy engine evaluates every call at the gateway, out of reach of a prompt injection, and per-caller rate limits double as a kill switch.
  ‍
• Attribution by default. The developer's identity travels with every bootstrap, SSH upgrade and tool call, and CloudTrail records it against a named person.

HUB built the environment on a variety of AWS services, including Amazon Bedrock AgentCore, a set of services for deploying and operating AI agents securely at scale: AgentCore Runtime for the per-session sandboxes, AgentCore Gateway as the single registered path to tools, AgentCore Identity to mint a per-user credential for each call, and AgentCore Memory, namespaced per user. Around it sit AWS CloudTrail for attribution, AWS Organizations service control policies and resource control policies as guardrails on the account, AWS Secrets Manager and AWS KMS for credential and volume encryption, AWS PrivateLink for a closed VPC with interface endpoints only, and Amazon ECR for the hardened sandbox images. The whole stack is deployed as modular Terraform into HUB's own account, so HUB owns every line of it.

The two days were about turning that design into HUB's environment, and the room was built for it: HUB's cloud, network, development and security teams, the AWS account team and solutions architect, and Act's founding engineers.

Day one covered requirements, architecture and the AWS foundation. Act had prepared modular Terraform and a reference implementation ahead of time, and the group reworked it live to fit HUB's closed networking model. When HUB's developer workstations turned out to be Windows VMs that couldn't run a container build, the team pivoted the same afternoon: HUB's own developers built both sandbox images on their Macs and pushed them to HUB's registry. The dedicated AWS account, VPC, network connectivity and cross-account read-only access for Act were all stood up by HUB's own team, inside HUB's change-control rules.

Day two was validation and hardening. Security policies were deployed and tested against the live environment, the deployment model was settled (microVM by default, EC2 for heavier workloads), and Act walked the room through HUB's environment as the platform now sees it, along with the "Adopt AI safely" campaign: the set of controls that keep an AgentCore account tight, from execution-role scoping to guardrails on the account itself, each one an action item HUB can review and apply through its own infrastructure-as-code.
‍

"Two days, hands on keyboard, and we got it done. In two days we went from requirements to architecture to a working environment: AWS foundation stood up, security policies deployed and validated, and a deployment model decided. That's a lot of ground covered in a short window, and it happened because everyone showed up ready to work through hard problems in real time."
‍
Mouncef Elalamy, Senior Director, Cloud and Infrastructure, HUB International

Outcome | A pattern for safe AI adoption, and a way to keep it tight

Two days produced more than an environment. They produced a pattern a regulated business can repeat: decide what must be true before the build, put security and engineering in the same room, use the cloud provider's native controls rather than a bolt-on, and connect a way to verify the result afterwards. The environment left the workshop in HUB's own AWS account, built to HUB's network and change-control standards, and every design decision was made with cloud, network, development and security teams present, so nothing has to be re-argued at rollout.

Using this approach, HUB was able to:

• Stand up a working AgentCore environment, from requirements to validated security policies, in two days
  ‍
• Give coding agents a home that holds no credentials, not AWS, not vendor, not the developer's own, so a prompt-injected session has nothing to steal
  ‍
• Keep developers in the terminal and IDE they already use, with execution moved to an isolated per-session sandbox in the cloud
  ‍
• Attribute every agent action to a named person, through the corporate identity provider and CloudTrail
  ‍
• Meet its own regulatory bar with native AWS controls only: closed networking, per-call authorization at the gateway, organization guardrails, and a build that ran inside its normal change process
  ‍
• Settle the deployment model, microVM by default and EC2 for heavier work, with every team agreeing in the room rather than in a ticket queue later

The part that usually stays open after any build like this is drift. Least privilege in a new environment tends to decay the moment people start using it, and coding agents are heavy users. That is where Act continues. Connected read-only to the account, Act compares configured access against observed access for every runtime and execution role, and proposes the narrowed policy. HUB reviews, HUB applies. Act has no write path into the environment, by design. As HUB onboards developers onto Claude Code in the new environment and extends the private-runtime configuration, the same loop keeps the design honest: what each agent can do stays matched to what it actually does.

About HUB International

HUB International is a top-five global insurance broker headquartered in Chicago, providing property, casualty, risk management, life and health, employee benefits, investment and wealth management products and services.

About Act Security

Act is an action-centric cloud security platform. It maps every access path in a cloud environment, both configured and observed, and turns the gap between the two into policy the customer applies through its own infrastructure-as-code.

‍