What we can prove, and what we have not done yet

UVAMAI holds no ISO 27001 certification, no SOC 2 report, no PCI DSS attestation and no HIPAA assessment. We have not been independently audited against any security framework. We are stating this first because it is the thing a trust page is most often used to obscure.

We are not going to describe ourselves as "ISO-aligned", "SOC 2 ready" or "compliant with industry best practice". Those phrases mean nothing verifiable, and using them would tell you more about our marketing than our engineering.

If a certification is a hard requirement for your procurement process, say so early. We will tell you honestly whether we intend to pursue it and on what timescale, and if the answer does not work for you, we would rather you knew in the first conversation than the fifth.

Development is trunk-based. Every change lands on the main branch through a pull request, and no change reaches the site without passing an automated gate first.

That gate is: TypeScript compiles under strict mode, the linter passes, the production build succeeds, production dependencies carry no high-severity advisory, the container image builds, that image boots, its health check goes green, and the home page renders its own content. A failure at any step stops the change in review rather than at deploy time.

Accessibility and performance are gates too, not reports. Lighthouse budgets and an axe scan run against the built site on every pull request, and a regression fails the build.

The container image is built in CI, never on the server, and tagged with the commit SHA that produced it. The server only ever pulls an image and runs it.

Deployment waits on the container's own health check before it completes, so a build that starts and immediately dies fails the deploy instead of quietly taking the site down. A final step reads the deployed commit back from the live site and fails if it does not match what was just pushed — a deploy that appears to succeed while the old container is still serving is otherwise invisible.

Rolling back is redeploying a previous SHA. That image is already in the registry, so it is a pull and a restart rather than a rebuild.

The application runs as an unprivileged user inside the image. Nothing in it needs root, so nothing in it has root.

The container is bound to the loopback interface only and is never published on the public network. Our reverse proxy terminates TLS and forwards to it. It runs with no-new-privileges set, a hard memory limit and a CPU limit, so a runaway process here cannot starve the platforms sharing the machine.

Container logs are size-capped and rotated. An uncapped log file filling a disk would take down every service on that box, not just this one.

Browsing the site stores nothing about you on our servers beyond ordinary web server and reverse proxy logs, which include IP addresses and are retained for a limited period for operational and abuse-handling purposes.

If you send us an enquiry through the contact form, we store what you typed — your name, email address, organisation if you gave one, the topic and your message — on our own infrastructure. In this release it goes nowhere else: no email marketing platform, no third-party form service, no advertising network. The submission is rate limited by IP address to make automated abuse impractical.

We will contact you about your enquiry and nothing else. There is no mailing list to be added to, because we do not run one.

The content security policy on this site restricts where scripts, styles, images and connections may come from, which blocks injected third-party resources. It permits inline scripts, because the framework emits them and removing that would require giving up fully static pages. It is a real control against external script injection and a weak one against a same-origin injection, and we would rather describe it accurately than call it hardened.

Rate limiting on the contact form is held in the memory of a single process. That is sufficient for one container and it resets when we deploy. It is a spam control, not a security boundary, and we will replace it when the shared cache lands.

Uptime and latency figures shown beside our platforms are illustrative until the health probes are wired to them. Every surface that displays them says so.

These are designed and scheduled rather than running today, and are listed so nobody mistakes the plan for the present state:

• Administrative sign-in with a second factor and recovery codes, database-backed sessions, and role-based access.
• An append-only audit log covering every content and configuration change.
• Enquiries queued to MIRAI CRM with idempotency keys, retries and a dead-letter queue, so nothing is lost when the CRM is unreachable.
• Live health probes replacing the illustrative uptime figures on the platform pages.
• Encrypted, per-record handling of any third-party provider credentials, with the plaintext never returning to a client.

Email hello@uvam.ai with enough detail to reproduce the issue, and put "security" in the subject line so it is routed rather than queued. The same address is published in our security.txt.

We will acknowledge your report within two working days and tell you what we intend to do about it. We will not threaten you with legal action for testing in good faith against this site, and we will credit you when the fix ships if you want us to.

Please do not run automated scanning that degrades the service for other people, do not access or modify data belonging to anyone else, and give us a reasonable window to fix the issue before publishing it.

This page describes uvam.ai. The MIRAI platforms are separate applications with their own architecture, their own data handling and their own deployment pipeline.

If you are evaluating one of them, ask us for its documentation rather than assuming this page covers it. We will tell you what is true of that system specifically, including where it is weaker than this one.