Krishna's team joined a deep dive session to evaluate whether Kindo can support a managed AI SOC offering. Here's what they signaled, what's missing, and what we do next.
Charlie · Joana · Victor
Krishna (lead) · Adelina · Harsha · Ravi · Tim
Point any AI workload at Kindo as LLM gateway. Audit logging, DLP, model/access policy enforcement. Operational today.
Centralized tool access management. One MCP config → all corporate tools. Governance of which teams get which integrations. Reduces end-user friction.
OpenTelemetry GenAI semantic conventions. ClickHouse foundation shipped. Product features (traces, metrics, collector API) not yet exposed. Timeline: early 2027.
Generic enforcement at tool-call/LLM boundaries. Webhook or agent-based judges. Configurable fail-open/fail-closed per hook. Not yet built.
If Kindo proxies all AI traffic, it becomes a SPOF. Clients will demand resilience proof before signing. Charlie responded with blue-green/auto-scaling, but no concrete numbers or architecture diagram exists yet.
Krishna wants risk scoring across multiple API calls and sessions — not just per-transaction policy. This is SOC language, not firewall language. If Kindo can do this, it's a SOC platform. If not, it's a policy gateway.
Krishna drew the distinction himself: simple policies (block tool access) = inline prevention. Deep inspection = detection only, not inline. This is defense-in-depth framing — the same architecture CISOs already use for network security.
Krishna immediately tested whether swimlane could be deprioritized to accelerate telemetry. Telemetry is the capability he needs to sell SOC for AI. Swimlane is an internal cost-avoidance play — it doesn't help him close deals.
Clients may want to use their existing SIEM (Google SecOps, Splunk) rather than ClickHouse. Charlie confirmed Kindo can forward telemetry to external systems and potentially make value-added features optional. Minimum ClickHouse may still be required for system health.
Fail-open is unacceptable for governance clients. Fail-closed is too risky without knowing downtime. Charlie: configurable per hook, standard HA (blue-green, zone distribution). But the operational story needs sharpening.
Deploying AI governance requires: Kindo deployment, reconfiguring all AI workloads to route through Kindo, revoking direct API key access, and employee communication. The friction is change management, not infrastructure. MDM-assisted reconfiguration planned but not built.
He wasn't asking exploratory questions. He was testing whether Kindo can support the pitch he already wants to make: Kindo as the platform for a managed AI SOC offering. The same model Deloitte uses with Splunk/Google SecOps for traditional cyber SOC — but for AI workloads.
Charlie presented four technical pillars. Krishna heard three sellable layers:
Inference proxy + MCP gateway. Policy enforcement, DLP, access control. Live now.
Telemetry + behavioral analysis. Cross-session risk scoring. The SOC capability.
Shadow AI discovery via MDM/EDR orchestration. Remediation workflows. Highest value, longest runway.
The risk: If Kindo doesn't provide the framing materials Krishna needs, Deloitte will build the narrative themselves — and may misposition Kindo's capabilities or make commitments the product can't support.
The SPOF concern was raised but only addressed verbally. Krishna needs a one-slide diagram he can put in front of a CISO showing redundancy, failover, and zone distribution.
Zero mention of SOC 2, NIST AI RMF, or ISO 42001 in a 58-minute governance conversation. Deloitte sells compliance. They need to map Kindo capabilities to framework controls.
Charlie was "confident" the inference proxy is in the latest build but couldn't confirm MCP gateway 100%. Needs verification before making further claims.
The biggest blocker to "force everything through Kindo": employees lose their $20/mo Claude Pro access when routed through API pricing. No answer offered.
Charlie flagged that shrinking models will proliferate on endpoints, making API key control insufficient. Acknowledged as an open problem with no solution timeline.
Translate 4 pillars → 3 layers (Prevent / Detect / Respond). Give Krishna the narrative he can use internally at Deloitte. One-pager, not a whitepaper.
One slide showing Kindo deployment with redundancy, failover, zone distribution. Doesn't need to be implemented — needs to be the target architecture a CISO can evaluate.
Even a canned walkthrough showing trace data flowing through ClickHouse/HyperDX. Krishna's team expected to see something — we need to deliver before next touchpoint.
Verify MCP gateway is functional in the latest Deloitte build. Binary answer needed before making further claims.
Summarize what was discussed, confirm commitments, share any URLs (OTel GenAI conventions, Braintrust example). Maintain momentum before the weekend.
Map Kindo capabilities to NIST AI RMF / SOC 2 / ISO 42001 controls. Deloitte will need this to position the offering to compliance-driven buyers.