A single click can undo weeks of security work, and Abnormal AI is using a managed code runtime to stop it
A successful phishing click often does the hard work for attackers, escalating privileges, moving laterally, and bypassing controls that took weeks to build. Abnormal AI now combines LLM-driven agents with a managed, ephemeral code runtime to run deterministic checks, verify behavior, and make inline blocking decisions on the hardest email cases, stopping them before messages reach users’ inboxes (AWS case study by Aswin Vasudevan, Felipe Lopez, and Shrivu Shankar).
What the managed runtime provides (and why it matters)
- Ephemeral MicroVM sandboxes: According to the AWS case study, the runtime provisions short-lived execution environments (a “compute scratch pad”) with preloaded runtimes such as Python and Node.js. Session TTLs are configurable from 15 minutes (default) up to 8 hours (per the case study).
- File handling and storage: The case study states the interpreter accepts files up to 100 MB via the API; larger datasets are staged through Amazon S3.
- Security and observability: Sandboxes can be configured in a zero-trust/no-egress mode to reduce exfiltration risk, and sessions emit logs to Amazon CloudWatch and AWS CloudTrail for audit and monitoring (per the AWS case study).
- Deterministic execution: The interpreter is the place to run hashes, regexes, tests, replay behaviors, and other non-semantic computations that LLMs alone cannot deterministically produce.
How Abnormal stitches this into production
Abnormal reports a three-tier detection profile in the AWS case study that balances scale, cost, and risk:
- Tier 1, high volume (order of magnitude: 10^9 events/day across customers): lightweight heuristics, small models, and logistic regressions that cheaply discard obvious benign or malicious mail.
- Tier 2, mid-depth (≈10^6/day): behavioral ML and deeper analysis for ambiguous cases.
- Tier 3, agentic inline checks (≈10^4/day): inline agents invoke the managed code interpreter for the hardest decisions where computation, file processing, or reproducible verification are required before taking blocking action.
Parallel to the real-time pipeline, Abnormal runs a batch “analyst agent” that the case study says executes roughly 100 batch jobs per week to ingest misclassifications, draft heuristics, and propose system improvements. These batch jobs may run for 30 minutes or span day-long workflows using intermittent interpreter sessions and filesystem checkpoints (per the case study).
“Pretty much any agent, whether it’s writing code or not, needs a code interpreter sandbox that allows it to actually crunch data and come to answers.”, Shrivu Shankar, VP of AI Strategy, Abnormal AI (quoted in the AWS case study).
Developer automation at scale: what Abnormal reports
Abnormal tells AWS that about 80 percent of their code changes are built using an agent in some way, and roughly 40 percent are produced end-to-end by a background agent (per the AWS case study). Those figures describe Abnormal’s internal measurement of developer automation and indicate a shift from manual authoring toward agent-assisted and agent-authored workflows under programmatic guardrails.
Tradeoffs, governance, and the questions every leader should ask next
Adding an inline interpreter unlocks higher fidelity decisions, but it introduces new tradeoffs leaders must evaluate immediately.
- Latency and cost: MicroVM execution adds decision latency and per-run cost. Abnormal’s approach is selective, running interpreter workloads only for the highest value cases to keep cost predictable. Ask vendors for median and tail latencies plus cost per 10k Tier-3 evaluations (your traffic profile matters).
- Security posture: A zero-trust/no-egress sandbox reduces exfiltration risk, but it’s not a panacea. Request pen-test reports, vendor attestations on network blocking, and evidence that sandbox policy prevents side-channels and supply-chain surprises.
- Auditability and human oversight: Require immutable logs (CloudWatch/CloudTrail), programmatic verifiers (unit tests, linters), and explicit human review gates for production merges. Confirm how agent-authored changes are approved, and what percent are auto-merged versus human-gated.
- Reproducibility and long-running jobs: For batch workflows that outlive a single session TTL, check that the vendor uses filesystem checkpoints or S3 artifacting to persist intermediate state and to enable repeatable runs.
- Compliance and data handling: For regulated data, ask how sensitive email content is encrypted, which subprocessors are involved, and whether the no-egress configuration satisfies SOC2/ISO/HIPAA controls in your audit matrix.
Operational gaps the case study leaves open (so you can ask pointed questions)
- Exact Tier-3 latency, tail percentiles, and cost per evaluation under realistic workloads, the case study provides throughput order-of-magnitude but not detailed SLAs.
- Concurrent MicroVM counts and typical CPU/memory footprints at peak scale when operating across “billions” of messages.
- Quantified detection impact: delta in true positives/false positives attributable specifically to Tier-3 agent runs.
- Detailed incident response plans for misbehaving agents or sandbox compromise (watchdogs, kill switches, rollbacks).
- Precise definitions for metrics cited (for example, what “80% of code changes” measures: commits, PRs, merges, or something else?).
Practical acceptance criteria and a short C-suite checklist
- Ask for measurable SLAs: vendor should provide median and 99th-percentile Tier-3 decision latency under a representative workload and a cost model (e.g., cost per 10k Tier-3 runs).
- Require audit artifacts: CloudWatch/CloudTrail logs, retention policies, and access controls aligned to your compliance needs.
- Demand deployment guardrails: demonstrate programmatic verifiers (unit tests/linting) and human approval gates for any agent-authored production changes.
- Verify sandbox hardening: pen-test reports, no-egress attestations, and artifact versioning for reproducibility of runs that process sensitive data.
- Get failure-mode commitments: documented incident response for agent misbehavior, including rollback mechanisms and monitoring alarms.
When this pattern makes sense, and when it doesn’t
Use agentic inline execution where the marginal accuracy or automation gains on hard cases materially reduce business risk or human load, for example high-value accounts, credential phishing targeted at executives, or complex attachment analysis that benefits from deterministic replay. For bulk filtering and low-value traffic, Tier 1 and Tier 2 approaches remain cheaper and faster.
This is not an all or nothing decision. The practical sweet spot is selective: apply interpreter-backed agents only where their higher cost and complexity are justified by fewer false positives, faster incident resolution, or measurable risk reduction.
Key takeaways, questions you should ask (and honest, concise answers)
- Does Abnormal use a managed code interpreter in production?
Yes. According to an AWS case study authored by Aswin Vasudevan, Felipe Lopez, and Shrivu Shankar, Abnormal runs agent-driven code using Amazon Bedrock AgentCore Code Interpreter to handle inline email threat detection for its hardest cases.
- How does the interpreter fit into their detection architecture?
It’s reserved for Tier 3: a selective inline path in a three-tier pipeline. Tier 1 handles extremely high volume cheap filters, Tier 2 runs deeper ML/behavioral analysis, and Tier 3 invokes the interpreter for tens of thousands/day of the most ambiguous or risky messages (per the AWS case study).
- Are the platform limits and configurations fixed?
The case study cites session TTLs configurable from 15 minutes to 8 hours and API file uploads up to 100 MB, with larger files staged via S3. Treat these as vendor-provided limits and verify them against current AWS documentation for your evaluation.
- Is running generated code safe enough for sensitive email data?
Sandboxing, no-egress configuration, and observability reduce exfiltration and improve reproducibility, but safety depends on implementation: request pen tests, attestations, and compliance artifacts before trusting production traffic.
- Will agentic automation replace engineers?
Abnormal reports heavy agent involvement in code changes (~80% agent-assisted, ~40% end-to-end agent-authored, per the case study). That shifts engineering toward oversight, verification, and orchestration rather than manual drudgery, but human governance remains crucial.
Where this points next
Managed, sandboxed runtimes are becoming standard infrastructure when agents need to act deterministically and safely. For security teams, the decision isn’t whether to use agents, it’s how to insist on the right sandboxes, verifiers, observability, and vendor metrics before letting agents make blocking decisions inline.
(Note: the technical limits, throughput figures, and automation percentages cited above are reported by Abnormal and described in the AWS case study by Aswin Vasudevan, Felipe Lopez, and Shrivu Shankar; verify the current values with the vendor and AWS documentation as you evaluate.)