Kindo × Deloitte
Thursday Session · Deep Dive
Session Prep

Three Topics, One Direction

Thursday covers agent telemetry & SOC for AI, observability, and Swimlane transition. For each topic: where we are, our recommended direction, and what we need confirmed to start Sprint 3.

Topic 1 · Agent Telemetry & SOC for AI

Sprint 2 Progress & Recommended Direction

Sprint 2 advanced the SOC for AI architecture across telemetry, platform research, and discovery frameworks. The agent telemetry alpha is architected to graduate toward production — it represents the starting point for requirements finalization. Full details at sprint2-review.pages.dev.

Alpha

Agent Telemetry

Trace export, LLM judges, eval configuration, span detail, error diagnostics. Built natively inside Kindo. Shaped for requirements finalization — your input refines it.

Research Complete

Platform Compatibility

Five platforms mapped — Anthropic, Azure AI Foundry, MS Copilot, ServiceNow, AWS Bedrock. Per-platform API capabilities documented for discovery and governance.

Architecture Defined

Three-Pillar Framework

Platform integrations, LLM gateway, network monitoring. Co-designed at the Jul 10 session. Three complementary approaches to AI governance.

The Five Governance Objectives

Each objective from the Jul 7 scope definition connects to a different part of the architecture. Objectives 1 and 2 require discovery of AI activity outside Kindo — the enterprise-wide challenge. Objectives 3–5 are addressable through the telemetry alpha.

1. Unauthorized Agent Deployment
Pillar 1 platform discovery probes external platforms to find AI activity outside Kindo. Once discovered and routed through Kindo, telemetry provides ongoing governance. Pillar 1 + Telemetry
2. Unauthorized Tool/Data Connections
Pillars 1 + 3 surface unauthorized connections via API probing and network-level detection. For sanctioned workloads, MCP Gateway enforces real-time tool access policies. Pillars 1 + 3 + Gateway
3. Agent Behavioral Drift
LLM Judges score every agent run against standard operating procedures defined in natural language. Alpha ready — criteria to be co-defined. Alpha
4. Guardrail/Policy Changes
Configuration visibility per agent. Change tracking and audit trail on roadmap. Roadmap
5. Cross-Tenant Contamination
Organization-isolated workspaces with per-org trace storage. Demonstrated in alpha. Alpha

Proposed Direction for Sprint 3

Recommendation

Lead With Shadow AI Discovery — Pillar 1 First

Enterprise-wide visibility before deep governance
Objectives 1 and 2 are about AI activity happening outside Kindo — agents and connections that aren't known or sanctioned yet. Sprint 3 should build a working Pillar 1 integration that discovers, enumerates, and classifies AI activity on at least one external platform. Agent telemetry alpha continues to be refined in parallel — particularly LLM Judges, which need SOC behavioral criteria to finalize.

Sprint 3 deliverable: Working discovery integration. Discover → enumerate → classify → route into Kindo. Judges configured with co-defined eval criteria.

Platform Priority — Ranked

Recommended

Azure AI Foundry

Full admin API surface, enterprise relevance for Deloitte, covers the Microsoft stack where most shadow AI activity lives. Highest strategic value.

Alternative

Anthropic Console

Fast-start option — simpler API, proven in Sprint 2 alpha. Lower strategic value but faster to production-ready. Good fallback if Azure API access takes time.

Not Recommended

Defer Discovery

Another sprint of alpha refinement without discovery delays enterprise-wide visibility — the core differentiator. Objectives 1 and 2 stay unaddressed.

Three-Pillar Architecture

1

Platform Integrations

Reach into Anthropic, Azure, Copilot, ServiceNow, Bedrock via admin APIs. Enumerate agents, audit usage, inspect configs. The discovery layer.

2

LLM Gateway

Kindo as inference proxy. Real-time governance at the choke point. Kush endorsed Jul 16. For sanctioned workloads.

3

Network Monitoring

Shadow AI beyond managed platforms. Network and endpoint-level discovery. Requires detection engineering expertise to scope.

Topic 2 · Observability

Current State & Proposed Direction

Observability has been a consistent priority from the program sessions. The upcoming Kindo platform release introduces foundational changes to the telemetry infrastructure. Here's where things stand and where we propose to go.

Current State

What Exists Today

  • No central log collection in Kindo out of the box
  • Makeshift hourly log retention on bastion host as stopgap
  • Token cost attribution not yet available
  • No native failure alerting — separate products required
Coming

Next Platform Release

  • Clickhouse-backed telemetry storage — structured trace data
  • OTel-based pipeline — Kindo ingests traces from any AI workload
  • Foundation for the SOC for AI eval and governance layer
  • Detailed roadmap coordination with engineering pending
Recommendation

Three Observability Priorities for Sprint 3

Ranked by impact on EBITDA visibility and SOC operations
Based on the program sessions, three observability requirements surfaced as highest priority. These strengthen the telemetry foundation that SOC for AI and Swimlane transition both depend on.

1. Token cost attribution — Critical for EBITDA visibility and Swimlane transition costing. Required for any cost comparison with existing tooling. Without this, the economic case for Swimlane replacement stays theoretical.

2. Failure alerting — Native notifications — email, Jira ticket creation, webhooks — without depending on separate products. SOC workflows need immediate failure notification.

3. Central logging — Replace the bastion host stopgap with the Clickhouse-backed pipeline from the upcoming release.

Note

Detailed observability roadmap from the engineering team is pending coordination. The priorities above are based on program session requirements — engineering timeline and sequencing to be confirmed.

Topic 3 · Swimlane Transition

What We've Learned & Where We Need Your Input

We've been working with the operations team to understand the full scope of the potential Swimlane-to-Kindo transition. The scope is substantially larger than the triage handoff in production today. We'd rather size this together with leadership than work from assumptions.

Timeline

November 2026
Decision point. Go/no-go on Swimlane replacement. Enough has to be validated by this point to make the call.
December 2026
Contract renewal window. Swimlane contract renewal notice deadline. Decision needs to be made before this.
Mid-January 2027
Migration complete. If transitioning, migration needs to be finished by this date.
February 2027
Swimlane contract end. Current contract expires.

What We've Learned From Discovery Sessions

Scale

Production Usage Is Extensive

Swimlane handles client alert injection, normalization, playbook execution, and SOC workflows. 80% of MXDR customers use Swimlane. Heavy daily volume across clients — email ingestion, format transforms, Jira integration. The scope goes well beyond the triage handoff currently running in Kindo.

Architecture

Kindo's Approach

Kindo is an agent-first platform. Agents orchestrate deterministic code in sandbox environments — without tokens entering the LLM context window. Agent as control layer, not deterministic engine. Inference costs drop with each model generation.

Recommendation

Size the Transition Together Before Committing

Scope first, then roadmap
The transition scope is larger than initially visible. Before committing to a migration timeline, we need to align on three things: the full inventory of Swimlane playbooks that would need to migrate, the cost structure (bench headcount vs. billed hours across customer engagements — these are different numbers), and a realistic timeline given the November decision point. We'd rather present a credible plan than an optimistic one.

What we propose for Sprint 3:

1. Playbook inventory — Complete mapping of Swimlane playbooks, classified by complexity and migration effort.

2. Token economics model — Per-playbook cost comparison: Swimlane (license cost, operational headcount) vs. Kindo (inference cost per run, including deterministic execution paths). Requires validated cost structure inputs — not assumptions.

3. Proof point — One representative playbook migrated end-to-end. Validates the pattern before committing to full migration.

Context

Token economics and inference cost may already be accounted for in the original due diligence. If so, we align our model to those assumptions. If not, we build the cost model together with validated inputs — bench headcount, billed hours per customer engagement, and current Swimlane license cost.

Next Steps

What We Need to Start Sprint 3

Your input from this session directly shapes Sprint 3 scope across all three topics.

SOC for AI

  • Confirm platform priority — we recommend Azure AI Foundry first
  • Provide SOC behavioral criteria for LLM Judge eval configuration
  • Confirm discovery scope for Sprint 3

Observability

  • Confirm priority ordering — cost attribution → alerting → logging
  • Alerting delivery requirements — email, Jira, webhooks
  • Engineering roadmap coordination for platform release timing

Swimlane

  • Validate cost structure — bench headcount vs. billed hours across engagements
  • Playbook access — for inventory and complexity classification
  • Confirm whether token economics surfaced in original due diligence
Sprint 2 Review

Full Sprint 2 delivery details, platform compatibility matrix, architecture documentation, and current status at sprint2-review.pages.dev.