Trust & Evidence

Procurement-ready answers,
without a sales call.

This page is built for security, procurement, and compliance reviewers. It answers the concrete questions you ask before approving a vendor: how RAXE turns agent activity into evidence you can verify, where data processes, what leaves your boundary, how our evidence maps to your governance frameworks, how to report a vulnerability, and the current SOC 2 posture.

01

How does RAXE turn activity into evidence?

Sealed by default, revealed on purpose, verifiable on demand. The record is the product – this is how it is built.

Sealed by default

Sensitive fields – prompts, file paths, tool arguments – land sealed in RAXE Lineage Lens, the RAXE console. Analysts triage on structure, scores, and lineage, not on your data.

Audited reveal

Unsealing a field takes a stated purpose and a click on Reveal. The reveal writes its own audit row – actor, field, outcome. Looking at evidence is itself evidence.

Hash-chained ledger

Every audit row is linked to the previous one by hash, so the ledger is tamper-evident. Run verification on demand and the chain answers with one word: Intact.

Fielding employee-privacy or works-council questions about watching engineers' agent sessions? Sealed-by-default already answers them: analysts triage on structure, scores, and lineage – not on what anyone typed – and unsealing a field requires a stated purpose and writes its own audit row.

From agent action to defensible record
1
What happened

An agent action arrives from one of four surfaces: gateway LLM traffic, in-app SDK events, AWS cloud activity, or kernel-observed file access from the host sensor.

2
Where RAXE saw it

The record names its witness: what the agent claimed at the gateway, what the application saw through the SDK, what the host sensor observed at the kernel – one timeline per agent session.

3
Why it was flagged

Explainable verdicts, not opaque scores: threat probability, per-family scores, out-of-distribution signal, and nearest known attack patterns, mapped to MITRE ATLAS and OWASP ASI.

4
What happened next

Reviewer actions join the same record: triage outcome, each reveal with its stated purpose, and the audit rows those reveals created. An approval trail your auditors can verify, not reconstruct.

2× 12/12
hardened acceptance runs on fresh deploys
7/7
persona review pass
Intact
audit chain verification result
13 · 41
threat families · techniques in the detection taxonomy

Process numbers come from our release gates, recorded on a live deployment – not marketing benchmarks. RAXE deploys observe-first: every would-block decision is logged with the evidence behind it. Today it lets you see it. Next, it lets you stop it.

02

Where does data process?

Data residency and where RAXE detection logic executes relative to your infrastructure.

RAXE is designed so detection runs inside your control boundary. The detection engine, classifiers, and scoring all execute on infrastructure you operate – self-hosted in your VPC or on your own hardware.

Telemetry and logs stay on your side unless you explicitly opt in to share anonymised signals with RAXE Intelligence. Prompt and response content is not transmitted to a RAXE-operated scanning cloud as part of normal operation.

  • Default deployment: detection runs inside your environment.
  • Data residency: follows your hosting region. We do not move traffic across regions.
03

What leaves your boundary?

Your prompts, detections, and evidence stay with you. Anonymised detection telemetry is the one configurable exception – off by default, shared only if you opt in.

Stays with you
  • Prompts, responses, and session content
  • Tool-call arguments and results
  • Kernel-observed file-access records
  • CloudTrail-derived cloud activity records – your CloudTrail is read in place by a collector running in your environment, never shipped to a vendor cloud
  • Detection scores and verdicts
  • The audit ledger and evidence exports
  • Customer-specific configuration and policy
Anonymised detection telemetry

Structured threat metadata only: family, technique, severity, classification tier. No prompts, no responses.

  • Purpose: keeps detection signatures sharp across deployments.
  • Your control: off by default for deployed products – share anonymised signals only if you explicitly opt in; the browser Detection Lab demo has its own one-click telemetry toggle (on by default, disclosed on the page).

The Browser Detection Lab demo on raxe.ai scans the prompt you paste as part of the detection walkthrough. Default on, toggle off in the demo.

04

What deployment models are supported?

Self-hosted in your environment. Validated paths today: Docker Compose, systemd, and the Python SDK. Kubernetes packaging is roadmap – stated plainly below.

VPC / Private cloud

Gateway, scoring, evidence store, and console all run inside your VPC. No RAXE-operated infrastructure in the traffic path. Signatures delivered via outbound HTTPS fetch.

Docker ComposesystemdPython SDKAWS CloudTrail reader
On-premise

Installed on hardware you operate, for organisations that keep AI workloads in their own racks. Same detection stack, same sealed evidence, same hash-chained ledger.

GatewaySDKHost Sensor
Kubernetes Roadmap

DaemonSet and sidecar packaging are on the roadmap, not shipping today. If K8s is your deployment target, ask us where it sits on the timeline before you plan around it.

DaemonSetSidecar

The AWS CloudTrail reader runs self-hosted alongside the rest of RAXE and needs read-only access to your CloudTrail. Early access – design partner programme; findings are correlated to agent sessions, not exact attribution; demo views use clearly-labelled sample data. How the AWS lane works →

05

How does RAXE evidence map to your frameworks?

Governance mappings: how the RAXE record supports your control obligations. Every entry links to the primary source.

These are governance mappings, not certification claims. They describe how RAXE evidence – the runtime record, the audited reveal trail, the hash-chained ledger – supports obligations you hold under each framework. Detection itself is mapped to MITRE ATLAS and OWASP ASI, the AI-specific threat frameworks, not to compliance frameworks.

Framework
Status
What RAXE evidence supports
Governance mapping
Map, Measure, Manage, Govern: the runtime record of what agents did, what was flagged and why, and who reviewed it gives you measurable inputs for the Measure and Manage functions.
Governance mapping
AIMS (AI Management System) supporting evidence: operating record, decision history, and audited access to sensitive fields for evaluation of AI system behaviour.
Governance mapping
High-risk system obligations: logging, transparency, human oversight. The hash-chained record and audited reveal support the record-keeping and oversight articles. Annex III obligations apply from 2 Aug 2026 (Digital Omnibus may adjust).
SOC 2
Programme in progress
Controls aligned to SOC 2 Trust Services Criteria. See SOC 2 posture below for the current status – stated plainly, no certification implied.
Governance mapping
Data minimisation by architecture: processing stays on infrastructure you operate, and sensitive fields are sealed by default. Data processing agreements available for enterprise customers.
Supporting evidence
ICT third-party risk and incident evidence for EU financial entities. DORA is already in force.
06

Vulnerability disclosure

How to report a security issue responsibly, what is in scope, and our safe-harbour commitment.

security.txt
Scope
RAXE Gateway, Application SDK, Host Sensor, Intelligence, and raxe.ai web properties.
Out of scope
Third-party cloud infrastructure, denial-of-service tests against production, social-engineering attacks on staff or customers.
Response SLA
Initial acknowledgement within 3 business days. Triage within 7 business days. Remediation timeline communicated with triage outcome.
Safe harbour
Good-faith security research conducted within scope will not be pursued legally. Please avoid privacy violations, data destruction, and service disruption.
08

SOC 2 posture

The current state of our SOC 2 programme and what we can share today.

SOC 2 programme status: in progress. RAXE has aligned internal controls to the SOC 2 Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) and is working through formal audit readiness. We do not claim a completed SOC 2 Type II audit.

For enterprise evaluations we can share the following under NDA:

  • Control matrix mapped to SOC 2 TSC
  • Current audit timeline and auditor relationship (when established)
  • Security questionnaire responses (SIG Lite, CAIQ v4)
  • Data processing agreement and sub-processor list

Ask the team for the current status: security@raxe.ai or book a walkthrough →.

Early access – design partner programme

Still have questions?

Book a 30-minute call with a RAXE engineer. No sales funnel.