Trust & Security
Verify every boundary.
How Senti limits permissions, separates execution, protects credentials, records activity, and lets you stop or revoke access. Funds stay at your broker.
Funds never leave the broker. Senti cannot withdraw or transfer them.
These figures show platform activity and measured availability, not investment performance, returns, or a contractual service level.
What the access model can and cannot do
Execution-only access by architectural design. Senti automates trading logic, it is technically incapable of moving or custodying money.
Security starts with a smaller permission boundary
The most robust security control is architectural: your funds remain permanently in your broker account, where deposits and withdrawals happen outside Senti's perimeter.
- Zero Custody: Capital never touches Senti's balance sheet or servers.
- Trade-Only Scope: Access tokens are restricted exclusively to order placement and status monitoring.
- Independent Banking: Deposits, withdrawals, and internal transfers remain strictly controlled via your broker's 2FA.
- Autonomous Governance: You retain sole ownership over strategy selection, risk budgets, and account revoking.
Senti is trading automation infrastructure. It is not a broker, custodian, fund manager, copy-trading marketplace, signal provider, or promise of financial returns.
A clear line between what you own and what Senti operates
The user or authorized customer stays responsible for the trading decisions. Senti provides infrastructure, not custody, investment advice, or discretionary fund management.
Where isolation is defined
“Isolation” is an architectural contract, not a generic security slogan. Ranging from single trade accounts to bare-metal deployments, boundaries are defined by your model:
- Trade Account Isolation: Each connected broker account operates within an independent execution runtime, preventing order, state, or memory bleed between accounts.
- Whitelabel Workspaces: Logical multi-tenant separation ensures member profiles, credentials, and telemetry remain strictly confined to your brand's workspace.
- API Scoping: Service tokens and programmatic access are strictly restricted to your provisioned users, completely segregated from third-party client datasets.
- On-Premise Perimeter: Physical and network-level sovereignty where infrastructure, VPC routing, and database boundaries are confined to your contracted server perimeter.
Specific data-handling policies, encryption standards, and architectural isolation guarantees are confirmed and documented during your technical security review.
Access remains under customer control
The authorized user can pause, revoke, and review at any time. Control does not depend on Senti.
The authorized user can pause or stop the supported automation workflow from Senti. When it is stopped, no new orders are placed.
Disconnecting the broker account or changing its credentials removes Senti's ability to continue the trading workflow.
Senti does not request withdrawal or transfer rights. The deposit and withdrawal flow stays entirely with the broker.
Supported order and account activity can be reviewed through Senti's operating and verification surfaces.
For B2B deployments, the exact account roles, administrative permissions, support access, and offboarding process are confirmed during technical discovery and documented in the applicable agreement.
How broker credentials are secure by architecture
Senti protects account keys using AES-256-GCM authenticated encryption. Credentials are encrypted at rest and decrypted exclusively inside isolated execution runtimes, never exposed in the web layer.
- Least-Privilege Scoping: Enforces the narrowest viable broker permissions, authorizing trade execution while strictly excluding withdrawal pathways.
- Isolated Decryption Perimeter: Decryption keys are decoupled from the web application and loaded solely within the ephemeral trading container.
- Zero Plaintext Logging: Broker passwords, server tokens, and session secrets are cryptographically scrubbed from all monitoring telemetry and error logs.
- Dynamic Revocation & Rotation: Terminate sessions and flush credential stores instantly upon account disconnection or security rotation.
End-to-end credential lifecycle flows, key management specs, and deployment-specific KMS controls are formally validated during technical security review.
What the operating record proves, and what it does not
We do not turn an operational metric into a certification, warranty, or guaranteed future result.
Our current compliance & audit posture
Senti does not claim active SOC 2 certification or published third-party penetration test reports. Independent formal external audits remain on our roadmap without speculative completion dates.
An evidence-led security posture
In place of third-party marketing badges, our security model is governed strictly by verifiable architectural boundaries and telemetry:
- Architectural Non-Custody: Funds remain permanently with regulated MT5 brokers; Senti possesses zero fund-transfer mechanisms.
- Documented Access Limits: Hard technical boundaries separate trade execution from fund management and credential access.
- Hardened Credential Isolation: AES-256-GCM encrypted keys decrypted solely within ephemeral, containerized runtimes.
- Verifiable Operational Evidence: System reliability backed by measured beta uptime and timestamped execution logs.
- Contracted Service Boundaries: Deployment-specific SLAs, incident responsibilities, and support escalation protocols confirmed in writing.
Formal audit reports, third-party penetration assessments, and data-residency certifications will be published here upon completion and disclosure clearance.
What a security review can cover
A technical or procurement review works through the deployment on real terms, not a generic checklist.
How your chosen model is deployed and how data moves through it.
The access scope and the credential path behind it.
Who can do what, and where those boundaries sit.
How issues are detected, escalated, and how access ends.
The technical requirements particular to your deployment.
The difference between operating history and a signed commitment.
Non-public evidence is shared only after scope and confidentiality terms are agreed. Current B2B agreement templates include mutual confidentiality provisions subject to legal review, and a separate mutual NDA can be scoped for deeper diligence. Availability and final terms are confirmed by Senti and legal before non-public materials are shared. It is not a self-serve or pre-approved public document.
Live operating metrics vs. contractual SLAs
Senti distinguishes observed historical uptime from binding legal commitments. We provide transparent telemetry publicly while tailoring guaranteed SLAs to each deployment contract.
- Measured Beta Uptime: 99.9% observed availability across live beta infrastructure.
- Standard API Support: Email response target within 24 business hours.
- Public Posture: Operational telemetry reflects historical performance, not a default blanket guarantee.
- Custom Availability Targets: Formal uptime commitments defined per deployment scope.
- Dedicated Escalations: Dedicated communication channels with agreed incident response windows.
- Service Terms: Remediation credits, maintenance windows, and governance confirmed in signed agreements.
Trust FAQ
Does Senti ever hold customer funds? +
Can Senti withdraw from a connected account? +
Can access be revoked? +
Is 99.9% a contractual SLA? +
Is Senti SOC 2 certified or independently penetration-tested? +
Can our security team review more detail? +
Verify the boundary before the deployment.
Tell us which deployment you are evaluating. We will route the review to the relevant technical and commercial context. Contact: Email partners@koni.studio with your company, deployment model, reviewer role, and priority security questions.