Saltar al contenido
VexiumAI Logo
VexiumAIAI Intelligence
SolucionesCómo funcionaAgentes IADiseño webNosotros

VEXIUM AI LLC / SECURITY

Security at Vexium AI

Who is responsible for security at Vexium AI, which systems that covers, and how to report a vulnerability to us.

VEXIUM / SECURITY
Updated · October 9, 20267 sectionsVexium AI LLC · Kansas City, MORead document

ON THIS PAGE

  1. 01Security leadership
  2. 02Scope: systems we own and operate
  3. 03How to report a vulnerability
  4. 04Rules of engagement and safe harbor
  5. 05How we protect our systems
  6. 06Recent security work
  7. 07security.txt and updates
Report a vulnerability
ON THIS PAGE
  1. 01Security leadership
  2. 02Scope: systems we own and operate
  3. 03How to report a vulnerability
  4. 04Rules of engagement and safe harbor
  5. 05How we protect our systems
  6. 06Recent security work
  7. 07security.txt and updates
01

Security leadership

Security at Vexium AI LLC is led by Cristian Ramirez, Founder & CEO. He is accountable for the security of our products and infrastructure, owns the security program and is the company's security point of contact for customers, researchers and partners.

Cristian Ramirez

Cristian Ramirez

Founder & CEO · Security Lead

Founder & CEO @ Vexium AI · Bilingual AI voice agents and CRM for the Americas · Security lead, vexiumai.com/security · Building on Claude + Deepgram + ElevenLabs · NVIDIA Inception · AWS Activate

Security contact: security@vexiumai.com

Alternate: ram@vexiumai.com

LinkedIn profile

02

Scope: systems we own and operate

This policy covers the systems that Vexium AI LLC owns and operates:

vexiumai.com

This website and its public, read-only agent endpoints (MCP and A2A).

Vexium CRM · crm.vexiumcore.com

Multi-tenant CRM for WhatsApp, Messenger and Instagram.

Vexium Voice · vexiumvoice.app and its subdomains

Bilingual AI voice receptionist for phone and web.

Agentes Vexium · bots.vexiumdata.com

Conversational agent platform and the messaging channels it operates.

Systems we build and host for our clients are not in scope for independent testing. Test them only with that client's written authorization. If you find something in one of them, report it to us and we will coordinate with the client.

03

How to report a vulnerability

Email the details to the security contact above. The more of this you include, the faster we can act:

  • The affected system or URL.
  • Steps to reproduce, or a proof of concept.
  • The impact as you understand it.
  • How we can reach you for follow-up.
1

Acknowledgement

2 business days

We confirm that we received your report.

2

Triage and first status

5 business days

We reproduce the issue, assign a severity and tell you what we plan to do.

3

Remediation

7 to 90 days

Targets by severity: critical in 7 days, high in 30, medium and low in 90.

4

Closure

On fix

We tell you when the fix is live and credit you publicly if you want us to.

We do not currently run a paid bug bounty program. We do say thank you, we fix what you find, and we credit you if you wish.

04

Rules of engagement and safe harbor

We welcome good-faith security research on the systems in scope. Good faith means:

Testing only with accounts and data you own or created for the test.
Stopping as soon as you confirm a vulnerability, and reporting it promptly.
Giving us reasonable time to fix the issue before any public disclosure. We aim for 90 days at most.

Not allowed

Denial of service, resource exhaustion or spam against any of our systems or phone numbers.
Social engineering of our staff, clients or their customers.
Accessing, modifying, deleting or downloading data that is not yours. If you encounter personal data, stop and report it.
Pivoting from our systems into third-party systems, including those of our clients and providers.

Safe harbor: we consider research that follows this policy to be authorized, and we will not pursue or support legal action against you for it. If a third party initiates action against you for research that complied with this policy, we will make it known that you acted in accordance with it.

05

How we protect our systems

This is what we do today. It is not a certification, and we keep it current as our program grows.

Periodic internal security audits of our own code, covering authentication, authorization, database row-level security, injection and secrets, with severity-ranked findings and tracked remediation.
Secrets kept out of source code, secret scanning before code is published, and third-party tokens stored encrypted.
Cloudflare with managed firewall rules and rate limiting in front of our CRM; signed webhooks and per-token rate limits on our messaging and voice endpoints; HTTPS and security headers everywhere.
Tenant isolation enforced in the database and reviewed in every audit, so one client's data stays separate from another's.
Dependency monitoring with prompt patching of the frameworks we run on.
A named owner for incidents, and customers notified without undue delay when their data is affected.
06

Recent security work

Security work we have completed recently on systems we build and operate. Client names are omitted on purpose.

June and August 2026 · Two internal security audits of a car-rental reservation system we build and operate: authentication, Postgres row-level security, rate limiting and HTML injection in e-mails. Findings were ranked by severity, fixed, and the fixes verified against production.

September 2026 · Closed an unauthenticated integration API on a rental ERP we operate and hardened its login and session handling, validated with 53 regression tests.

October 2026 · Phase 1 security audit of Vexium CRM: cross-tenant isolation, SSRF, OAuth and webhook signatures, with fixes merged and dependency advisories brought to zero. Audit of a public quoting API: rate limiting, formula injection and privacy notice.

Ongoing · Adversarial testing of our chatbots (prompt injection and data exfiltration), secret scanning before code is published, and firewall rules against automated scanners on our public endpoints.

07

security.txt and updates

Machine-readable contact information for this policy is published at /.well-known/security.txt, following RFC 9116. This page is reviewed at least once a year. The security.txt file expires on October 1, 2027 and is renewed before then.

RELATED

Legal and policy documents.

PrivacyTerms of serviceData deletion
VexiumAI

Inteligencia que trabaja contigo.

SOLUCIONES

Vexium VoiceVexium CRMAgentes de IADiseño webAutomatización

VEXIUM

NosotrosCómo trabajamosContacto

LEGAL

PrivacidadCondicionesEliminar mis datosSeguridad
© 2026 Vexium AI LLCKansas City, USA
Volver arriba
VEXIUMAI✳