Alloy is non-custodial by design. We never hold, control, or have access to your private keys or funds. This is our most important security property — and it is structural, not a policy choice.
The strongest security guarantee is one that cannot be violated by a configuration change, a rogue employee, or an operational mistake. Alloy's non-custodial boundary is enforced at the architecture level.
Transaction metadata, policy decisions, approval states, reconciliation records, and audit evidence. Alloy operates on the workflow and evidence layer — the operational semantics of what happened, what was approved, and what needs attention.
Private keys, signing material, seed phrases, or raw cryptographic secrets. Key management and transaction signing remain with your chosen custody provider. Alloy connects via provider APIs — the same APIs your team already uses — and never requires key export or delegation.
Most security incidents in digital asset operations happen at the workflow layer: wrong approvals, missed reconciliation, stale policy, or operator error during provider transitions. Alloy addresses this layer without expanding the custody trust boundary.
Alloy requests only the minimum API permissions needed for each provider integration. Read access where possible; write access scoped to specific transaction submission flows.
Internal services authenticate every request. No implicit trust between components. Every API call carries identity, scope, and audit context regardless of network position.
Multiple independent controls at every layer: network isolation, application-level authorization, provider-side approval policies, and customer-defined policy rules that execute before any provider call.
Every operation, policy decision, approval, and provider interaction is logged to an append-only audit trail. Records include timestamps, actor identity, policy version, and provider confirmation.
When policy evaluation is uncertain, the default is denial. Missing policy rules, unreachable policy engines, or ambiguous approval states all result in blocked operations — never silent pass-through.
All data encrypted in transit (TLS 1.3) and at rest (AES-256). Provider API credentials stored in isolated secret management with per-tenant encryption keys. No shared secrets across customer boundaries.
Alloy processes transaction metadata, policy decisions, and reconciliation records. Here is exactly what we store, how we protect it, and how you get it back.
We are explicit about boundaries because vague security claims are worse than no claims. Here is what WalletKit phase one does not include.
Alloy is an early-stage company building toward enterprise compliance. We are honest about our current stage and transparent about our roadmap, because compliance is a journey, not a checkbox.
Non-custodial architecture verified through design review. Encryption in transit and at rest. Per-tenant data isolation. Immutable audit logging. Secure credential management. Vulnerability scanning on every deployment.
Stage: design partner validation
SOC 2 Type I readiness assessment. Formal penetration testing by independent security firm. Security policy documentation to ISO 27001 control mapping. Customer-facing security questionnaire and evidence package.
Stage: post-seed execution
SOC 2 Type II audit engagement. Independent code audit for critical paths. Formal incident response program with defined SLAs. Customer-accessible Trust Center with live compliance status, audit reports, and sub-processor list.
Stage: growth and enterprise readiness
By never holding, controlling, or having access to customer funds or private keys, Alloy operates outside the regulatory perimeter that applies to custodians, exchanges, and money transmitters in most jurisdictions.
Private network segmentation with no public-facing database endpoints. All administrative access requires MFA and is logged. Infrastructure-as-code with change review for all production modifications. No SSH access to production hosts — operations via audited control plane only.
Dependency scanning and SAST on every pull request. Container image scanning before deployment. Secrets never stored in code repositories. Rate limiting and abuse protection on all API endpoints. Input validation and output encoding at every service boundary.
Real-time alerting on anomalous access patterns, failed authentication attempts, and policy engine exceptions. Structured logging with correlation IDs across every service. Incident response runbooks for the most common failure scenarios.
Multi-region deployment capability. Automated backups with tested restore procedures. If Alloy becomes unavailable, customers retain full access to their custody providers and all previously exported audit data. No single point of failure in the critical transaction path.
We take security reports seriously and respond promptly. If you discover a vulnerability in Alloy's systems, please report it responsibly.
No. Alloy's architecture does not include any mechanism to access, store, or generate private keys. Transaction signing is performed by your custody provider through their standard signing flow. Alloy submits transaction requests via provider APIs — the same APIs your team already uses directly.
Your custody providers continue to function independently. All transactions previously submitted are already with the provider. Audit evidence and reconciliation records exported before the outage remain in your systems. Alloy is an operational layer, not a dependency in the critical signing path.
Not yet. Alloy is an early-stage company currently in design partner validation. SOC 2 Type I readiness is on our compliance roadmap for months 6–12 post-seed, with Type II audit engagement planned for month 12+. We are transparent about this because we believe honesty about compliance stage is more useful than vague claims.
Provider API keys and OAuth tokens are encrypted at rest using AES-256 with per-tenant encryption keys stored in dedicated secret management infrastructure. Credentials are never logged, never exposed in API responses, and never accessible to Alloy personnel without a formal access request process.
Production data access requires explicit justification, MFA authentication, and is fully logged. Routine operations do not require access to customer data. Support cases that require data access follow a documented process with time-limited permissions and audit review.
Based on our assessment, Alloy's non-custodial architecture — which never holds, controls, or has access to private keys or customer funds — does not trigger custody-specific licensing requirements in the jurisdictions we operate in. However, regulatory landscapes evolve. Customers should consult their own legal counsel for jurisdiction-specific guidance. We are happy to provide architectural documentation to support your legal team's assessment.
Yes. Contact security@alloy.build for our current security documentation, architecture diagrams, and control descriptions. We are building toward a self-service Trust Center with live compliance status for later stages.
The best security conversation starts with your specific requirements: regulatory environment, provider landscape, data residency needs, and compliance obligations. We will walk through exactly how Alloy's architecture maps to your security model.
Security reports: security@alloy.build · General: hello@alloy.build