← Back to home

Security

Version 1.0 · Last updated: July 14, 2026

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: bcrypt with cost factor 12+
  • 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

Seat Validation Gateway

  • Seat validation: Only SHA-256(key) + nonce 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

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

RailCall gateway and seat-validation services run on AWS (or GCP), leveraging:

  • VPC isolation and network segmentation
  • IAM least-privilege access controls
  • Encrypted storage (EBS, S3 with KMS keys)
  • CloudWatch / StackDriver logging and monitoring

Access Controls

  • Internal: Role-based access (RBAC) for AiTrade staff — audit logs for all production access
  • Database: Encrypted at rest (AWS RDS encryption), restricted network access
  • Secrets: API keys and credentials managed via AWS Secrets Manager / GCP Secret Manager

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

  • GDPR, CCPA, UK GDPR, LGPD: Privacy-first architecture minimizes personal data collection and transmission
  • Data Processing Agreements (DPA): Available for Enterprise customers upon request
  • Penetration testing: Annual third-party penetration tests

Roadmap (2026-2027)

  • HIPAA: 100% compliant with the §164.312 technical safeguards today; BAAs signed at Enterprise.
  • SOC 2 Type II: Independent audit in flight, report targeted for Q4 2026.
  • ISO 27001: Under consideration for 2027.

Scope note: The compliance claims above describe RailCall's product controls. Your organisation's overall regulatory posture also depends on how you configure, deploy, and operate the product; consult your counsel or auditors on end-to-end coverage.

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: RailCall is 100% HIPAA compliant on the §164.312 technical safeguards, and offers signed BAAs at Enterprise. Your organisation's overall regulatory posture — how you configure, deploy, and operate the product against your specific regulator — still needs your own assessment.
  • 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

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