Detecting threats before an email reaches an inbox creates a practical tension: deeper investigation takes time and compute. When AI agents perform that investigation, deciding how much to analyze goes hand in hand with deciding where their code runs.

Abnormal AI’s case study, published on September 14, 2026, offers a useful design example. The company uses Amazon Bedrock AgentCore Code Interpreter as a temporary computation environment for agents supporting email threat detection.

Why does this small workspace help a large detection system? Following the routing decisions, access permissions, and session boundaries shows where computation can fit into production operations.

Three detection tiers reserve agents for difficult messages

Abnormal AI passes messages to the next tier when the preceding tier lacks sufficient confidence. The published daily volumes describe progressively smaller workloads.

Tier	Main processing	Daily scale
Tier 1	Heuristics, small models, and lightweight classifiers	Billions
Tier 2	Deep learning and machine learning for behavioral signals	Millions
Tier 3	Inline agents using Code Interpreter	Tens of thousands

Agents handle the hardest cases. They receive threat intelligence, dynamically write analysis scripts, and make determinations in the context of a behavioral model. These are customer-reported workload figures, rather than a performance guarantee for Code Interpreter itself. Abnormal AI case study

This routing makes the volume reaching later tiers a necessary input to capacity planning. For a similar deployment, a useful starting point is to measure the share of messages sent to agents and the additional waiting time at that stage.

Code Interpreter adds computation to language-based decisions

Code Interpreter is a managed environment that executes agent-generated code and returns results. It supports Python, JavaScript, and TypeScript for tasks such as aggregating and transforming data. Official Code Interpreter guide

For example, producing a natural-language count does not establish that a counting operation ran over the input data. Executing code supplies a result or an error that can inform the next decision. Whether the input and counting criteria were appropriate still requires validation.

A session is the execution unit. Each session uses a dedicated microVM with isolated CPU, memory, and filesystem resources. State can support successive computations within the session, making it a workspace for the agent. Session isolation specification

The ability to run a calculation and the decision to accept its result are separate design questions. Once an execution environment exists, its inputs and access permissions need to be defined.

Design Sandbox networking together with S3 permissions

Abnormal AI describes choosing a configuration without outbound access to prevent internet exfiltration and reduce external influences during execution. It also controls which data enters the environment and which writes are permitted. That description concerns its own deployment.

The current network configuration documentation says Sandbox mode can access Amazon S3 for data operations. Public mode provides public internet access, while VPC mode connects to resources in a configured VPC.

The Sandbox label therefore does not establish that every data path is closed. Deployment design needs to specify the execution role’s S3 access and permitted write destinations alongside the network mode. Networking and authorization jointly determine where data can move.

Restricting communication also does not automatically prevent incorrect analysis caused by prompt injection. Isolation constrains what executing code can do; validating the resulting decision remains necessary.

Split long analyses at session deadlines

Alongside real-time classification, Abnormal AI operates a batch agent that analyzes signals such as misclassifications to improve earlier detection stages. Its design includes running long model-training operations externally and using Code Interpreter before and after them.

The duration of that overall workflow differs from the lifetime of one session. The sessionTimeoutSeconds parameter defaults to 900 seconds and allows up to 28,800 seconds. The deadline applies even while activity continues; it is not an idle timeout refreshed by each operation. StartCodeInterpreterSession API reference

Long workflows therefore need a way to export the state required for resumption. Writing a local file within a session alone does not establish that a new session can use it after termination. Define the storage destination and restoration procedure, then feed external processing results into the next computation.

An execution environment ending also differs from the retention period for associated data. The official session management guide additionally lists a 30-day TTL for session data. A sensitive-data retention policy cannot assume that every associated record disappears immediately upon session termination.

Evaluate decision quality alongside runtime cost

CloudWatch metrics expose session counts, request latency, throttling, and errors. Execution stdout and stderr need to be handled from individual invocation outputs; the dedicated observability guide says execution console logs are not available in CloudWatch. Code Interpreter observability documentation

Session usage also affects cost. The current pricing explanation describes per-second billing based on actual CPU consumption and peak memory consumed up to that second. Memory billing must be considered separately even when waiting consumes no CPU, giving session shutdown a practical role in cost control.

For a deployment evaluation, track the number of cases routed to agents, misclassifications, and total decision time over the same evaluation period as infrastructure latency and errors. This is a proposed evaluation approach. The case study does not establish an accuracy improvement, latency distribution, or cost per message.

The answer to the opening question is to create room for computation on difficult cases while defining its operational boundaries. Tiered routing limits the workload, networking and permissions define data access, and session deadlines divide the work into manageable units. Measuring quality and cost across those boundaries turns an agent’s ability to compute into an assessable production design.

Source

• Title: Abnormal AI: Amazon Bedrock AgentCore for agentic email security at scale
• URL: https://aws.amazon.com/blogs/machine-learning/abnormal-ai-amazon-bedrock-agentcore-for-agentic-email-security-at-scale/