Trust & Security

This page is written for a security, compliance, or procurement reviewer evaluating Asenion. It describes how Asenion runs in your environment, how integrations authenticate, how the platform handles data, and the evidence model that lets you verify what the platform did rather than take its word for it.

Asenion is an AI governance platform with capabilities across the lifecycle of an AI system. For the end-to-end picture of what it does, start with What is Asenion?. This page covers the questions a reviewer asks before that: where does it run, how does it connect, and what can I check?

Deployment options

Asenion is a containerized platform, and you choose where it runs. The same product is offered under several deployment models so that data residency and operational control can sit wherever your policy requires.

Deployment model Where it runs Notes
Private cloud (single-tenant) Your own AWS, Microsoft Azure, or Google Cloud Platform account Asenion is deployed into infrastructure you control.
Asenion-hosted SaaS Microsoft Azure, operated by Asenion Available as multi-tenant or single-tenant.
On-premises A virtual machine or physical machine in your own environment The platform is fully containerized and can be installed on hardware you provide.
Self-hosted testing service Your environment The LLM testing service ships as a containerized application (Docker / Compose) you run yourself, so prompts and responses under test stay inside your network.

Because the platform is containerized, an on-premises or self-hosted deployment keeps your data and your model traffic within your own environment — the platform connects outward only to the model APIs and systems you designate.

For the deployment matrix in its own words, see Deployment Options. For what the self-hosted testing service needs to run — Python, a Node-based evaluation tool, network access to the model APIs you call, and container or Compose instructions — see Installation.

Authentication

Asenion’s testing integration authenticates on every request it makes to a system under test, over HTTPS. When you expose an endpoint for Asenion to test, it supports one or both of the following credentials:

  • Bearer token — Authorization: Bearer <token>
  • API key — X-API-Key: <key>

Your endpoint rejects a missing or invalid credential with 401 Unauthorized and a JSON error body. For local or internal use you may allow unauthenticated access; for production you require a credential. The full request/response and authentication contract is documented on the endpoints reference.

Within the platform, access is governed by roles rather than shared credentials: platform-level and project-level roles determine who can manage an organization, register and govern an AI use case, and review or sign off on assessments. The role model is described under User Roles and Getting Started.

Data handling — how Asenion runs in your environment

Asenion is designed so that you decide where governance data and model traffic live:

  • You choose the deployment. In a private-cloud or on-premises deployment, the platform runs inside infrastructure you control; in the Asenion-hosted option it runs on Microsoft Azure.
  • You supply model credentials. The testing service reads model-provider credentials from environment configuration (for example an .env file or the equivalent secrets your container runtime provides). Asenion connects to the model APIs you name — Azure, OpenAI, AWS Bedrock, Google Vertex, among others — over your network.
  • Connections are authenticated and encrypted in transit. Integrations use Bearer-token or API-key authentication over HTTPS, as above.
  • The platform is the system of record. Assessments, test results, and reports are drawn from the same records your team works in, so what a report shows is the actual state of governance rather than a periodic reconstruction of it.

This page describes capabilities, not any particular customer installation. What a given deployment stores, and where, is a function of the model you choose from the table above.

Architecture at a glance

Asenion has four capability areas, each of which produces evidence attached to the system it governs. The Overview walks the whole loop; the reviewer-relevant shape is:

  • Authoring turns a regulation, standard, or policy into structured controls, each carrying citations back to the source clause and a versioned, tamper-evident history of what changed.
  • Assessment is the system of record: a hierarchical inventory (AI systems, models, agents, datasets, vendor components), a role-based review workflow with owners, reviewers, and approvers, a full audit trail, lifecycle stages, and reports.
  • Testing evaluates the systems you govern — structured adversarial testing for LLMs and agentic systems, bias and fairness metrics across protected classes, and statistical drift detection — delivered by a network of test agents architected as microservices you can deploy where your models run.
  • Runtime Governance is delivered by Guardian: your agents and applications consult it at the moment of a bounded action, and it surfaces the policies and guidance that apply, producing a tamper-evident witness record of what was consulted and what guidance was returned.

The architecture is presented here to be legible to a reviewer, not reproducible: it names the components and the trust boundaries without publishing internal implementation recipes.

The evidence model

For a governance platform, the question behind every security review is how do I verify what the platform did? Asenion’s answer is that evidence is produced in the course of the work itself, and is built to be checked:

  • Controls carry citations to the source text they implement and a versioned, tamper-evident history.
  • Assessments carry review trails — who responded, who reviewed, who signed off, and when.
  • Tests carry results tied to the specific system they tested.
  • Runtime consultations carry a tamper-evident witness record, cryptographically chained so that tampering is evident and so that the record can be verified afterward by someone who trusts no one involved.

Because these records are made as the work happens, when an auditor, a regulator, or a customer’s security team asks you to show your work, the record already exists rather than being assembled for the occasion.

Certifications and security program

Asenion is ISO/IEC 27001, ISO/IEC 42001, and SOC 2 Type 2 certified. Certification reports and procurement or security documentation are available on request from the Asenion team at support@asenion.ai.

Asenion’s internal security program includes role-based access control, immutable audit trails, encryption at rest and in transit, and security and assurance testing, with security audits and risk assessments performed at least annually and continuous vulnerability monitoring backed by committed CVE response timelines.

Certifications attest to Asenion’s own controls. For the AI systems you govern, the trust model is the verifiable evidence described above — records you or your auditors can inspect directly.

Guardian: guidance, not verdicts

Guardian is worth a specific note for reviewers, because it is easy to assume a runtime governance layer acts on its own. It does not. Guardian surfaces the applicable policies and guidance and witnesses what happened; how to act on that guidance is your integration’s to determine. This is a design position: a governance layer you can trust is one that shows its work and leaves the action to you, and it is why every consultation leaves a tamper-evident witness record you can verify.

Where to go next