Bring your own cloud (BYOC) and bring your own model (BYOM) are now generally available. The A Security platform runs in your own cloud account, on any major cloud vendor, and every AI call goes to a model you've approved. It's built on our engine, agent harness, and layered guardrails, with no external dependencies, so it runs even in air-gapped environments.
Offensive security testing produces some of the most sensitive data an organization has: working exploits for unpatched vulnerabilities, the credentials and attack paths used to get in, your source code, and proof of which customer data an attacker could reach. For banks, insurers, and other regulated organizations, sending that to a vendor's cloud means third-party risk reviews, data residency questions, and limits on which AI providers may process it. BYOC and BYOM keep the data and the AI processing inside boundaries you already govern.
Proven at one of the world's largest banks
One of the world's largest banks, with hundreds of thousands of employees, uses A Security with BYOC and BYOM. Its security team reviewed A through its AI threat assessment, using our map of every communication path in the platform, and approved the deployment. The bank's engineers then installed the platform in their own environment, running on the bank's approved models.
What it means for your security program
- Your data stays in your account. Findings, evidence, recordings, prompts, logs, and test credentials are stored in your cloud account, in your region.
- Your AI policy applies. A Security uses only the models you approve, through your provider or your own AI gateway. We recommend which approved model fits each task and validate quality before go-live.
- Your controls apply. Your encryption keys, identity provider, secrets store, and network rules.
- Every boundary crossing is documented. We map each flow between your account and A Security, and you control each one.
- You run the same product. BYOC runs the same platform as our SaaS, from the same codebase.
- Infinite scale. The infrastructure is cloud-native and scales automatically, so one deployment can test thousands of servers and applications in parallel. The only limit is the cluster capacity you give it.
- Audited controls. A Security holds SOC 2 and ISO 27001 attestations.
Bring your own cloud

A BYOC deployment is our engine, agent harness, and layered guardrails system, running as cloud-native workloads in your Kubernetes cluster on AWS, Microsoft Azure, Google Cloud, or another cloud on request, plus the data services they use. Every component scales automatically with load, so a single deployment can test thousands of servers and applications in parallel, limited only by the cost quota and capacity you give the cluster.
The tables below list the requirements regulated organizations raise most often in security reviews and RFPs, grouped by topic, with how A Security meets each one. They're worth putting to any vendor that offers BYOC.
Data protection and residency
AI and testing safety
Platform and operations
Network isolation and air-gapped operation
Access and identity
Bring your own model
- The providers you already use. Anthropic, AWS Bedrock, Google Vertex AI, OpenAI, xAI, and more, including their embedding models, called directly or through your own AI gateway.
- Only approved models. You set the list, and A won't deploy if any part of the platform would be left without an approved model.
- The right model for each job. We combine your approved models into an alloy, with each type of task on the model that's best at it, and show you what each choice gains or loses before go-live.
- Tuned to your models and your route. Our agent harness adapts prompts, settings, reasoning effort, and output handling to the models you choose and the provider you reach them through, because the same model can behave differently on two routes. We keep it current as providers update.
- Cost you can plan. Inference runs on your provider contract, and the most expensive models are used only where they change the outcome.
What it means in practice
Bring your own model doesn't mean pointing A Security's autonomous offensive security platform at any model and hoping for the best. Every agent runs through our harness, the layer between the agents and the models. It handles model selection, fallbacks, prompts, and output validation, and it's what makes model choice a configuration setting. A Security runs over 100 agents, and they do very different jobs. Some run thousands of times in a campaign; others make a handful of decisions that shape the whole campaign.
So BYOM works as a recommendation and validation process. You tell us which models you've approved. We recommend which of them each type of task should use, and we validate the result before it goes live.
Bigger isn't automatically better. The question isn't only which model succeeds more often or costs less, but which one behaves the way each agent needs: how long its findings are, how it calibrates severity, how closely it follows guardrails, how many false positives it raises, and how strictly it stays in scope. A model that writes 120 words where the task calls for 70, or wanders past what it was asked to test, can be smarter and still the wrong fit.
Matching models to tasks
We group agents by what they need from a model: how much reasoning a task takes, how much it relies on tools and structured output, and how often it runs. The table shows a few examples from over 100 agents; each one is tuned and benchmarked on its own.
The same grouping keeps cost in balance. High-volume work runs on efficient models, and the most capable and most expensive models handle only the few decisions that shape a whole campaign. Compared with running everything on a frontier model, that roughly halved the cost per test case in our benchmarks, with quality matched on all but one hard case. Inference runs on your own provider contract, at the pricing you've already negotiated.
What each model choice gains and loses
Before a model set goes live, we tell you what each choice gains and what it gives up: findings quality, severity calibration, false positives, guardrail compliance, cost, and runtime, compared with our production baseline. We run the comparison on ARENA, our open-source benchmarking platform, across the agent types that drive results (exploitation, lead generation and scoring, reporting, reproduction, planning, and finding deduplication and merging), plus full end-to-end campaigns. For the bank's deployment we mentioned earlier, that meant hundreds of benchmark runs, measured against multiple targets:
- Quality: at least 90% of our baseline
- Cost: at most 2× our baseline
- Runtime: at most 4× our baseline

The results aren't always what you'd expect. On one discovery agent, a small model made no wrong claims where a larger model made 21, while costing about 97% less. On a hard exploitation case, the frontier model kept going for 58 steps and confirmed the bug, where a mid-tier model stopped at 23. We show you trade-offs like these before you choose.
Changing models or providers later is a configuration change: update the allow list, re-run the benchmarks, and deploy. No code changes are needed. Every model call records which model served it, so results always show exactly which model did what.
Getting started
BYOC and BYOM are generally available now. We start with a session with your platform and security teams to go through the architecture, the communication map, the permissions each service needs, and our SOC 2 and ISO 27001 reports.
Request a demo today.

