omesos
Book an assessment

For security teams

Models for security work. The evidence stays in your account.

Investigating an intrusion means handing a model real payloads, real attacker commands and real credentials. Several hosted models, some of them offered specifically for security work, keep prompts for abuse detection unless you qualify for an exception. If you have promised your clients otherwise, those are not terms you can accept for them. We run open-weight models on instances in your own AWS account, where what is kept is your decision.

Cloud
Yours, in the AWS EU region you choose, for example Frankfurt.
Models
Open-weight models from identifiable publishers, chosen and tested on your own cases. Published and versioned, with licence lineage documented.
Runs on
Dedicated GPU instances in your own AWS account, on the AWS Nitro System. For this work we use no shared model service, so your prompts are not processed outside your account.
Supports
Authorized work, on systems whose owners have permitted it: triage, log and alert analysis, payload and malware explanation, reverse engineering of malware and suspicious samples, detection engineering and report drafting.
Access
A named deployment for a named team in your own account, set up after you confirm its purpose in writing. No shared endpoint and no self-serve access.
Fees
A fixed setup fee, then a monthly operations fee, agreed in writing. AWS bills your usage directly to your own account.
Book an assessmentHow pricing works

01 / What we do

Everything between your analysts and the model

You know the work. We find the models that hold up on it, run them in your account and keep them running, so your analysts stay on cases instead of on an inference stack.

  1. Measurement on your own cases

    Together with you we build a test set from past cases you are permitted to reuse, with live credentials and client identifiers replaced, and run the candidates against it inside your account. We record where each one is accurate, where it is unreliable and where it falls short of the task. You decide on your own results, not a vendor benchmark.

  2. Model selection

    Hundreds of open-weight models exist, and only some are tuned for security work. They differ in reasoning, language, speed and running cost, and new releases arrive every few months. We shortlist for your actual tasks and re-check as the field changes.

  3. Licence lineage, documented

    Many open-weight models are built on another family’s base model. Where that base licence or its acceptable-use policy binds derivatives, its terms can carry through, whatever the derived model’s own page says. We trace lineage per model, note terms that restrict commercial use or security work, and keep a register for your legal team to assess.

  4. Deployment in your account

    Your analysts and tools call a private endpoint on GPU instances in your own account, in the region you choose. Your keys, your network, your logs. Our access is a role you can revoke.

  5. Pinned versions

    The model and the software serving it stay at the versions you approved until you approve a change, and we record the settings each version ran with. When a client questions a finding in last quarter’s report, you can rerun the work on the same configuration.

  6. Operations and upgrades

    Monitoring and capacity, operating-system security patches applied promptly, and model upgrades we test on your test set and switch only after you approve. Business-hours support (CET) through a named contact who knows your setup.

02 / The constraint

Why the question comes up at all

AWS’s documentation says its managed model service keeps no model inputs or outputs by default, and then lists exceptions. As of October 2026, for some listed models every prompt is kept for up to 30 days and prompts flagged by classifiers may be reviewed by AWS staff; for others, flagged prompts are kept for automated review. The list includes models offered specifically for security work. For these models, zero retention is granted per account, to customers judged eligible.

So for those models, keeping nothing is something you apply for, not something you set, and the decision is not yours. We choose open-weight models that are not on that list and run them on instances in your own account, where retention is your setting rather than someone else’s condition of access.

Amazon Bedrock abuse detection

Model catalogue

The open models that matter, running in your cloud.

Open weights mean the whole model runs inside your cloud. Your prompts never reach the company that trained it, wherever it comes from. We test the candidates on your own examples, check each licence for your use, and keep the catalogue current as new releases appear.

  1. DeepSeekDeepSeek
  2. QwenAlibaba
  3. GLMZhipu AI
  4. KimiMoonshot AI
  5. LlamaMeta
  6. MistralMistral AI
  7. GemmaGoogle
  8. gpt-ossOpenAI
  9. and many more

Model names and logos are trademarks of their respective owners. No affiliation or endorsement is implied.

03 / Your own account

Why the account matters more here than anywhere else

Most companies want privacy for their own data. A security team also holds someone else’s: the client or business unit whose network, credentials and unpatched systems are described in every prompt you write.

  1. The evidence stays where it belongs

    Recovered credentials, command-and-control artefacts, client hostnames and the case history are processed on instances in your account. They are not sent to any company that makes AI models, and they enter no one else’s retention window.

  2. Your client commitment stays intact

    If your contracts bar you from letting client material sit in a third party’s storage, a model whose terms require retention is open to you only if its provider grants you an exception. Running the model in your own account means you do not have to ask for one.

  3. You can show where it ran

    Region, instances, access: all of it sits in your account, so a client audit or a security questionnaire gets evidence instead of assurances. Every AWS API call we make is recorded in your own CloudTrail, and our access is yours to revoke at any time.

  4. The purpose is in writing

    Before a deployment exists, you confirm in writing what it is for and that it will be used only for work the owners of the systems concerned have authorized. It is then set up for a named team in a named account. Your logs show which identity called the model and when; whether prompts are logged as well is your decision, made to fit your client commitments.

04 / How we work

From first call to production

  1. Assessment

    Thirty minutes on your cases, what your client contracts require, and your AWS setup. You leave with a concrete recommendation for the next step, and sometimes with the recommendation that you do not need us.

  2. Measurement

    A fixed-fee project: together with you we assemble a test set from cases you are permitted to reuse, with live credentials and client identifiers replaced, measure the candidate models on it in your account, and hand you the results. They are yours to use whether or not you go further.

  3. Deployment

    The chosen setup goes live in your account: a private endpoint for your analysts and tooling, capacity for your caseload, access you control, and the agreements signed.

  4. Operations

    We keep it running and current: monitoring, capacity, upgrades you approve, and the licence register updated as models change.

05 / In writing

What we promise

Specific statements, not slogans.

Who can see what, in detail
  1. Runs on instances in your own AWS account. You own the keys and can revoke our access at any time.
  2. Your prompts, payloads and case data are not sent to any company that makes AI models.
  3. For this work we use no shared model service, so nothing you send the model is kept outside your account.
  4. Hosted in the AWS EU region you choose, for example Frankfurt.
  5. We work through a role with short-lived credentials. Every AWS API call we make is recorded in your CloudTrail, and commands we run on your instances in a session log in your account.
  6. The model and the software serving it stay at the versions you approved until you approve a change.
  7. We use only Nitro-based instances with encrypted volumes. AWS states in its Service Terms that its staff have no technical means to access your content on them.AWS Service Terms
  8. We deploy published, versioned models whose licence lineage we have traced and documented for you.
  9. Every deployment is set up for a named team in your account. We do not run a shared endpoint or self-serve access for this work.
  10. Use is limited by contract to work the owners of the systems concerned have authorized. We do not see your prompts, so the agreement places that obligation on you and lets us end the service if a deployment is used otherwise.
  11. We set this up to support your analysts, not as an autonomous agent: we connect it to nothing that changes a system on its own. What is applied, and after which review, is your team’s decision.
  12. A GDPR processing agreement and a separate secrecy agreement, signed with you. Where you process client data on your client’s behalf, we act as your sub-processor and give you what your client needs to approve us.

Measure the models on your own cases first

Thirty minutes on your cases, your client commitments and your AWS setup. You leave with a concrete recommendation: which models to measure, how they would run in your account, and what operating them takes.

Book an assessment