Three targeted questions plus four recommendations for Kishore's team — designed to confirm scope and unlock Sprint 2 build.
How is multi-tenancy implemented in Deloitte's managed Kindo deployments? Separate Kindo instances per client, or a shared instance with organization-level isolation?
This determines the detection approach for Objective 5 (cross-client data contamination). The platform has strong prevention controls — tenant-scoped memory, cross-tenant referent checks on import, pinned-connection logic. Detection of contamination requires understanding whether cross-client data flows are even architecturally possible, and if so, where the boundaries are.
Is the audit log exporter currently active in your managed environments? If so, which SIEM (Splunk, Datadog, or other) is the SOC team consuming alerts from?
This determines whether we build the monitoring agent inside Kindo (consuming audit events directly) or push detection alerts into your existing SIEM pipeline. The audit log captures all five categories of events Kishore described. The question is where your team consumes them.
For Objective 3 (behavioral drift from SOPs) — is there a formal SOP compliance review today? For example, do analysts currently audit a sample of agent runs against the SOP definitions, or is this a new capability? If a review exists, what does "in-line with the SOP" mean in practice — what are the specific criteria?
This determines whether we're digitizing an existing process or creating a new one. If a manual review exists, we can encode its criteria directly. If not, we'll need an SME (we recommend the Engineering Lead) to establish the baseline through direct interaction with the agent.
Objectives 1 (unauthorized deployment) and 4 (policy/guardrail changes) can be delivered via an audit log monitoring agent in Sprint 2. The platform already captures all relevant events with full metadata. We build detection rules and alerting on top of existing telemetry — no new platform instrumentation required.
Objective 2 (unauthorized integration connections) builds on existing Tool Action Access Controls and audit logging. The monitoring agent cross-references agent tool calls against allowed integration lists per SOP. Detects when an agent connects to an integration that exists in the platform but isn't in the agent's intended scope.
Objective 3 (behavioral drift from SOPs) is the most complex and highest-value objective. We propose the SME-driven approach described in the IK framework: the Engineering Lead does 2–3 hours/week of sessions with the agent on real scenarios, encoding judgment patterns into a structured evaluation curriculum. This curriculum becomes the automated standard against which all agent outputs are measured.
View Full IK Framework →We recommend starting with periodic monitoring (daily summary report) as the Sprint 1 proof-of-concept, upgrading to real-time alerting in Sprint 2. The data source is the same — only the consumption cadence changes. This de-risks the build and gives your team a working artifact within the current sprint.