A Security Runs in Your Cloud, on Your Models

Autonomous Offensive Security on Your Terms

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

The A platform and your data services run in your cloud account. Model calls go to your provider, and campaigns reach only your in-scope targets. Yellow marks the only flows that reach A.

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

Requirement How A Security meets it
Data stays in your account and region Databases and object storage run as your managed services or inside the cluster. Retention is set per data type.
Data at rest is encrypted with keys you can revoke Databases, volumes, and buckets are encrypted with keys in your own KMS, which you can rotate or revoke at any time.
Secrets stay in your vault Uses the vault you already run, such as HashiCorp Vault or your cloud's secrets manager. Test credentials are resolved only at use and redacted from logs, traces, and prompts.
Secrets never reach the model Secrets are never sent to a model, only to the tools that use them.
Traffic in transit uses your certificates TLS with your own CA certificates, mutual TLS between services, private endpoints, and an IP allowlist.

AI and testing safety

RequirementHow A Security meets it
AI calls go only to approved models, through your gatewayThe model allow list is enforced at deploy time. Calls go through your AI gateway with its own authentication, provider keys never leave the gateway, and chat is screened for prompt injection and secret leaks.
Each test is isolated and held to scopeEvery campaign gets its own sandbox and egress proxy, with default-deny networking, scope checks on every call, and non-root pods under restricted Pod Security.

Platform and operations

RequirementHow A Security meets it
Images are hardened and scannedBuilt on hardened base images, with releases blocked on known CVEs.
Fits the cluster platform you already runWorks with your existing ingress or load balancer, autoscaler, network plugin, and node pools. Nothing internet-facing is created.
Monitoring stays in your environmentMetrics, logs, traces, and dashboards stay in the cluster, with the same alert rules we run for our SaaS. Alerts reach our on-call only through a topic you own.

Network isolation and air-gapped operation

RequirementHow A Security meets it
Installs and runs with no internet accessThe installer carries every chart and infrastructure provider it needs, and images come from your registry mirror. Nothing is downloaded at install or run time.
All outbound traffic goes through your proxy and trusts your CAModel calls, integrations, repository clones, and campaign traffic all leave through your egress proxy, using your CA bundle.
Out-of-band testing stays inside your networkThe callback server that confirms blind vulnerabilities runs inside your boundary, on private IPs and your DNS. No test data goes to a public callback service.

Access and identity

RequirementHow A Security meets it
A Security does not require standing accessYour team can run every install and upgrade from versioned releases. Support sessions happen only when you approve them, and they are time-boxed and logged.
Users sign in through your identity providerSSO through your identity provider, with roles mapped to your workspaces.
No long-lived cloud credentialsEach service has its own cloud role through your cloud's workload identity, and uses short-lived credentials only.

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.

Type of taskExamplesWhat the model needsCalls per engagementModel tier
GuardrailsChecking that every action stays in scope and every result holds up, as the campaign runsFast, consistent, low costVery highSmall
DiscoveryMapping hosts, services, and applications, and what each one exposesTool use, structured output, efficient at volumeHighSmall to mid-tier
ExploitationRunning multi-step attacks against in-scope applications and infrastructureReasoning, tool use, persistence, low refusal rateHighMid-tier to frontier
PlanningPlanning the campaign and each attack pathExtended thinking, planningLowFrontier
ReportingWriting findings, setting severity, and merging related findings into attack chainsWriting quality, calibrated severityLowFrontier

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
How we build an alloy: benchmark every approved model on every type of task, keep the best one for each, and run the mix at about half the cost of using the top model everywhere.

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.

Share this article
About the author
Ofir Assif has spent 12 years building offensive and defensive cybersecurity products. Before joining A Security as a Product Manager, he led engineering teams at Unit 8200 and Hunters, helping build products that protect organizations against evolving cyber threats.