Kindo × Deloitte
Sprint 2 Review · Jul 25, 2026
Sprint 2 · SOC for AI

From Objectives to Working Platform

Sprint 2 focused on translating Deloitte's SOC for AI governance objectives into platform capabilities. This review maps each objective to what was built, what was researched, and what's next for the co-design session.

01 · Foundation

Deloitte's SOC for AI Objectives

Five governance objectives defined by Kishore's team (Jul 7, 2026). Focus: monitoring risks from known AI agents/platforms — not shadow AI discovery, which is handled by Deloitte's detection engineering team.

Implementation requires two things: (1) audit logs/telemetry data from the platform and (2) process/data collection architecture to monitor for these risks.

Objective 1
Detect Unauthorized Agent Deployment
Detect when unauthorized users are deploying new agents or updating existing agents.
How it's delivered: Agent Telemetry — every agent is visible in the catalog with creator, last updated, and type. Telemetry export captures every run, creating a full audit trail of agent activity.
Objective 2
Detect Unauthorized Tool/Data Connections
Detect when new integrations to unauthorized tools/sensitive data sources are added.
How it's delivered: Trace detail view shows every tool call an agent makes — which tools, what arguments, what data was returned. The "Grounded tool use" eval automatically flags agents using tools outside expected patterns.
Objective 3 · Biggest Engineering Need
Detect Agent Behavioral Drift
Detect when actions performed are NOT in-line with the SOPs defined for the agents, like deleting JIRA tickets or sending data to unauthorized external data stores.
How it's delivered: LLM Judges — plain-language evals that automatically score every agent run. Define "polite tone," "no fabricated data," "grounded tool use" — the judge flags drift run-by-run. 4/4 satisfied = compliant. 0/4 = drift detected. This is the compound learning mechanism Kush prioritized.
Objective 4
Detect Guardrail/Policy Changes
Detect changes in MCP/tool policies to provision edit/delete privileges to agents when not intended.
How it's delivered: Configuration panel — telemetry export, sampling rate, trace retention, and eval configurations are all visible and auditable per agent. Changes to these settings create a traceable record.
Objective 5
Detect Cross-Tenant Data Contamination
In the multi-tenant environment, detect data breach/contamination when agent for one client cross references data of another client.
How it's delivered: Organization-isolated workspaces — traces are stored in each organization's isolated workspace. Cross-tenant isolation is enforced at the platform level. Trace inspection shows exactly what data each agent accessed.
02 · Evidence

Agent Telemetry — Working Demo

Live walkthrough of the Agent Telemetry capabilities built into the Kindo platform. This is not a mockup — it's the actual platform running with real agent traces, LLM judges, and eval verdicts.

Demo video available — 1:07 walkthrough of Agent Telemetry in Kindo.

Presentation video →  ·  Raw demo →

Agent Telemetry · Library Concierge · Jul 17, 2026

What the Demo Shows

Agent Catalog
Full inventory of deployed agents
Every agent visible — name, type, creator, last updated. One-click access to telemetry view.
Traces
Every run captured and inspectable
Model calls, tool activity, token usage, latency, cost, and LLM judge verdicts — per run. Stored in org-isolated workspace.
Evals & Judges
Plain-language behavioral monitoring
Define judges in natural language. Multiple judge models available (Claude, GPT). Automatic scoring on every exported run.
Trace Detail
Full drill-down into any run
Span waterfall, conversation replay, tool calls with arguments and results, token metrics, cache hit rates, error diagnostics.
Configuration
Governance controls per agent
Telemetry export toggle, sampling rate, trace retention, eval judge model selection — all configurable per agent, per organization.
03 · Architecture

Three-Pillar Discovery Framework

Charlie's framework, confirmed by Kush and Krishna at the Jul 10 co-design session. Three approaches to AI governance discovery — each platform has different strengths.

Pillar 1

Platform Integrations

Reach into Anthropic, Azure Foundry, Copilot, ServiceNow, Bedrock via their admin APIs. Enumerate agents, audit usage, inspect configurations.
Pillar 2

LLM Gateway / Choke Point

Kindo as inference proxy — 2 lines of config to redirect. The LLM is the firewall. Real-time governance at the choke point. Kush: "The choke point IS the governance layer."
Pillar 3

Network/Endpoint Monitoring

Sweep for shadow AI — the long tail. Network and endpoint-level discovery of unauthorized AI usage beyond managed platforms.
04 · Commercial Model

Discovery Tier Model

Krishna's CrowdStrike analogy — a menu of discovery options, not one-size-fits-all. First version: "less intrusive" detection and response post-action.

Basic

Detect & Respond Post-Action

Telemetry export + audit log analysis. After-the-fact detection. Low adoption cost. Entry point for governance.
Standard

Monitor & Alert Live

Native telemetry + LLM judges scoring every run. Real-time drift detection. Configurable evals and alerting thresholds.
Elite

Preventative Blocking

Gateway position (inference + MCP) = real-time preventative control. Block unauthorized actions before they execute. Requires Pillar 2 gateway integration.
05 · Research

Platform Compatibility Matrix

Per-platform capabilities for discovery and governance actions. Determines which tier model and which pillar applies to each platform in a customer's environment.

Capability Anthropic Azure AI Foundry Microsoft Copilot ServiceNow AWS Bedrock
List models/agents ✓ API ✓ ARM API ~ Graph + Studio ~ Table API ✓ API
Usage/audit logs ~ Limited ✓ Azure Monitor ✓ Purview ✓ System logs ✓ CloudTrail
Content/safety filters ✗ Not via API ✓ Full API ~ DLP policies ~ Admin config ✓ Guardrails API
Disable/block access ✓ Key revocation ✓ RBAC + Policy ✓ Entra ID ✓ Role-based ✓ IAM + SCPs
Enforce policies ✗ No policy API ✓ Azure Policy ✓ DLP + labels ~ Workflows ✓ Guardrails + SCPs
Alerting/notifications ✗ None ✓ Monitor Alerts ✓ Sentinel ✓ Event Mgmt ✓ EventBridge
Best Kindo method Gateway (P2) API + Gateway (P1+2) API + Network (P1+3) API + Network (P1+3) API + Gateway (P1+2)

✓ Full API  ·  ~ Partial  ·  ✗ Not available

Key Insight

No single discovery method works across all platforms. This is why Krishna's CrowdStrike analogy is right — customers need a menu of discovery methods, deployed based on: which platforms are in their environment, network disposition (gateway possible?), and governance maturity (Basic/Standard/Elite).

Kindo's advantage: it can operate at all three pillars simultaneously. Rich admin APIs (Azure, Bedrock) → Pillar 1. Limited admin APIs (Anthropic) → Pillar 2 gateway fills the gap. Shadow AI → Pillar 3 catches the rest.

06 · Standards

Kindo's Three Open Standards

Kindo reaches governance outcomes on three existing open standards — no proprietary protocol adoption required.

Standard 1 · Live Today

Inference APIs

Chat Completions, Responses, Messages, Models. 2 lines of config to route Claude Code, Copilot, or any agent through Kindo.
Standard 2 · Live Today

Federated MCP Gateway

Single governed endpoint for tool/integration access. Real-time control over agent tool use across the organization.
Standard 3 · Landing Now

OpenTelemetry

OTLP-based. Kindo ingests traces from any AI workload — completing the Inference + Tools + Telemetry trifecta. Foundation for evals, self-improvement, and governance.

Inference + Tools + Telemetry = comprehensive AI governance. Open standards = low adoption cost. Gateway position is cheap and reversible — addresses "customers worry about choke point."

07 · Sprint Status

Sprint 2 Backlog — Jul 13–25

Delivered

Agent Telemetry — Native Platform Capability

Working prototype: trace export, LLM judges, eval configuration, span detail, error diagnostics. Demo video available.

Delivered

Platform Compatibility Matrix

5-platform research (Anthropic, Azure, Copilot, ServiceNow, Bedrock). Per-platform discovery/action capabilities mapped to three pillars.

Delivered

Pillar 2 Gateway/Shim Architecture

Kush endorsed gateway approach (Jul 16). Three-standard strategy documented. Inference + MCP + Telemetry trifecta.

Delivered

OTel/MLflow Architecture Design

Two-tier model: export out (alpha) vs native pillar. MLflow adoption proposal with working prototype. Integration patterns documented.

In Progress

Discovery Menu of Options (CrowdStrike Model)

Krishna-facing deliverable. 5-7 discovery methods with tier mapping. Dependent on Platform Matrix (complete) — synthesis in progress.

Blocked

Digital Twin L2/L3 Analyst Pilot

Teams integration blocked on Deloitte IT. Krishna circling back internally. Sprint 2 goal was discovery — how to do this. Moved to Sprint 3.

Blocked

Triage Agent Optimization

Requires work session with Zun. Kush OOO Jul 21-25. Moved to Sprint 3.

Blocked

A7 Quality Audit Agent Design

Depends on digital twin approach + design session with Krishna's team. Sprint 3.

08 · Next

Co-Design Input Requested

For the next co-design session (~August), we'd like to walk through these capabilities with your team and get input on:

Kindo × Deloitte · Sprint 2 Review · T&C Collaboration · Jul 2026