The security your CISO would build, if they were building it.
In your cloud account or ours. One authorize() predicate per MCP call. Hash-chained audit. Customer-managed encryption keys at rest.
This page is the lobby. The full Security Architecture pack (architecture diagram, two-tier authorization model, residual-risk disclosure, audit schema, sub-processor list, threat model summary, SDLC controls) is available to your security team on request.
Trust pillars
Your code stays in your cloud
Run StackRails in your own cloud account or on-prem and your source never crosses a tenancy boundary. On the hosted EU option, only the architecture model (metadata, under your KMS) is managed by StackRails, never your source.
Never trains a model
Your code and architecture are never used to train AI, ours or anyone else's. No model fine-tunes on your data, ever.
Gated by your permissions
Code snippets live in the graph but reach only users who already have source-control read access to that repo. Identity-bound via your IdP, authorized on every call.
Four trust claims a CISO can verify.
Four claims that bound the review surface. The full pack walks the technical evidence behind each one.
Storage stays in your environment
In a VPC deployment the graph, snippets, embeddings, audit log, Portal, and policy store all run inside your own cloud account (AWS, Azure, or GCP) under your KMS / Key Vault / Cloud KMS keys. Nothing routes outbound to StackRails in normal operation.
MCP responses go only to your approved assistants
Authorized graph slices are returned to the assistant inside your VPC. The assistant then transmits prompt and retrieved context to its LLM provider under your existing vendor agreement. StackRails adds no new third-party data destination.
Projected permissions
Every MCP call is authorized against the caller's source-control permissions: Tier A architectural metadata is org-wide; Tier B code-internal content is gated on the user's read access to the specific repo.
Your security team self-serves
Scope, per-repo confidentiality, redaction patterns, rate limits, audit-log mode, and SIEM webhooks live in the Portal under Information Governance. Gated to a Security Admin role distinct from Architect and Admin.
Same security controls. Different operating boundary.
Customer VPC
AWS, Azure, or GCP. The default for enterprise.
Run StackRails in your own cloud account. Cross-account access role (AWS IAM role with sts:ExternalId, Azure managed identity with federated credentials, or GCP service account with workload identity federation). BYOK under your KMS, your audit log, your VPC.
Hosted EU
StackRails-operated, eu-north-1.
Same product, same security controls, different operating boundary. Per-customer isolated graph under your KMS key. EU data residency by default. For smaller customers, design partners, and POVs that want enterprise posture without running infrastructure.
On-prem / air-gapped
Your data centre. Sovereign cloud. Defence.
Offline installer plus signed container images delivered out-of-band. No outbound connections required. Licence validation via offline-signed certificate rotated annually. Suited to sovereign cloud and defence deployments.
Where StackRails stands on GDPR, NIS2 and the EU AI Act.
The sub-processor list and DPA template are in the pack.
Sub-processor change notification: 30 days advance notice with right to object.
Request the full Security Architecture pack.
What's in the pack:
- Full Security Architecture (five components, egress posture, SCM matrix, encryption, audit schema)
- Two-tier authorization model (Tier A / Tier B), identity binding, residual-risk disclosure, live-probe protocol
- Compliance roadmap, sub-processor list, threat model summary, SDLC and supply-chain controls
- Reference Terraform modules (AWS, Azure, GCP)
Or email security@stackrails.ai directly. We respond inside one business day.