← Back to home

Security

Version 2.0 · Last updated: August 27, 2026

Published for review.Version 2.0 withdraws three claims Version 1.0 made that no artifact supported: “100% compliant with the HIPAA §164.312 technical safeguards” (§5 and §8), “annual third-party penetration tests” (§5), and a cloud-provider list (§3) that did not match our published subprocessors. §5 sets out what we can actually back. Not yet reviewed by counsel.

Security by architecture. RailCall is designed to minimize attack surface by keeping your keys, code, and data on your machine. This page explains our security model, practices, and how to report vulnerabilities.

The core guarantee

Every action your AI takes leaves a receipt no one can forge or alter — not even us.

When your AI does something on your behalf — sends an email, charges a card, updates a record — RailCall signs a cryptographic receipt of exactly what happened, by whom, and under which rules. Anyone can check that receipt is genuine and unaltered, offline, with our servers switched off. It's the same mathematics that secures your bank's website and every verified app-store download — the strongest guarantee cryptography can give.

“Unforgeable unless you hold the private key” isn't fine print — it's the definition of digital security. The padlock on your bank site (TLS), signed software updates, and signed source code all rest on that exact sentence. No honest system claims more: whoever holds a signing key can sign with it — that is what a key is for. So this is the maximal, honest claim — unforgeable by anyone who doesn't hold the key.

Two keys — and stealing one is not stealing the system

Your station key

lives only on your machine · like your house key

Signs your receipts. If it were stolen, the thief could only act as your one account — and could never deny it, exactly like a stolen signature. Every other account stays untouched, and the key can be revoked.

RailCall's identity key

held only by us · never on any machine

Does one job: vouch for which account a station belongs to. It cannot rewrite a single receipt that was already signed — not even a past one. It's the key we guard hardest: off every machine, rotated on a 90-day expiry, moving to hardware.

Bottom line:steal one station's key and you compromise one account — bounded, revocable, undeniable. No key anywhere, ours included, can alter a receipt your station has already signed or rewrite the past.

1. Local-First Security Model

BYOK (Bring Your Own Key) Vault

  • API keys for connected services (Slack, Stripe, GitHub, etc.) are stored in a local vault on your disk
  • 0600 permissions recommended: Only your user can read/write
  • Encrypted at rest: Vault is encrypted with AES-256-GCM
  • Never transmitted: Keys are resolved at 127.0.0.1 — they never leave your machine to reach AiTrade

Connected-Service Actions (v1)

  • When you approve an action (send Slack message, charge Stripe, etc.), it flows directly from your machine to the provider
  • No RailCall intermediary: Action content never transits our servers
  • Your security posture: You control the network path, TLS certificates, and provider authentication

MCP Sessions (v1)

  • Loopback/stdio only: MCP connections to Claude Desktop (or other hosts) are local — no network egress to AiTrade
  • Governed execution: RailCall still enforces dry-run, approval, and receipts for actions proposed via MCP

2. What We Secure

Account & Authentication

  • Password hashing: a memory-hard KDF with per-user salt
  • Session tokens: Signed JWTs with short expiry (1 hour default)
  • Rate limiting: Brute-force protection on login endpoints
  • 2FA (coming soon): TOTP-based two-factor authentication
Counsel — name the password KDF exactlyThe password-hashing line above is deliberately generic. An earlier version of this page said “bcrypt cost 12+”, while the published subprocessor page says argon2id — the two cannot both be right. Confirm which primitive the auth path actually uses and state it exactly; a security page that guesses its own primitive is worse than one that omits it. Nothing has been asserted here in the meantime.

Entitlement and seat validation gateway

  • Blind by construction: where an entitlement or seat check is made, only SHA-256(key) + a nonce is transmitted — no action names, no per-action counts, no business data
  • TLS 1.3: All gateway communication encrypted in transit
  • Replay protection: Nonces prevent replayed validation requests
Counsel — does this call exist?Our own pages disagree about whether a periodic outbound seat-validation ping happens at all. The Privacy Policy and the Data Flow Disclosure both describe it as a recurring call while a paid seat is active. Terms of Service §25 records the opposite — that the v1.0 description was “not carried forward” because it describes “a periodic outbound call that the trust page says does not happen” — and §5.2 and §11.2 state that the local engine has no runtime dependency on any service we operate. Both cannot be true, and the difference is material: it is the single question a privacy-motivated buyer asks about a local-first product. Resolve it against the code, then make this page, the Privacy Policy, the Data Flow Disclosure, and the trust page say the identical thing. The wording above is deliberately conditional (“where a check is made”) so that it is not false under either answer — it is not a substitute for settling it.

Hosted Compose (Optional)

  • Zero-retention: Descriptions passed through to model provider, not logged by AiTrade
  • TLS everywhere: Encrypted in transit to gateway and provider
  • Alternative: Use BYOK or local model to avoid server-side compose entirely

3. Infrastructure & Operations

Cloud Providers

The authoritative list of the providers we actually use is the published subprocessor list, and it controls over anything on this page. It currently names Render, WorkOS, Stripe, Resend, GitHub, and Cloudflare. Our hosted services run on managed platform infrastructure with:

  • Network isolation and segmentation between environments
  • Least-privilege access controls
  • Encrypted storage at rest, with managed key handling
  • Centralised logging and monitoring
Counsel — GDPR Art. 13 / Art. 28This section previously named the wrong providers,describing the gateway as running on “AWS (or GCP)” with EBS, S3, KMS, CloudWatch, RDS, and Secrets Manager, while the published subprocessor list named Render, WorkOS, Stripe, Resend, GitHub, and Cloudflare, and railcall.ai resolves to a DigitalOcean address. Naming subprocessors that are not used, and omitting ones that are, is a disclosure defect under Art. 13 and Art. 28 — not a copy problem. The specific vendor names are removed above rather than replaced with guesses. Confirm the actual hosting, database, secrets, and logging providers and restore concrete names, in this section and on the subprocessor page, in the same pass. The Privacy Policy carries the same defect and is corrected the same way.

Access Controls

  • Internal: Role-based access (RBAC) for AiTrade staff — audit logs for all production access
  • Database: Encrypted at rest, restricted network access
  • Secrets: API keys and credentials held in a managed secrets store, not in source control

Monitoring & Incident Response

  • Real-time alerts for anomalous traffic, failed logins, or service degradation
  • Incident response runbooks for common scenarios
  • Security incident disclosure within 72 hours (GDPR requirement) if personal data is affected

4. Cryptographic Verification

Ed25519 Receipts

Every approved action mints a receipt with:

  • Integrity hash: SHA-256 of action plan + inputs + outputs
  • Ed25519 signature: Keypair-based signature (not login-based)
  • Offline verification: You can verify receipts independently, without trusting AiTrade or any online service

Public Key Infrastructure

  • Approval keypairs stored locally (your machine)
  • Delegatable: You can authorize other users/services to approve on your behalf
  • Receipts include the public key used for signature, enabling third-party audit

5. Compliance & Certifications

Current Status

We hold no security or compliance certification. No SOC 2 report, no HIPAA certification, no PCI DSS attestation, no ISO 27001 certificate. Where this page names a target date, that is a target and not a report. Terms of Service §14.1 states the same thing contractually.

Previous versions of this page said otherwise— that RailCall is “100% compliant with the §164.312 technical safeguards today.” That claim is withdrawn in full. There is no such certification for a software vendor to hold, we do not hold one, and an unqualified compliance assertion is a representation we cannot support. What we can say is narrower and is set out below.

  • GDPR, CCPA, UK GDPR, LGPD: Privacy-first architecture minimizes personal data collection and transmission. Adopted written policies and a documented risk analysis exist; neither is a certification.
  • Data Processing Agreements (DPA): Available on request to any customer, at no charge and regardless of tier. Under GDPR Art. 28 a controller is entitled to processor terms whenever we act as processor, so this is not gated to a plan.
  • HIPAA §164.312: We publish a mapping of our technical controls to the technical safeguards, so your own assessor can check our work. A control mapping is an input to your assessment. It is not a certification, it is not an attestation, and it does not make your organisation compliant.
  • Penetration testing: No third-party penetration-test report is currently published or listed on the trust page. Earlier versions of this page claimed annual third-party tests; that claim is withdrawn until there is an artifact behind it.

Roadmap (2026-2027) — targets, not held reports

  • HIPAA: BAAs offered under negotiated Enterprise agreements. A BAA is a contract we sign, not a certification we hold.
  • SOC 2 Type II: Targeted for Q4 2026. No report exists today. Ask for the current control inventory and readiness posture instead — that is a real artifact and we will send it.
  • ISO 27001: Under consideration for 2027.

Scope note:The controls described on this page are product controls. Your organisation’s overall regulatory posture also depends on how you configure, deploy, and operate the product, and that part is yours. No property of our software makes your organisation compliant with anything. Consult your counsel or auditors on end-to-end coverage.

Counsel — SOC 2 and penetration-test wordingThe HIPAA claim is withdrawn site-wide in this change— this page, the Enterprise and Teams pages, and the four marketing components no longer assert compliance. What still needs review is the remaining audit language: “SOC 2 audit in progress” and any reference to annual third-party penetration testing should not be published unless there is an engagement letter or report behind each one.CounselConfirm the HIPAA §164.312 control mapping is published at a stable URL before this page points at it as an artifact — the changelog references a /trust/hipaa page. A mapping we describe but do not publish is the same defect in a quieter voice.

6. Responsible Disclosure

Reporting Vulnerabilities

If you discover a security vulnerability, please disclose it responsibly:

  • Email: sami@railcall.ai
  • Response time: We aim to acknowledge within 48 hours and provide an initial assessment within 7 days

Scope

In scope:

  • RailCall CLI, gateway, seat-validation service
  • Web properties (railcall.ai, docs)
  • Authentication, authorization, or cryptographic flaws
  • Remote code execution, privilege escalation, or data leaks

Out of scope:

  • Social engineering or phishing attacks
  • Denial-of-service (DoS) attacks — report without testing at scale
  • Third-party services (Slack, Stripe, etc.) — report to those providers
  • Known issues already disclosed or in our backlog

Recognition

We don't run a cash bug-bounty program. Valid, high-impact reports earn contributor credit on our public community leaderboard, scaled to severity, plus a public acknowledgment in the fix advisory (with your permission, and never before a fix ships).

Rules

  • Do not access, modify, or delete user data without explicit permission
  • Do not disrupt service availability
  • Do not publicly disclose before we issue a fix and advisory
  • Comply with all applicable laws

Violation of these rules may forfeit any recognition and result in legal action.

7. User Security Best Practices

To maximize security when using RailCall:

  • Protect your vault: Ensure the local key vault has 0600 permissions (read/write for your user only)
  • Rotate keys regularly: Connected-service API keys should be rotated per your security policy (e.g., every 90 days)
  • Use strong passwords: Enable 2FA (when available) and use a password manager
  • Verify receipts: Audit Ed25519 receipts offline to ensure actions match your intent
  • Monitor provider dashboards: Check Slack, Stripe, GitHub audit logs for unexpected activity
  • Keep RailCall updated: We push security patches rapidly — update your CLI and Studio promptly
  • Report suspicious activity: If you see unexpected charges or account activity, contact sami@railcall.ai

8. Limitations & Honest Scope

No silver bullet. RailCall's local-first architecture reduces attack surface by minimizing data transmission, but it is not a complete security solution.

  • Your machine's security matters: If your laptop is compromised (malware, physical access), attackers may access your local vault.
  • Connected-service risk: Security of Slack, Stripe, GitHub, etc. depends on those providers — RailCall cannot eliminate third-party risk.
  • Your posture is yours: we publish a mapping of our technical controls to the HIPAA §164.312 technical safeguards, and we sign BAAs under negotiated Enterprise agreements. Neither is a certification and neither makes your organisation compliant. How you configure, deploy, and operate the product against your specific regulator is your assessment to make.
  • Zero-day vulnerabilities: Like all software, RailCall may have undiscovered bugs. Report them responsibly.

Our commitment: Operate transparently, patch quickly, and never hide incidents. Security is a journey, not a destination.

9. Questions & Contact

For security questions or concerns:

Email: sami@railcall.ai

Entity: AiTrade LLC, a Florida limited liability company

Counsel — registered addressCounsel supplied the jurisdiction of formation on 2026-08-27, and the entity block above now reads "AiTrade LLC, a Florida limited liability company". The registered business address was not supplied and is not published anywhere on this site — we have not invented one. Provide it. A security page is one an enterprise reviewer reads with a procurement checklist in hand, and a complete entity block is on it.

Entity: AiTrade LLC, a Florida limited liability company · Last updated: July 14, 2026
See also: Privacy Policy · Terms of Service · Data Flow Disclosure