The Layered Security of SuperAnalyst
Over the years, AlphaSenseβs architecture has evolved to support the increasingly complex research workflows of our users. SuperAnalyst, our always-on agent, marks the next shift: from finding insights to doing the work those insights make possible.
To do that work, AI agents need access to broader data, context, and tools. That access requires an architecture that gives them the flexibility to solve ambiguous problems with whatever tools and data they need, while also meeting the high security standards of highly regulated industries.
When it comes to what an agent can access, there should be no mystery involved. Digital resources are reachable only because someone built a path to them. If an agent needs one internal service, allow that path. If it needs file storage, add that. If it needs nothing else, leave it sealed. More than a decade of cloud network virtualization technologies and authentication protocols have made these boundaries practical for engineers to define and enforce. So when you hear about agents escaping the sandbox, the first question should be: who cracked the door open?
No single control makes an architecture secure, which is why SuperAnalyst is secured in layers. Running the agent in an isolated compute environment does not help if the network is open. Strong network controls do not help if any caller can claim any identity. Strong authentication does not help if any identity can access any resource.
SuperAnalyst does not rely on any one defense. Each layer covers a different risk, and the layers overlap, so one failure does not become a breach. Our design philosophy is that no layer depends on another. Each has one job and talks to its neighbors through a narrow interface, so we can replace any layer without weakening the rest. The technologies in this post are our choices today. The philosophy is what we hold constant. This post outlines those layers from the inside out: the environment where the agent works, how we control it, who it can claim to be, and what it can reach.
The Isolated Deal Room
Every SuperAnalyst needs a place to work: somewhere to run code, read files, and build deliverables. That place has to be fast to start, cheap to run, and sealed off from every other SuperAnalyst. Those goals pull in different directions.
Our first attempt used containers running on Kubernetes. A container is a lightweight box that holds a program and everything it needs. It worked, but containers on the same server share one Linux kernel, the core of the operating system. Because SuperAnalyst runs code of its own, a single security flaw in that kernel or in the container runtime could be enough to tear down the wall between two SuperAnalysts. We did not find that to be a strong enough boundary.
So we moved to MicroVMs. A virtual machine is a whole simulated computer with its own operating system. A MicroVM is a stripped-down version that starts in a fraction of a second. The MicroVM is built on top of Firecracker, an open-source technology that AWS has spent decades building to run many of their popular managed cloud services. Each Firecracker MicroVM runs its own operating system, so the wall between two instances is much harder to cross than a container wall.
With MicroVMs, you can think of each analystβs session as an isolated deal room: a sealed space where a deal team reviews confidential material. This isolated deal room gives your SuperAnalyst a dedicated walled-off environment to deliver decision-grade work. Now that we have a secure deal room, we still need to determine when to provision it, what materials can go inside it, and which people and systems it can reach.
The Coordinator
A deal room costs money to rent, so thereβs little reason to pay for it when SuperAnalyst is not working. As such, we needed a coordinator to manage when a room should be provisioned, and when it should be released. Temporal, the workflow orchestration platform, plays the role of the coordinator in our architecture by managing the lifecycle of the MicroVMs. For each user entitled to SuperAnalyst, we maintain a long-lived temporal workflow which decides when to provision, suspend and terminate their MicroVM based on usage signals. Releasing the MicroVM saves us on the ever-so-scarce resource of compute, but the analyst's work still needs to be saved. This means separating the room from the files stored in it.
Separating Storage from Compute
Separating storage from compute is an idea infrastructure teams have championed for years because it makes a system more efficient and reliable. The work lives in durable storage, and compute runs only when there is work to do. Between sessions, each workspace can sit in low-cost object storage (Amazon S3), then move into faster storage when a MicroVM actually needs it, when a userβs SuperAnalyst is working. When a node fails, its replacement can recover the workspace from durable storage. As the old DevOps saying goes, servers are cattle, not pets: a node failure should summon a replacement, not interrupt the customer and wake the engineer on call.
While a room is open, we sync the workspace to S3, so every change the agent makes lands in a durable place outside the room. That boundary matters for security as well as reliability. The room is disposable, so we can terminate it at any time, and the record of the analyst's work sits behind its own access controls.
Keeping Each Analystβs Files Separate
The files survive the room. But every new room needs a key. How do we make sure that key opens one analystβs workspace and no one elseβs?
When our Temporal worker (the coordinator) provisions a new MicroVM, it issues a short lived JSON Web Token (JWT). This JWT is like a cryptographically signed temporary identity badge. The MicroVM offers the identity badge to AWS, who verifies it against the public key, and then returns an access token with credentials scoped to that identityβs workspace files in S3.
This is the equivalent of showing the front desk your ID in exchange for a temporary key card. The security officer at the front desk will only give you the key card if the ID you provided is verifiably your ID. This temporary key card can then be used to open only the file cabinet belonging to you.
Thatβs how SuperAnalyst securely picks up its memory, skills, and work from previous sessions.
Beyond the File Cabinet
To reach AlphaSenseβs research tools, requests from the analyst follow a separate, guarded corridor.
Letβs start with where the deal room sits. Each MicroVM lives in an isolated subnet, which is a walled off section of our cloud network. This subnet has no doors to the public internet. It only has local routes, so the only addresses the room can even see are other addresses inside our own network.
Then, we add a second lock. The MicroVMβs security group allows outbound traffic only to an AlphaSense internal proxy. A security group is a firewall rule attached to the room itself.
The subnet controls which paths exist on the map. The security group controls which paths traffic may be sent down. Either one alone keeps the agent in, so one mistake alone does not give the agent a way out.
When SuperAnalyst needs a research tool, its requests go to an AlphaSense internal proxy, the one place the room is allowed to send traffic. The proxy then verifies the identity badge before forwarding it to AlphaSenseβs proprietary research toolset: AlphaSense search, knowledge graph, financial data APIs, and more.
The proxy controls which research tools SuperAnalyst can reach. The next layer determines how it gets exposed to those tools.
From Access to Action
In November 2025, Anthropicβs release of Opus 4.5 marked an inflection point for software engineering. Claude Code and Opus 4.5 had shown how a capable model, connected to tools and a working environment, could do more than answer questions or write boilerplate code. It could carry ambiguous, long-horizon engineering work forward.
That same inflection point is now reaching the rest of knowledge work. The model is the analyst's brain, and a brain alone cannot do the work. It needs hands. The harness provides the hands. They reach into the file cabinet and bring back what the brain needs to catch up to speed (the system prompt, memory, skills, and more). They pick up the tools for the job: a search, a spreadsheet, a data feed. And they reach only for what we allow.
Ask a general harness for a comps table and you get a table. Ask ours and you get a table where every figure links back to a filing. The model is not doing that on its own. In finance, an uncited number is a liability. In our harness, the system issues the source marker for every claim. The model does not type it. The marker follows the claim into chat, reports, decks, and workbooks, and an analyst can trace any figure to a passage in a document. Because the model never writes a source, it cannot invent one.
The same idea runs through the rest of the harness: packaged analyst workflows, purpose-built access to AlphaSense content, and finished deliverables in the formats a research team expects. These rules live in the harness, not the prompt, because a prompt is a request. The harness is enforcement.
The harness gives SuperAnalyst its hands, while the brain that powers it remains flexible.
The Brain Behind the Analyst
Every LLM request goes through a single gateway. This gateway is guarded by another security checkpoint, where user identity is yet again cryptographically verified before the request is forwarded. Behind the gateway, we can route work across models from different labs and inference providers. That lets us match each task to the customerβs priorities for cost, latency, and intelligence. As the frontier moves, we adopt stronger capabilities without rebuilding the rest of the system.
When intelligence matters, we can route a task to an Astra or an Opus 5.x. When speed matters, we can route requests to open-weight models on our Cerebras fleet. Itβs like giving SuperAnalyst a double espresso: same assignment, quicker turnaround. And we put our users in control. If you want to run a workflow on your model of choice, select it, and we will respect that preference.
Layers You Can Replace
Each layer in this post has one job, and talks to its neighbors through a narrow interface. No layer needs to know how the others work inside. This lets us replace one layer and keep the rest. For example, we can swap the room for a different compute substrate. The coordinator still asks for a room and releases it. The storage still holds the files. The identity badge still opens one workspace. The network rules still allow one path out.
This matters because the field is moving fast. A better compute substrate, model, or harness will appear. When it does, we replace one layer and keep the controls on the others.
Putting It All Together
When it comes to security, SuperAnalyst works in a deal room where nothing is assumed. It shows its ID, and we check it. We issue a badge, and the badge opens one room and one file cabinet, nothing more. When it reaches for a research tool, the front desk checks the badge again. This is zero trust: being inside our network is not enough. Every request must prove itself, every time.
No single check carries the weight. Each layer covers a different risk and a different way to address that risk, so one failure does not become a breach. This is also what lets you hand SuperAnalyst real work on your behalf. Together, these layers give it room to carry research through to decision-ready work while keeping its access deliberate and contained.
