What the platform provides today and what we build next — prepared for Friday's working session with Kishore's team.
Following Kishore's clarification of SOC for AI objectives, this document maps existing Kindo platform capabilities against each objective. Shadow AI discovery (finding unknown AI tools across the enterprise) is handled by Deloitte's detection engineering team through SecOps use cases. SOC for AI for Kindo focuses on monitoring and governing the agents built on the platform — detecting unauthorized changes, behavioral drift, and data contamination.
Each of Kishore's five SOC for AI objectives mapped against current platform capabilities, identified gaps, and sprint targets.
GET /v1/agents/list)Alerting workflow — detection rules that fire when an unauthorized user creates or modifies an agent. The data exists; the monitoring layer does not.
Sprint 2 — build the alerting and detection rules layer on top of existing audit data.
GET /v1/agents/list), audit logging for workflow/agent create-update-delete, full version history/restore. Missing: Out-of-the-box alert for "unauthorized user created/changed agent" — data exists, detection workflow needs to be built on top.GET /v1/integrations/connections)Scope monitoring — cross-reference agent tool calls against allowed integrations per SOP. Current controls prevent unauthorized access but don't detect scope violations within authorized integrations.
Sprint 2 — scope violation detection against SOP-defined integration boundaries.
GET /v1/integrations/connections), org/user-group tool access controls, pinned connection handling, audit logs for tool invocations. Missing: First-class alerting for "new sensitive integration added" or "agent started using new data source."SOP compliance monitoring engine — compares agent actions against SOP / skill file definitions over time, flags deviations. This is the primary build target and the most IK-dependent objective. No behavioral baseline or anomaly detection exists today.
Sprint 3 (design in Sprint 2) — requires IK design session with SME to define SOP compliance baselines.
Change detection and alerting — automated diff and notification when guardrails or policies change. Data exists; monitoring layer does not.
Sprint 2 — automated diff + notification on policy changes.
Cross-org detection — "agent for client A referenced client B data" beyond audit logs + existing guardrails. Prevention is strong; detection is the gap.
Sprint 3 — depends on multi-tenancy architecture confirmation.
The building blocks for SOC for AI governance monitoring are largely deployed. The gap is the monitoring and alerting layer — not the underlying data.
Linear tickets tracking governance enhancements: ENG-8737 (improved audit logging), ENG-10042 (org-level tool access controls), ENG-8539 (principle of least privilege), ENG-8654 (agent security primitives), ENG-8453 (multi-tenancy & isolation).
Kindo's REST API and audit infrastructure provide the data substrate for all five SOC for AI objectives. These endpoints enable programmatic governance monitoring.
GET /v1/agents/listGET /v1/agents/{agentId}GET /v1/integrations/connectionsGET /v1/runs/{runId}GET /v1/runs/{runId}/evalsGET /v1/modelsActive and planned Linear tickets that directly support SOC for AI governance capabilities.
The approach to SOC for AI demonstrates the value of continuous requirements mapping and rapid capability assessment. When scope clarification arrived, the team produced a complete capability mapping against all five objectives within hours — drawing on existing platform documentation, API surface analysis, governance architecture verified in prior sprints, and engineering assessment. This velocity comes from maintaining living knowledge of the platform architecture, not from starting fresh each sprint.