Governance is a floor, not an add-on.
Railspike is designed so identity, scope, policy, approvals and receipts are part of the action path itself. The customer decides what the system may do — and the system carries the basis for that decision forward.
AI does not grant itself authority.
Models can identify, summarize and propose. Authorization is resolved outside the model through customer policy and scoped capability.
Identity
Microsoft Entra sign-in, or email and password, with server-side session handling and human-readable identity.
Scope
Tenant, portfolio, property, project and role boundaries travel with the request.
Policy
Deny-by-default checks determine which declared action classes are permitted.
Receipts
Attributable decisions keep the proposal, authority, evidence and outcome inspectable.
Configure the operating envelope to your level of comfort.
The current product already demonstrates customer-owned controls over autonomous action and timing/escalation. Those are examples, not the limit. Railspike’s configuration model is designed to extend governance as workflows and risk classes expand.
Auto-execute selected reversible internal steps while keeping consequential or external actions as proposals.
Set response clocks, escalation windows, deferral limits and the point where silence becomes a finding.
Thresholds, separation of duties, delegation, expiry and required actors.
Permitted models, actions, data classes, residency, retention and external destinations.
Scope · capability · data class · destination · policy · approval requirement
Security should improve operational clarity, not bury it.
Operators see plain-language status and next action. Administrators and auditors can progressively disclose the policy basis, capability, evidence, correlation ID and audit detail when they need it.
Built around the controls enterprise IT already expects.
Railspike’s current foundation and target release path use Microsoft identity and Azure-native controls rather than inventing a parallel security stack.
| Layer | Railspike approach | Why it matters |
|---|---|---|
| Identity | Microsoft Entra; backend-for-frontend authentication; HttpOnly sessions | Company identity remains the basis for access. |
| Authorization | Tenant-scoped capabilities, property/project scope and deny-by-default checks | Access and action authority are explicit rather than inferred by a model. |
| Secrets | Azure Key Vault and managed identity in the target release architecture | Production credentials are kept out of application code and CI files. |
| Action integrity | Proposal → decision → execution → verification with attributable receipts | The difference between “recommended” and “actually happened” remains inspectable. |
| Data portability | Customer-owned export of normalized records and source files | The company brain is not intended to become a vendor trap. |
Security diligence should start before production data enters the platform.
We can walk through identity, deployment, model boundary, permissions, retention and action controls with the customer’s IT/security stakeholders.
Available only for authorized preview use. Public purchasing is not open.