What Security Platform gives your team
These capabilities map to the Security Platform workspace in YottaBot — Incident Response (Incidents, Investigations), Assessments (Pen Tests, Threat Analysis), Documents (Findings, Runbooks), and Settings — all governed by the same identity, policy, and audit as the rest of the control plane
- 01Security incidentsSecurity incidents are canonical Issues tickets filtered to security — severity, on-call, and lifecycle stay in one system of record, not a parallel security tracker. Every state change carries a Yotta Identity principal and audit trail
- 02Security investigationsMulti-hop investigations across identities, secrets, network paths, service dependencies, and recent changes — each hop grounded in a live Yotta Context node, not a hallucinated relationship, and each write limited to investigation artifacts rather than customer infrastructure
- 03Scoped pen testsPen tests are governed workflows, not ad-hoc prompts: explicit scope over known Context resources, passive or safe authenticated checks by default, active mode off until approved, a deployment target, a time window, live logs, and a stop control
- 04Threat analysisRead-heavy, Context-first analysis of attack paths, exposure, identities and grants, and secret blast radius — bounded graph walks feed the model answer-shaped evidence instead of raw enterprise-scale lists. Secret exposure uses trust edges and metadata; agents never read secret values
- 05Evidence-backed findingsFindings are first-class security records — severity, confidence, status, owner, affected Context resources, cited evidence, recommended remediation, and a link back to the source investigation or assessment run — not free-floating markdown
- 06Security runbooksCurated security runbooks drawn from the native Documents product, filtered by a configured directory or tag — containment and response procedures kept beside the findings and investigations they support, versioned in one knowledge base
- 07Governance & deployment targetsPrefixed security permissions, explicit scope, approval gates for active work, and a deployment-target cluster/namespace on every run — the same governance model your agents already run under, so security work is auditable end-to-end