kela FundOS — security posture for fund managers, LPs, and AI agents.
Contact security: security@kela.com · SOC 2 report, DPA, MSA, and pen-test summary available under NDA.
kela FundOS is built for fund managers who handle LP capital, regulated data, and irreversible financial decisions. Every tool, every connection, and every byte is designed to meet the standards your LPs, auditors, and regulators expect.
We built kela because we ran a private credit fund for 16 years before selling to J.C. Flowers. We know the diligence questionnaires you have to answer, the audit trail your administrator demands, and the consequences of getting access control wrong. This page is the document we'd have wanted from a vendor in our seat.
kela exposes its full fund-operations platform as a Model Context Protocol (MCP) server, so AI agents — Claude, ChatGPT, Cursor, and others — can directly read, draft, and act inside your fund operations. This is a powerful capability and a new attack surface. We've engineered for both.
kela's MCP server acts as a proper OAuth 2.1 resource server, in line with the current MCP specification. Agents authenticate per-user against your firm's identity provider. Tokens carry user-level scope, not blanket access — an agent connected on behalf of an analyst cannot see what a partner sees.
All kela tools are classified at three levels:
The classification is visible in every tool description and machine-readable in the MCP annotations field, so your agent framework can route confirmations correctly.
The destructive-tool gate is enforced at kela's API layer, not just in the MCP client. Even if an agent is misconfigured or compromised, it cannot move money, publish LP-facing content, or change access rights without a human approval recorded in the audit log.
Every MCP invocation is logged with caller identity, tool name, arguments, result, success/failure status, and timestamp. Logs are immutable, retained for seven years by default, and available to your compliance team and external auditors via the get_audit_log tool or a direct database export. We expose this trail through the same MCP interface, so your compliance agent can answer "what did our AI agents do last quarter" without us being in the loop.
kela supports the MCP 2026 incremental-consent specification. Agents request the minimum scope per operation rather than blanket access upfront. A "draft an ODD response" request does not implicitly grant access to the OMS or capital call ledger.
kela tool outputs that originate from untrusted sources — uploaded documents, LP-submitted Q&A questions, external email content — are tagged as untrusted in the response payload. Agents that respect MCP content-trust annotations will refuse to follow instructions embedded in those payloads. We also strip common injection patterns from document text before it enters the agent context.
kela runs on AWS in the US-East region. All data is encrypted at rest with AES-256 and in transit with TLS 1.3. Customer-managed keys (CMK) are available on the enterprise tier for firms that require key custody.
EU data residency is available on the enterprise tier for firms operating under AIFMD, GDPR, or local data-localization requirements.
Tenant data is isolated at the database level. Cross-tenant queries are architecturally impossible — not just access-controlled. Every query carries a tenant identifier enforced at the connection layer, and our schema validation rejects any query that attempts to span tenants.
Deal-room documents are stored in encrypted blob storage. Access is controlled by per-document ACLs, and download URLs are signed and short-lived (default 15 minutes). Documents are scanned for malware on upload and content-type-verified before being served.
kela uses Gemini API (Google) and Anthropic API for LLM workloads. Neither provider trains on data sent through their paid API. kela does not log LLM inputs beyond what is required to operate the platform (error diagnosis, audit, and billing reconciliation). LLM-call logs are subject to the same access controls and retention policies as other customer data.
We never use customer data to train, fine-tune, or evaluate models — our own or any third party's. The only data that leaves our environment is the request payload sent to the LLM provider for the specific user query in front of it.
LP personal information, KYC records, beneficial-owner data, and tax identifiers are stored in segregated tables with additional access logging and field-level encryption for tax IDs. PII is never sent to LLM providers without explicit user invocation of a tool that requires it.
Customer data is retained for the duration of the contract plus a 90-day grace period for export. Audit logs are retained for seven years to support regulatory examinations. Deletion is honored within 30 days of a verified request, with documented exceptions for legally required retention.
We state our compliance posture honestly. Buyers know the difference between "in progress with a date" and a checkbox; we'd rather earn trust by being accurate than overclaim.
| Framework | Status | Target |
|---|---|---|
| SOC 2 Type II | In progress audit period began Q2 2026 | Report available Q4 2026 |
| SOC 2 Type I | Complete | Available under NDA |
| GDPR | Compliant DPA available | — |
| CCPA / CPRA | Compliant DPA available | — |
| ISO 27001 | Roadmap | 2027 |
kela is infrastructure, not a regulated financial institution. Your firm's regulatory obligations — SEC (Form ADV, Form PF, custody rule), AIFMD Annex IV, MAS/FCA filings, state-level investment adviser registration — remain yours. kela is built to support those obligations through audit trails, role separation, document retention controls, and automated report generation.
We've designed kela to be examined: every action is logged, every approval is timestamped, and every tool invocation is reproducible from the audit log. Our SOC 2 control set is mapped to the ADV Item 7 and Form PF data fields that our customers report.
A DPA is available on request and is included by default for any contract subject to GDPR, UK GDPR, or US state privacy laws. Standard contractual clauses are used for transfers out of the EU/UK where applicable.
kela commissions an annual third-party penetration test covering the web application, MCP server, API surface, and infrastructure. The most recent test summary is available under NDA. Critical and high findings are remediated before report finalization.
Email security@kela.com with any suspected security issue. We acknowledge within 48 hours and commit to coordinated disclosure. We do not currently run a paid bug bounty; we credit and acknowledge researchers who report responsibly.
Every commit is scanned for vulnerable dependencies, secrets, and known misconfigurations. Builds fail on critical findings. We track our exposed dependency surface and minimize where reasonable.
Given the elevated risk profile of MCP servers in 2026 — including documented CVEs against MCP Inspector and prompt-injection attacks against agent contexts — we run additional monitoring on the MCP endpoint: rate limiting per agent identity, anomaly detection on tool-call sequences, and automated alerts on patterns that match known agent-exfiltration techniques.
Production database and infrastructure access is limited to named senior engineers, with just-in-time elevation required for support cases. All production access is logged, including read-only queries. No engineer has standing access to customer data.
Any employee or contractor with production access undergoes a background check and signs an enhanced confidentiality agreement before access is granted.
We maintain a documented incident response runbook with defined roles, escalation paths, and customer-notification SLAs. For confirmed material security incidents, we notify affected customers within 72 hours, or sooner where required by law. Post-incident reports are shared with affected customers within 30 days.
A current list of sub-processors (cloud infrastructure, LLM providers, email delivery, monitoring) is maintained at kela.com/subprocessors. Customers on the enterprise tier receive 30 days' notice of material sub-processor changes.
The AI agent ecosystem moved faster than its security model. The NSA published guidance on MCP security in May 2026; new CVEs against MCP infrastructure are disclosed regularly; major MCP servers have been shown to silently exfiltrate sensitive data when prompted by malicious documents.
For a SaaS used by a marketing team, that risk is uncomfortable. For a platform used to manage LP capital, approve trades, and draft regulator-facing documents, it is unacceptable.
Three principles guide our security work:
No agent moves money without a human.
Capital calls, allocations, trade submissions, and access grants are gated behind explicit confirmation. This is a product decision, not a configuration toggle.
Every action is reproducible.
Your compliance team should be able to answer "what did this AI agent do, when, and on whose behalf" from the audit log alone, without contacting us. The audit trail is your audit trail, not ours.
Your data is yours.
It is not used to train models, not used to improve our product, not sold, not shared. The only third party that sees a request payload is the LLM provider you've authorized us to use, for the duration of that specific call.
We're building kela for fund managers who can't afford the alternative.
For prospective customers: if your firm has a security questionnaire we haven't seen, send it. We'll complete it directly and won't pad answers.
For Anthropic, Google, OpenAI, and MCP registry operators: the kela MCP server is published with full risk classifications, audit hooks, and OAuth 2.1 compliance. We welcome inclusion in curated connector directories and are happy to support security review by your team.
This page was last updated May 30, 2026. Material changes are versioned and announced to active customers via email and to the public via our changelog at kela.com/changelog. For the canonical, version-controlled security posture, see our SOC 2 report.