Executive summary
The verdict, the architectural correction, and the design position — before any component detail.
Overall finding
The originating requirements are strong as a senior hybrid-engineer profile but materially incomplete as a platform specification. Building directly from them would likely produce an impressive SOC copilot or demonstration — not a defensible enterprise or MSSP security operations product.
The requirements describe what agents should do, but not:
- What each agent and workflow is authorized to do.
- Which evidence is trusted, untrusted, sufficient, incomplete, or contradictory.
- How tenant isolation is enforced at every service and data boundary.
- How findings are proven, replayed, audited, and challenged.
- How response actions are approved, verified, reversed, and stopped.
- What happens when models, connectors, data sources, queues, or policy services fail.
- How quality is measured against security outcomes rather than stylistic output.
- How the platform itself is secured, monitored, investigated, and recovered.
Core architectural correction
Do not treat “multi-agent” as the architecture. The correct pattern is a deterministic, policy-controlled security platform containing bounded probabilistic components.
Identity, policy, evidence, workflow state, approval, execution, verification, and audit remain outside model discretion — implemented by deterministic services that bind every operation to a tenant, case, workflow, and actor identity.
Ten mandatory design principles
P01 · Evidence before narrative
Every material conclusion identifies supporting and contradicting evidence. A persuasive summary is not a finding.
P02 · Least agency
Each agent gets the minimum tools, data, duration, context, and authority for one bounded responsibility. No universal SOC agent.
P03 · Read-only by default
Side effects require a separate deterministic response workflow. Read-only still gets scopes, quotas, masking, and full audit.
P04 · Human accountability
Sensitive actions require identifiable human approval and complete attribution — who, what evidence, which policy, what result.
P05 · Decision traces, not chain-of-thought
Store structured traces: evidence, queries, tools, versions, approvals, decisions. Hidden model reasoning is not the audit artifact.
P06 · Replayable by design
Evidence, mappings, models, prompts, agents, tools, policies, and workflows are versioned so any decision can be reconstructed.
P07 · Tenant isolation by design
Isolation exists at routing, identity, data, encryption, queue, storage, policy, observability, and operational layers — never a tenant_id column alone.
P08 · Fail closed for authority, open for visibility
Policy, approval, or audit failure stops high-risk action. Alert receipt, raw evidence, and analyst visibility continue when safely possible.
P09 · Deterministic where possible
No AI agent for work that code, rules, parsers, or queries do more reliably. Each agent must beat the deterministic baseline in benchmarks.
P10 · No unsupported claims
Nothing is called compliant or secure without stating how it is implemented and verified. Assumptions are labeled ASSUMPTION.
How to read this artifact
Press / to search. Click any node in the Overview for its contract: purpose, data, controls, failure modes, owner, open items. Amber chips mark trust-zone boundaries; violet marks probabilistic components.
Honesty register
Severity ratings, owners, runbook procedures, and ADR positions are recommended baselines from this review — not customer commitments or compliance claims. Open items are listed under Open Decisions.
Critical gap analysis
What the original requirements get right, and precisely where they are incomplete. Severity is assessed in this review: Critical = unsafe to ship without it · High = unsafe to scale without it · Medium = quality/operability debt.
1 · Product and requirements definition
| Area | Current position | Critical gap | Required correction | Severity |
|---|---|---|---|---|
| Product boundary | “AI-driven security operations platform” | Supported and unsupported use cases are undefined. | Define precise initial workflows: triage, enrichment, investigation assistance, response recommendation, gated execution. | Critical |
| Operating model | Enterprise and managed environments | Enterprise SOC vs MSSP delegation, reporting, data access, and authorization differ materially. | Define enterprise, MSSP, regulated, sovereign, and customer-managed operating modes. | High |
| Autonomy | “Read-only by default” | No formal autonomy or action-risk model. | Define risk classes R0–R5, approval requirements, prohibited actions, kill-switch behavior. | Critical |
| Multi-agent design | Assumed foundational | No proof that multiple agents outperform simpler workflows. | Require benchmark evidence before introducing each agent or handoff. | High |
| Investigation quality | General methodology | No completeness criteria, pivot requirements, or stop conditions. | Define mandatory pivots, evidence standards, collection gaps, escalation, closure criteria. | High |
| Evidence | Mentioned indirectly | No canonical evidence, provenance, or chain-of-custody model. | Immutable evidence objects with source, query, timestamps, hashes, transformations, retention. | Critical |
| Confidence | “Escalate when confidence is low” | Model self-confidence is uncalibrated and misleading. | Use calibrated workflow risk scores and explicit evidence sufficiency — not model-reported confidence. | High |
| Human accountability | Approval gates mentioned | No responsibility or authority matrix. | Define analyst, investigator, incident commander, tenant admin, approver, responder, auditor roles. | Critical |
| Case management | Not specified | Alerts, investigations, incidents, findings, actions lack a lifecycle model. | Formal case state machine with ITSM/SOAR integration. | Medium |
| Service objectives | “Balance quality, latency, cost” | No measurable SLOs or release thresholds. | Workflow-specific security, reliability, performance, safety, and cost targets. | High |
| Failure handling | “Fail-safe escalation” | No failure taxonomy or degraded-mode behavior. | Define handling for model, connector, data, policy, audit, workflow, approval, execution failures. | High |
| Deployment model | “Major cloud platforms” | SaaS, hybrid, sovereign, private, air-gapped boundaries unclear. | Declare supported deployment patterns and shared-responsibility boundaries. | Medium |
| Ownership | One hybrid role | Role implicitly owns AI, SOC, integration, tenancy, SRE, platform security, and product controls. | Cross-functional product and platform team with explicit design authority. | Critical |
2 · AI and agent architecture
| Area | Missing requirement | Consequence | Required design | Severity |
|---|---|---|---|---|
| Agent contracts | No typed I/O, permissions, budgets, ownership, or stop conditions. | Inconsistent behavior; untestable permissions. | Versioned contracts: schemas, allowed tools, data classes, budgets, pre/postconditions, evaluation suites. | Critical |
| Durable orchestration | Framework-level agent state implied. | Work lost, duplicated, or resumed incorrectly. | Durable workflow engine: checkpoints, idempotency, retries, compensation, replay, human waits. | High |
| Agent identity | Not defined. | Actions cannot be strongly attributed or authorized. | Unique workload identity per agent, workflow, worker, connector, actuator. | Critical |
| Memory | No working / case / tenant / long-term memory model. | Cross-tenant leakage, poisoning, stale context, cost growth. | Separate ephemeral working context from authoritative case evidence and governed long-term memory. | Medium |
| Context construction | Not defined. | Irrelevant or hostile evidence may control model behavior. | Context builder that classifies trust, redacts, delimits, minimizes, binds objects to tenant and case. | Critical |
| Prompt hierarchy | Not defined. | System, tenant, playbook, user, evidence instructions may conflict. | Enforceable precedence outside prompts; evidence never alters system policy. | High |
| Tool security | “General tool integration.” | Over-permissioned, arbitrary, unsafe calls. | Typed tool broker: schema + semantic validation, scopes, quotas, egress control, audit. | Critical |
| Model gateway | Multiple providers expected, no control point. | Lock-in, inconsistent policy, uncontrolled data transfer, opaque changes. | Centralized routing, policy, redaction, version pinning, fallback, budgets, provider assurance. | High |
| Open-weight models | Mentioned for privacy/latency only. | No artifact integrity, GPU isolation, patching, capacity, or acceptance criteria. | Approved model lifecycle: hashes, provenance, vulnerability process, benchmarks, isolation. | High |
| Structured outputs | Required but conflated with correctness. | Syntactic validity mistaken for factual or semantic correctness. | Validate syntax, semantics, evidence references, authorization, and workflow conditions separately. | Medium |
| Hallucination control | Not specified. | Plausible but unsupported findings accepted. | Evidence-linked claims; visibly mark unsupported or assumed statements. | High |
| Prompt injection | Acknowledged only generally. | No untrusted-evidence security architecture. | Treat logs, emails, tickets, filenames, URLs, tool responses as hostile by default. | Critical |
| Model fallback | Not defined. | Provider failure can halt incident response. | Deterministic degraded mode and tenant-approved model fallback. | High |
| Model changes | Not defined. | Silent provider updates alter decisions. | Pin versions where possible; regression, shadow, canary, rollback, inventory updates. | Medium |
| Fine-tuning | Listed as preferred experience. | No tenant consent, data provenance, contamination, isolation, or rollback rules. | Permit only under explicit governance and dataset lineage controls. | Medium |
| Kill switch | Not specified. | Unsafe workflows cannot be rapidly stopped. | Global, cell, tenant, workflow, agent, tool, model, and action-level disable controls. | Critical |
| Replayability | Not specified. | Decisions cannot be reconstructed after changes. | Persist versioned evidence, mappings, models, prompts, tools, policies, workflow definitions. | High |
3 · Platform security and tenant isolation
| Layer | Missing capability | Risk | Required design | Severity |
|---|---|---|---|---|
| Threat model | No platform threat model. | Critical trust-boundary and abuse paths remain invisible. | Threat-model tenant data, identities, agents, tools, models, connectors, actions, audit, CI/CD, admin access. | Critical |
| Human identity | No SSO, federation, MFA, provisioning, or privilege model. | Weak access governance. | OIDC/SAML, SCIM, phishing-resistant MFA, conditional access, JIT privilege, break-glass, session control. | High |
| Authorization | “Strong tenant isolation” is too general. | Authorization devolves to app code and tenant filters. | RBAC plus ABAC and policy-as-code at every service and resource boundary. | Critical |
| Workload identity | Not specified. | Shared credentials; poor attribution. | Short-lived workload identity with tenant-bound claims; mTLS everywhere. | High |
| Secrets | Not specified. | Credentials leak into prompts, traces, logs, or code. | Central secret manager, secret references, short-lived tokens, rotation, separate read/action credentials. | Critical |
| Encryption | Not specified. | Inconsistent protection; weak tenant separation. | TLS/mTLS, envelope encryption, tenant DEKs, KMS/HSM roots, customer-managed keys where required. | High |
| Network segmentation | Not specified. | Compromise traverses ingestion, inference, data, and execution planes. | Separate the twelve trust zones with private endpoints and egress control. | High |
| DLP and privacy | Not specified. | Sensitive data exposed to models, users, logs, providers. | Pre-inference classification/redaction, egress policy, output filtering, minimization, residency enforcement. | High |
| Connector compromise | Not specified. | A compromised connector becomes a privileged path. | Per-connector capabilities, scopes, credentials, signing, health, egress allowlists, limits, isolation. | High |
| Insider & support risk | Not specified. | Privileged staff access customer security data without adequate controls. | Separation of duties, customer-approved support access, recording, time limits, immutable audit. | Medium |
| Platform incident response | Not specified. | The security product itself is unprepared for compromise. | Platform-specific IR plans, forensic logging, credential revocation, tenant notification, recovery exercises. | High |
| Vulnerability management | Not specified. | Unknown exposure in code, images, infrastructure, dependencies. | SAST, DAST, SCA, IaC, secrets, container, runtime scanning; patch SLAs. | Medium |
| Supply chain | Not specified. | Compromised models, packages, prompts, datasets, or builds. | Signed builds, provenance, SBOM, AI/ML-BOM, dependency pinning, artifact admission, revocation. | High |
| Audit protection | Auditability stated as a principle only. | Incomplete or alterable records fail customer, legal, forensic scrutiny. | Append-only, tamper-evident, independently retained audit and decision records. | Critical |
| Deletion & offboarding | Not specified. | Residual customer data and credentials persist. | Cryptographic erasure, backup expiry, legal-hold handling, access revocation, verified offboarding reports. | High |
| Business continuity | Not specified. | Security operations stop during provider or regional failure. | Backup, restore, regional resilience, provider fallback, queue protection, tested degraded modes. | Medium |
4 · SOC and detection-engineering definitions still required
- Deduplication, correlation, suppression, maintenance windows, incident promotion.
- Severity normalization using asset criticality, identity risk, business context, threat confidence.
- Evidence sufficiency, contradictions, incomplete telemetry, collection-gap handling.
- Pivot strategies, time-window expansion, query limits, source-specific validation.
- TI source reliability, confidence, expiration, revocation, deconfliction.
- Detection ownership, tuning, exceptions, staged deployment, rollback, health.
- Disposition taxonomy, analyst disagreement, reopen criteria, post-incident learning.
- MSSP customer-specific policy, delegated administration, reporting, response authorization.
- ATT&CK mapping governance — coverage is not proof of detection effectiveness.
Where the gaps land in this architecture
Every gap above maps to a component or control in this artifact:
- Authority and autonomy → Response Controls (R0–R5, approvals, kill switch).
- Evidence and provenance → Data & Evidence (immutable store, schemas, lineage).
- Injection and context → Security (context builder, untrusted-evidence controls).
- Isolation → Multi-Tenancy (cells, tiers, keys, negative testing).
- Quality → Evaluation (five levels, zero-tolerance metrics, release gates).
- Reconstruction → Observability (telemetry vs audit vs decision ledger).
- Sequencing → Roadmap (authority ships last, behind exit criteria).
The structural finding — a single hybrid role owning everything — is addressed in Roadmap → Team & ownership.
Architecture overview — the whole platform on one canvas
Click any node for its full contract: purpose, data handled, trust zone, dependencies, controls, failure modes, owner, and open decisions. Use the path toggles to trace how an alert, a response, or hostile evidence moves through the system.
Primary pipeline — ingestion to disposition
Control plane and data plane are separated; read-only investigation (Z8) and side-effecting response (Z9) run with different identities, credentials, and network paths.
Architecture layers L01–L20
The complete layer catalog. Expand a layer for its components — chips open the same detail panel as the Overview. Components without a dedicated catalog entry are listed as capabilities of their parent service.
L01 · User experience & analyst workspace Z1
Consoles for analysts, incident commanders, MSSP operators, tenant admins, detection engineers, evaluators, and auditors. The case timeline visibly separates source evidence, normalized evidence, AI inference, deterministic rules, assumptions, recommendations, and executed actions. AI text never renders as verified fact unless linked to validated evidence.
Analyst & IC consoleMSSP workspaceTenant admin portalDetection workspaceEvaluation dashboardAudit portalAPI & CLI
L02 · Edge & API security Z1
DNS, CDN where appropriate, DDoS protection, WAF, API gateway, rate limiting, bot/abuse protection, request validation.
Edge securityAPI gateway
L03 · Human identity & access management Z2
OIDC/SAML federation, SCIM provisioning, phishing-resistant MFA, RBAC + ABAC, conditional access, PAM, JIT elevation, break-glass with recording and separate audit.
Identity federationPAM & break-glassPolicy decision point
L04 · Workload & agent identity Z2
Unique identity for every service, agent, workflow, connector, and actuator; short-lived credentials, mTLS, workload identity federation. Authorization context includes subject, tenant, region, environment, severity, action-risk class, approval state, and data classification.
Workload & agent identity
L05 · Control plane Z3
Tenant lifecycle, entitlements, regional placement, and the registries that make every AI artifact governed: connectors, agents, prompts/playbooks (signed), models (with provider policy), policies, flags, evaluation, and the governance inventory (SBOM, AI/ML-BOM, attestations).
Tenant managementConnector registryAgent registryPrompt registryModel registryPolicy administrationFlags & entitlementsEvaluation controlGovernance inventory
L06 · Tenant & cell architecture Z3→Z5
Tenant router, regional data cells, tenant data-plane boundary, tenant encryption keys, tenant-scoped queues, storage, credentials, and quotas. See Multi-Tenancy for tiers and isolation mechanics.
Cell routerTenant managementTenant keys (KMS)
L07 · Integration & connector layer Z4/Z8
SIEM, EDR/XDR, identity, cloud, email, network, TI, ITSM/SOAR, CMDB/asset, and collaboration connectors — each with versioned capabilities, scopes, per-tenant credentials, health, limits, and side-effect classification. See Integrations.
Connector runtimeConnector registry
L08 · Ingestion & messaging Z4
Webhook receiver, polling workers, streaming ingestion, durable event bus, dead-letter queues, schema validation, deduplication, and backpressure management.
Webhook & pollersEvent busValidation & dedup
L09 · Normalization & enrichment Z4
OCSF normalization with vendor-field preservation, schema-mapping registry, entity extraction, asset/identity/TI enrichment, and data-quality scoring. A common schema improves correlation; it does not erase vendor semantics.
OCSF normalizerEnrichment
L10 · Data & evidence Z5
Immutable raw evidence store, hot search/event store, PostgreSQL transactional store (cases, findings, approvals), object storage, cache, optional vector index, lineage, retention, and legal hold. See Data & Evidence.
Raw evidence storeSearch storeCase DBCacheVector indexLineage & retention
L11 · Durable workflow orchestration Z6
Persisted state, checkpointing, retries, timeouts, compensation, human-approval waits, cancellation, replay, and workflow versioning. The engine — not an agent framework loop — owns investigation state.
Workflow engine
L12 · Context & evidence construction Z6
Context builder, evidence trust classifier, prompt-injection detection, content sanitization, redaction, retrieval policy, context limits, and evidence references. The only doorway between untrusted evidence and any model.
Context & evidence builderDLP & classification
L13 · Agent services AI Z6
Twelve specialized bounded agents — triage, correlation, investigation planning, evidence collection, identity, endpoint, cloud, threat-intel, detection drafting, response planning, reporting, quality review. See Agents.
Specialized agent services
L14 · Model gateway & inference Z7
Provider abstraction, model routing, data-classification and residency enforcement, allowlisting, version pinning, token/cost budgets, fallbacks, circuit breakers, private endpoints, open-weight serving.
Model gatewayInference endpointsModel registry
L15 · Policy enforcement & tool broker Z8
PDP/PEP, typed tool registry, JSON-Schema + semantic validation, tenant binding, credential resolution at call time, query guardrails, rate limits, result filtering, and audit on every call.
Typed tool brokerQuery compilerPDP
L16 · Response planning & execution Z9
Action-risk classification, response planner, target validation, dry-run, approval workflow, dual control, short-lived execution tokens, actuator, post-action verification, rollback, kill switch. See Response Controls.
Response plannerApprovalsActuatorVerificationKill switch
L17 · Observability & audit Z10
OpenTelemetry traces/metrics/logs, token and cost accounting, agent failure analysis, security audit log, case decision ledger, tamper-evident storage. See Observability.
ObservabilityAudit logDecision ledger
L18 · Security platform services Z10/Z12
KMS/HSM, secrets management, certificate management, DLP, malware scanning, runtime security, vulnerability management, privileged-access monitoring.
KMS & secretsDLP & egress
L19 · DevSecOps & supply chain Z11
Source control, CI/CD, IaC, policy-as-code, detection-as-code, SAST/DAST/SCA, secret scanning, container and IaC scanning, SBOM, AI/ML-BOM, signed artifacts, build provenance (SLSA).
DevSecOps & supply chainGovernance inventory
L20 · Reliability & operations Z10
SLO management, capacity, autoscaling, backup, disaster recovery, restore testing, chaos testing, incident management, degraded operating modes, cost management.
Reliability operations
Agent architecture — a small set of bounded specialists
More agents are not better. An agent exists only where it measurably beats deterministic code or a simpler model call — proven in benchmarks before release. No agent holds execution authority, standing credentials, or cross-tenant scope.
Triage agent read-only
Classifies and prioritizes alerts against tenant context.
Why an agent: deterministic dedup and rules run first; the agent adds value only on ambiguous residue.
Budgets: ≤10 steps · ≤60 s · capped tokens/cost per alert.
Escalates: insufficient evidence, contradiction, policy uncertainty.
Correlation agent read-only
Finds related alerts, entities, and cases across the tenant scope.
Why an agent: entity-graph joins are deterministic; semantic similarity across noisy alerts is not.
Budgets: bounded lookback and result counts via broker.
Escalates: cross-case links touching other tenants → refused by design.
Investigation planner no direct tool execution
Selects evidence-collection steps and pivots for the case type.
Why an agent: playbook selection under partial information benefits from reasoning; execution stays deterministic.
Output: typed evidence plan; every step re-authorized at the broker.
Evidence collection agent read-only · strictly scoped
Executes approved, bounded queries from the plan via canonical query intent.
Never: raw vendor query strings to production systems.
Budgets: per-query lookback, row, volume, and cost caps.
Identity investigation agent read-only
Analyzes authentication, privilege, session, and directory activity.
Data limits: identity telemetry for the bound tenant only; PII minimized before inference.
Endpoint investigation agent read-only
Analyzes process, file, network, and endpoint telemetry from EDR/XDR.
Injection note: command lines and filenames are hostile input — delimited and never interpreted as instructions.
Cloud investigation agent read-only
Analyzes control-plane, workload, storage, and identity activity in Azure, AWS, GCP, Kubernetes.
Threat-intelligence agent read-only
Contextualizes indicators with source reliability, confidence, and expiry.
Rule: external intelligence informs; it never becomes automatically authoritative.
Detection agent draft only
Drafts or translates detection content (Sigma → KQL/SPL/CQL).
Rule: conversion is not semantic proof — drafts enter the detection-as-code pipeline, never production directly.
Response planning agent no execution
Creates action, impact, verification, and rollback plans.
Boundary: the plan is inert until the deterministic response plane validates, approves, and executes it.
Reporting agent read-only
Creates evidence-linked summaries and timelines.
Rule: every claim carries evidence references; unsupported statements are visibly marked.
Quality review agent read-only
Checks findings for evidence coverage, contradictions, and policy compliance before human review.
Rule: one signal among several — never the release authority.
Mandatory agent contract (versioned, in the agent registry)
agent_id · version · owner · purpose approved_workflows input_schema · output_schema allowed_tools · denied_tools allowed_data_classifications · tenant_scope maximum_steps · maximum_runtime maximum_input_tokens · maximum_output_tokens · maximum_cost required_evidence · preconditions · postconditions stop_conditions · escalation_conditions failure_behavior · side_effect_class evaluation_suite · release_state
An agent version cannot reach production without its contract, its evaluation suite passing, and a named owner.
Typed inter-agent handoff (the only agent-to-agent channel)
tenant_id · case_id · workflow_id · task_id requested_result evidence_refs[] — references, never raw blobs tool_permissions[] — subset of sender's own grants constraints — lookback · volume · cost · time expiration — every handoff expires required_output_schema sender_identity — authenticated workload identity
Handoffs are events on the durable workflow engine — checkpointed, replayable, and attributable. A receiving agent can hold fewer permissions than the sender, never more.
Integration architecture
Every integration is a governed connector with versioned capabilities, per-tenant credentials, and a declared side-effect class. Not every named platform ships in the first release — the matrix below is the priority order.
| Category | Representative platforms | Pattern | Capability class | Phase | Notes |
|---|---|---|---|---|---|
| SIEM | Microsoft Sentinel · Splunk · Elastic · Google SecOps | Poll + webhook + streaming | R0 read · R2 case sync | P1 | Start with one SIEM end-to-end; certify others against the same connector conformance suite. |
| EDR / XDR | Defender XDR · CrowdStrike · SentinelOne · Cortex | Streaming + API | R0 read · R3 isolate (P5) | P1 | One EDR in MVP. Response verbs stay disabled until Phase 5 gates pass. |
| Collaboration | Slack · Teams · email notifications | Outbound webhook | R1 notify/draft | P1 | Draft-only notifications; no inbound instructions accepted from chat. |
| Identity | Entra ID · Okta · Active Directory | API + event stream | R0 read · R3/R4 revoke (P5) | P2 | Session revocation and account disable are R3/R4 verbs behind approvals. |
| Cloud platforms | Azure · AWS · GCP · Kubernetes audit | Native audit feeds | R0 read | P2 | Control-plane, workload, storage, identity activity for cloud pivots. |
| Threat intelligence | STIX 2.1 / TAXII 2.1 feeds · commercial TI | TAXII poll | R0 read | P2 | Reliability, confidence, expiry, revocation, and decay preserved per source. |
| ITSM / SOAR | ServiceNow · Jira · existing SOAR | API, bidirectional | R1 draft · R2 ticket ops | P2 | Case lifecycle sync; the platform complements rather than replaces existing SOAR early on. |
| CMDB / asset | CMDB · asset inventory · DSPM | Scheduled sync | R0 read | P2–3 | Asset criticality and ownership feed severity normalization. |
| Email security | Email security gateways | API | R0 read · R3 quarantine (P5+) | P4+ | Email bodies are prime injection carriers — sanitization is mandatory before context. |
| Network security | Firewall · DNS · proxy/SASE · NDR | API + streaming | R0 read · R3 temp block (P5+) | P4+ | Firewall-wide changes are R4 dual-control; broad blocks never automated. |
| Vulnerability mgmt | VM platforms | Scheduled sync | R0 read · R2 request scan | P4+ | Context for exposure-aware prioritization. |
| SaaS audit | SaaS audit-log sources | Poll | R0 read | P4+ | Extends coverage to business-critical SaaS. |
Connector capability model
- Declared capabilities — each verb registered with schema, side-effect class (R0–R5), and cost profile.
- Authentication — per-tenant credentials from the secret manager, resolved at call time; OAuth client credentials or scoped API keys; separate read vs action credentials.
- Health model — liveness, auth validity, quota headroom, schema drift, and lag surfaced per tenant.
- Rate & retry strategy — vendor-aware budgets, exponential backoff with jitter, circuit breakers, dead-letter queues; ingestion favors at-least-once with deterministic dedup.
- Versioning & certification — connectors are versioned artifacts passing a conformance suite (schema, limits, failure injection, cross-tenant negative tests) before release.
Safe query generation — the only path for model-generated queries
Guardrails: operation allowlists, prohibited statements, maximum lookback, result-count and volume caps, timeouts, cancellation, per-tenant rate limits, query-cost monitoring, and full attribution. Unrestricted LLM-generated KQL/SPL/ CQL/SQL never reaches a production system.
Data & evidence model
Evidence is a first-class domain object with provenance and chain of custody — not text in a prompt. The original event is always preserved, even after normalization.
| Store | Holds | Explicitly not for | Notes |
|---|---|---|---|
| PostgreSQL (system of record) | Cases, findings, workflow metadata, configuration, approvals, transactional state | Bulk event storage | Row-level security + tenant keys; the authority for case truth. |
| Immutable object store | Raw evidence, reports, large query results, replay packages, legal holds | Mutation of any kind | WORM/object-lock, cryptographic hashes, strongest durability tier. |
| Hot search / event store | Interactive investigation queries over normalized events | Being the system of record | Rebuildable projection; tenant-isolated indexes where justified. |
| Redis | Cache, rate control, short-lived coordination | Durable investigation state | Loss is a performance event, never a correctness event. |
| Durable message bus | Asynchronous processing, connector decoupling, DLQs | Long-term retention | Tenant-partitioned topics; backpressure managed. |
| Vector index optional | Approved approximate-retrieval use cases only | Authoritative evidence storage | Every hit re-validated against the source of record before use. |
Minimum evidence record
evidence_id · tenant_id · case_id · alert_id source_system · source_record_id source_query · query_parameters event_time · observed_time · ingestion_time raw_object_uri · raw_hash normalized_schema · normalization_version content_classification · provenance · transformations collection_status · retention_policy · legal_hold redaction_status · access_policy
Three timestamps are deliberate: when it happened, when the source saw it, when the platform received it. Divergence between them is itself investigative signal.
Minimum finding record
finding_id · claim · finding_type · status supporting_evidence_ids[] · contradictory_evidence_ids[] assumptions · collection_gaps · attack_mappings[] severity · calibrated_risk_score · recommended_action agent_version · model_version · prompt_version · policy_version review_status · reviewer · disposition
Contradictory evidence and collection gaps are mandatory fields — their absence must be asserted, not implied. Model-reported confidence is never the risk score; calibration is empirical per workflow.
Evidence provenance flow
Every transformation appends to lineage. Replay pins the evidence set, mapping version, model, prompt, agent, tool, policy, and workflow definition — so any past decision can be reconstructed exactly (P06).
Platform security architecture
The platform guards other people's security data — it is a high-value target itself. Twelve trust zones, a hostile-evidence pipeline, engineered secret handling, and an explicit threat model.
Trust zones — separate identities, networks, and credentials
Untrusted evidence & prompt-injection containment
All external and customer-generated content is potentially hostile: logs, emails, tickets, filenames, URLs, command lines, process arguments, threat reports, endpoint artifacts, cloud metadata, tool responses, retrieved documents.
- Four instruction classes with enforced precedence outside prompts: system policy → tenant configuration → analyst instruction → untrusted evidence. Evidence can never modify policy, authority, tenancy, tool permissions, or approval requirements.
- Structural delimiting; active content stripped; embedded-instruction and suspicious-encoding detection.
- Length, nesting, recursion, and retrieval-volume limits (context flooding).
- Credential and unnecessary-PII removal before inference; source, hash, provenance preserved.
- Every retrieved object bound to the current tenant, case, and authorization decision.
- Output validation on the way back: schema, evidence references, authorization, unsupported-claim marking.
Secrets, keys, and supply chain
Secrets & keys
- Secret references in configuration — never values; resolution immediately before use; short-lived credentials preferred.
- No credentials in prompts, model context, traces, or case narratives — enforced by scanning, not convention.
- Separate read-only vs action credentials; per-tenant DEKs under KMS/HSM roots; customer-managed keys where contracted.
- Automatic rotation; revocation on offboarding or compromise; independent secret-access audit with anomaly alerts.
Software & AI supply chain
- SBOM for application, container, and infrastructure dependencies; AI/ML-BOM for models, adapters, datasets, evaluation sets, prompts, and agent configurations.
- Signed images, prompt/playbook packages, and model artifacts; admission verifies provenance (SLSA-aligned).
- Pinned model artifact hashes for local serving; approved provider/model inventory; license and vulnerability process; revocation and emergency rollback paths.
Threat model — minimum scenario set
| Scenario | Primary architectural counter | Framework lens |
|---|---|---|
| Compromised tenant administrator or analyst | ABAC + conditional access, JIT elevation, dual control on R4, session risk, behavioral audit | ATT&CK (valid accounts) |
| Malicious insider or support engineer | Separation of duties, customer-approved support access, recording, time limits, immutable audit (Z12) | NIST 800-53 AC/AU |
| Compromised connector credentials | Per-tenant scoped credentials, egress allowlists, health anomaly detection, rapid revocation runbook | ATT&CK (trusted relationship) |
| Malicious alert / log / ticket / email / filename / URL / tool response | Context builder trust classing, sanitization, delimiting, output validation, injection metrics | OWASP LLM01 · ATLAS |
| Cross-tenant attacker / confused deputy | Cell isolation, tenant-bound claims on every call, RLS, per-tenant keys, continuous negative tests | OWASP LLM · multi-tenancy |
| Compromised model provider or poisoned open-weight model | Gateway allowlist + pinning, artifact hashes, shadow comparison, provider health, emergency model disable | ATLAS (supply chain) |
| Poisoned embedding corpus or evaluation dataset | Dataset inventory + lineage in AI/ML-BOM, non-authoritative vector index, eval-set isolation | ATLAS (data poisoning) |
| Malicious agent tool / prompt / playbook / package update | Signed registries, review + release gates, admission control, revocation | SLSA · OWASP agentic |
| Compromised CI/CD pipeline or artifact registry | Build provenance, signed artifacts, admission verification, separated build zone (Z11) | SLSA |
| Audit suppression or tampering | Append-only tamper-evident store, independent retention, audit-write failure blocks R3+ execution | NIST 800-53 AU-9 |
| Response-target substitution / actuator abuse | Target re-validation at execution time, short-lived single-action tokens, post-action verification, kill switch | OWASP agentic (excessive agency) |
| Token / API / GPU / queue / cost exhaustion | Budgets at gateway and broker, quotas per tenant, circuit breakers, backpressure, cost alerting | OWASP LLM10 |
| Control-plane compromise / data-residency violation | Control-data plane separation, regional cell routing, residency enforcement at gateway, no bulk data in Z3 | NIST 800-207 |
Multi-tenant & cell architecture
Cell-based tenancy bounds the blast radius of any failure or compromise, simplifies regional isolation, and creates a credible path from shared SaaS to sovereign and customer-managed deployments.
tenant_id column is not an isolation architecture. Isolation is enforced at routing, identity claims,
API authorization, queue partitioning, database row-level security, object prefixes and policies, search indexes,
encryption keys, connector credentials, model policy, response policy, quotas, and audit — and proven by
cross-tenant negative tests on every release plus continuous runtime canaries.| Tier | Design | Typical driver |
|---|---|---|
| Standard | Shared cell, strong logical isolation: tenant-aware routing, RLS, quotas, tenant-specific encryption keys | Enterprise and MSSP customers at standard assurance |
| Enhanced | Dedicated databases, indexes, queue partitions, worker pools inside a shared cloud boundary | Noise isolation, elevated assurance, MSSP anchor tenants |
| Regulated | Dedicated cell and dedicated cloud account/subscription/project, private network, approved inference endpoints | Regulated industries; auditor-driven separation |
| Sovereign | Region-restricted dedicated cell, controlled support access, locally approved providers and models | Data-residency and sovereignty mandates |
| Customer-managed | Data plane in the customer environment; narrow, authenticated management channel; no standing platform access to data | Maximum-control customers; air-gap-adjacent needs |
Defense-in-depth checklist (all tiers)
- Tenant-aware routing and tenant-bound workload claims on every internal call.
- Separate queue topics/partitions and per-tenant quotas — no noisy-neighbor cascade.
- Database row-level security plus resource-level authorization at the API.
- Tenant object prefixes, per-tenant search isolation where justified, tenant DEKs.
- Per-tenant connector credentials; per-tenant model and response policy.
- Cell-level capacity and failure containment; cells fail independently.
- Cross-tenant negative tests in CI and continuously in production.
Offboarding & verified deletion
MSSP mode adds delegated administration: the MSSP operates many customer tenants under explicit per-customer context, per-customer policy, response authorization, and reporting — with every delegated act attributed to both the operator identity and the customer tenant.
Response controls — the action-risk model
Response planning and response execution are separate services with separate identities. The planner has no execution authority; the actuator cannot reinterpret the plan.
| Class | Examples | Default authority | Additional requirements |
|---|---|---|---|
| R0 · Observe | Query SIEM, EDR, identity, cloud, case data | Automatic under read policy | Scopes, quotas, masking, full audit — read-only is not a free pass |
| R1 · Recommend | Draft ticket, summary, containment plan, analyst message | Automatic draft | Drafts visibly marked; evidence-linked claims required |
| R2 · Administrative reversible | Tag case, assign ticket, request approved scan, enrich asset | Tenant policy-controlled | Tenant authorization policy; full attribution |
| R3 · Security reversible | Temporarily isolate endpoint, revoke session, temporary indicator block | Explicit human approval | Target validation, TTL, verification query, rollback plan |
| R4 · High impact | Disable account, broad credential revocation, org-wide or firewall-wide change | Two-person approval | Dual control, dry-run where supported, expected business impact recorded |
| R5 · Destructive / irreversible | Wipe device, delete asset, permanent data deletion | Prohibited in-platform | External emergency procedure only, outside platform authority |
Required control sequence for every side-effecting action
Every action defines: required evidence, required role, approval level, dual-control requirement, target validation, expected business impact, TTL, dry-run support, execution method, idempotency behavior, success criteria, verification query, rollback method, and escalation path — before it is ever enabled for a tenant.
Kill-switch hierarchy
Independent disable controls, each tested in release gates and exercised in drills:
Global Cell Tenant Workflow Agent Tool Model Action type
Activation is deterministic, requires no model availability, and is itself audited. Investigations queue; raw alert receipt continues.
Detection engineering — detection as code
Detections are versioned, tested, staged artifacts with owners and health monitoring — not strings pasted into a SIEM console.
Pipeline
Repository structure
/detections /sigma /kql /spl /cql /vendor-native /tests /positive /negative /performance /schema /mappings /attack /ocsf /vendor /playbooks /exceptions
Code ownership per directory; review requirements enforced in CI; exceptions are versioned artifacts with expiry — not tribal knowledge.
Threat-intelligence integration
- STIX 2.1 for structured threat and observable information; TAXII 2.1 for exchange where supported.
- Source reliability, confidence, expiration, revocation, relationships, provenance, and tenant policy preserved.
- Indicator decay, deconfliction, and suppression of stale or low-quality intelligence.
- External intelligence informs investigations — it never becomes automatically authoritative.
Detection health
Per-rule: fire rate, FP feedback loop from case dispositions, telemetry-gap tracking, latency and cost, staleness, deprecation workflow, and one-click rollback to the prior version.
Evaluation, testing & release governance
Golden datasets and LLM-as-judge are necessary but not sufficient. Evaluation spans components, workflows, adversarial conditions, shadow production, and controlled release — measured against security outcomes, not stylistic quality.
| Level | Required coverage |
|---|---|
| 1 · Component | Prompts, structured-output schemas, policy checks, query compilation, tool selection, evidence citation, normalization mappings, connector authorization. |
| 2 · Workflow | True/false positives, duplicates, missing logs, conflicting evidence, stale intelligence, source outage, provider outage, rate limits, partial completion, human disagreement. |
| 3 · Adversarial | Direct/indirect injection, poisoned retrieval, malicious tool responses, tool-schema manipulation, cross-tenant requests, context flooding, cost exhaustion, loop induction, credential extraction, audit suppression, response-target substitution. |
| 4 · Shadow production | Run against live alerts without changing dispositions or executing actions; compare with analyst outcomes at scale. |
| 5 · Controlled production | Enable one narrowly defined outcome at a time, after workflow-specific evidence and rollback validation. |
Metric domains
- Security outcomes — true/false-positive triage rates, critical false negatives, escalation accuracy, evidence completeness, pivot coverage, time to correct disposition, time to validated containment, override rate, reopen rate.
- Agent performance — correct tool choice, query validity/relevance, structured-output validity, grounded-claim rate, citation correctness, unsupported claims, completion, loops, retries, latency, cost per case.
- Safety — unauthorized tool attempts, cross-tenant retrieval, sensitive-data disclosure, injection success rate, policy bypass, unsafe recommendations, unauthorized actions, rollback failures, audit completeness, unattributed actions.
- Reliability — connector availability, queue delay, workflow completion, model-fallback rate, degraded-mode success, restore results, cell saturation, P50/P95/P99 latency.
LLM-as-judge restrictions
- One evaluation signal — never the sole production release authority.
- Explicit rubrics, deterministic checks, human adjudication, judge-to-human agreement measured.
- Candidate identity hidden; ordering randomized to reduce preference bias.
- Judges versioned and revalidated after any change.
- Development, regression, adversarial, and final holdout sets kept separate; no training or prompt leakage from evaluation data.
Release gate — all ten, every release
- 1 · Regression and adversarial suites pass.
- 2 · No critical safety regression.
- 3 · Schema and connector compatibility pass.
- 4 · Permission changes separately reviewed and approved.
- 5 · Cost and latency within budget.
- 6 · Human-review agreement meets the workflow threshold.
- 7 · Rollback and kill switches tested.
- 8 · SBOM and AI/ML-BOM inventories updated.
- 9 · Audit and observability fields complete.
- 10 · A named owner accepts the release.
Observability, audit & decision reconstruction
Three record categories with different consumers, retention, and integrity requirements — deliberately not one log.
| Record category | Purpose | Integrity requirement |
|---|---|---|
| Operational telemetry | SRE and engineering: latency, failures, resources, cost, reliability | Best-effort; sampled; short retention |
| Security audit log | Who or what accessed, changed, approved, or executed a protected operation | Append-only, tamper-evident, independently retained |
| Case decision ledger | Reconstruct evidence, findings, policies, approvals, actions, verification, disposition per case | Complete per case; replay-grade; legal-hold aware |
OpenTelemetry instrumentation
Spans for workflow, agent, model call, tool call, connector, policy decision, approval, response execution, verification, and rollback — with token, cost, retry, and failure-category attributes.
tenant.id | case.id | alert.id workflow.id | workflow.version agent.id | agent.version model.provider | model.name | model.version prompt.version | tool.name | tool.version | policy.version action.risk_class | approval.id | evidence.count token.input | token.output | cost.estimated result.status | failure.category
Default: sensitive prompt and completion content is disabled or redacted in production telemetry.
Minimum security audit event
- Tenant and actor type/identity — human session, service, workflow, and agent identity.
- Source, destination, requested operation, protected resource.
- Policy version, inputs, decision, and any exception applied.
- Approval identity and scope where applicable.
- Evidence references and data classification.
- Tool, connector, model, and prompt versions.
- Action result, verification result, before/after state.
- Trusted timestamp, trace identifier, integrity proof.
Audit-write failure is a platform incident — and blocks R3+ execution while it lasts.
Standards & framework baseline
Standards are used pragmatically, mapped to concrete components with a validation method. Referencing a framework is not compliance; no certification is claimed here.
| Domain | Baseline | Used for | Lands in | Validated by |
|---|---|---|---|---|
| AI governance | NIST AI RMF + GenAI Profile | Govern, map, measure, manage AI risk across the lifecycle | Governance inventory, evaluation control | Governance review |
| Cyber governance | NIST CSF 2.0 | Enterprise cybersecurity outcomes and governance | Control mappings, risk register | Control assessment |
| Incident response | NIST SP 800-61r3 | IR lifecycle integrated with CSF 2.0 | Case lifecycle, platform IR runbooks | IR exercises |
| Security controls | NIST SP 800-53r5 | Control catalog and assessment basis | Security-control matrix | Internal audit |
| Zero trust | NIST SP 800-207/207A | Identity-, workload-, resource-centric access | PDP/PEP, workload identity, zones | Access reviews, pen tests |
| Secure development | NIST SSDF 800-218/218A | Secure SDLC including AI-specific practices | DevSecOps pipeline | Pipeline evidence |
| Adversary behavior | MITRE ATT&CK | Tactics, techniques, detection mapping — not proof of coverage | Findings, detection mappings | Mapping governance |
| AI threats | MITRE ATLAS | Threats and attack paths for AI/agentic systems | Threat model, adversarial suites | Red-team exercises |
| LLM / agent security | OWASP GenAI & Agentic | Injection, excessive agency, tools, memory, supply chain | Context builder, broker, evaluation | Adversarial testing |
| Event schema | OCSF | Vendor-neutral normalized security events | Normalization layer | Mapping-quality scoring |
| Threat intel | STIX 2.1 / TAXII 2.1 | Structured threat information and exchange | TI connectors and store | Feed conformance |
| Detection portability | Sigma | Portable detection source requiring destination validation | Detection-as-code repo | Replay + FP testing |
| Playbooks | CACAO 2.0 | Structured security playbooks | Playbook registry | Schema validation |
| Response commands | OpenC2 | Standard command semantics where integrations support them | Response actuator verbs | Connector certification |
| Observability | OpenTelemetry | Vendor-neutral traces, metrics, logs, GenAI telemetry | Observability layer | Trace completeness checks |
| Supply chain | SLSA · CycloneDX SBOM / AI-BOM | Build provenance; software, model, dataset inventory | CI/CD, governance inventory | Admission verification |
Implementation roadmap — authority ships last
Each phase ships value and retires a named risk. No autonomous response exists until Phase 5, and then only one narrowly defined action at a time. Effort bands are relative for a properly staffed team: M ≈ 1–2 months · L ≈ one quarter · XL ≈ multi-quarter.
| # | Phase | Principal deliverables | Retires risk | Exit condition | Effort |
|---|---|---|---|---|---|
| 0 | Architecture & safety foundation | Product boundary; threat model; data classification; tenant-isolation design; evidence/case schemas; action-risk model; agent contracts; provider policy; evaluation strategy; SLOs; responsibility matrix | Building the wrong system safely | No coding on autonomous response until authority and evidence models are approved | M |
| 1 | Read-only single-workflow MVP | One SIEM + one EDR; alert ingestion; OCSF normalization; deterministic dedup; triage; evidence-linked summary; analyst feedback; telemetry; audit; shadow mode | Unproven value; ungrounded summaries | Demonstrated improvement over analyst baseline without unacceptable safety or evidence defects | L |
| 2 | Investigation platform | Durable workflows; specialized agents; typed query layer; case management; TI; identity/cloud pivots; evidence sufficiency; replay; model gateway; adversarial sets | Lost state; unbounded queries; provider lock-in | Repeatable quality across supported scenarios and data-failure conditions | L |
| 3 | Multi-tenant & MSSP controls | Cell architecture; regions; tenant keys; MSSP delegation; per-tenant policy/models/quotas; dedicated tier; cross-tenant testing; offboarding | Cross-tenant exposure; unbounded blast radius | Independent validation of isolation and blast-radius controls | XL |
| 4 | Detection engineering | Detection-as-code; Sigma + vendor compilers; historical replay; performance and FP testing; shadow/canary; ATT&CK mapping; telemetry gaps; health monitoring | Untested detections; silent rule drift | Safe staged release and measurable detection quality | L |
| 5 | Gated response | Ticketing; notifications; temporary block; session revocation; endpoint isolation — with dry-run, approval, idempotency, verification, rollback, kill switch | Wrong-target and unauthorized actions | No high-impact autonomous execution; expand one action at a time | L |
| 6 | Advanced optimization | Local model serving; ensembles; fine-tuning where justified; low-risk automation; cross-case learning; adaptive routing; MSSP analytics; customer-managed data planes | Cost/latency ceilings; provider dependence | Only after safety, isolation, evidence, reliability, and operations are mature | XL |
Service objectives (starting targets, not contracts)
Final SLOs follow customer risk, deployment mode, source-system behavior, and commercial tiers. Degraded modes are defined for: preferred model unavailable, all external models prohibited, SIEM/EDR rate-limited or down, stale TI, cache loss, search degraded, audit unavailable (blocks R3+), and regional cell loss — with deterministic triage, queued investigations, disabled automation, and preserved raw evidence.
Team & ownership — the staffing reality
| Function | Core ownership |
|---|---|
| Product security lead | Threat model, isolation, secure design, abuse cases, risk acceptance |
| AI platform lead | Model gateway, agents, evaluation, prompts, model lifecycle, AI supply chain |
| Security engineering lead | SOC methodology, detections, investigations, evidence, response policy |
| Backend / platform engineers | APIs, workflows, data services, state, connectors, integration SDKs |
| Data engineer | Ingestion, schemas, normalization, lineage, event stores, data quality |
| Detection engineers | Rules, testing, telemetry requirements, mappings, tuning, health |
| SRE / platform engineer | Reliability, capacity, observability, DR, operations, incident management |
| Cloud security engineer | IAM, network, KMS, runtime, workload identity, deployment guardrails |
| Front-end / product engineer | Analyst experience, evidence presentation, approvals, accessibility |
| QA / adversarial engineer | Regression, red-team, negative, safety, cross-tenant, failure testing |
| Governance / compliance owner | Privacy, control mappings, customer assurance, contracts, audit readiness |
Separation of duties: release approval, response approval, risk acceptance, and audit review are held by different named owners; no self-approval anywhere in the chain.
Operational runbooks
Condensed operating procedures — recommended baselines to be finalized during Phase 0–1. Every runbook records evidence, requires a named role, and ends with verification.
Lifecycle
Tenant onboarding
Trigger: signed agreement, tier selected. Role: platform operations + tenant admin. Approval: tenant management owner.
- Create tenant in control plane → assign region/cell per tier and residency → generate tenant DEKs in KMS.
- Provision queue partitions, storage prefixes, RLS policies, quotas; issue tenant-scoped workload claims.
- Configure SSO federation, SCIM, roles, and (MSSP) delegation mappings; set model and response policy defaults (restrictive).
- Onboard first connectors (read-only); run ingestion conformance and cross-tenant negative tests.
Verify: isolation canaries pass; test alert flows end-to-end; audit events present. Rollback: disable tenant, revoke claims. Evidence: onboarding report in ledger.
Tenant offboarding & verified deletion
Trigger: contract end or termination. Role: platform operations. Approval: tenant management owner + governance owner.
- Legal-hold check → export package if contracted → revoke all tenant access, delegations, and connector credentials.
- Destroy tenant DEKs (cryptographic erasure) → purge replicas, search indexes, caches → schedule backup expiry.
Verify: sampled reads fail across all stores; credential audit clean. Evidence: signed offboarding report with dates and scope. Escalate: any residual-data finding = platform incident.
Connector onboarding
Trigger: tenant requests integration. Role: tenant admin + platform engineer. Approval: tenant policy; action verbs additionally security lead.
- Register connector version from registry; confirm declared capabilities and side-effect classes.
- Store credentials in secret manager (scoped, least-privilege, read-only first); bind egress allowlist.
- Run conformance suite: schema, limits, failure injection, cross-tenant negatives; enable health monitoring.
Verify: events flowing, dedup working, provenance recorded. Rollback: disable connector; credentials revoked.
Connector credential rotation
Trigger: schedule, staff change, or suspicion. Role: platform operations. Approval: automatic if scheduled; security lead if suspicion.
- Issue new credential in source system → store new version in secret manager → connectors resolve at next call.
- Confirm traffic on new credential → revoke old → verify old credential fails.
Verify: health green; zero auth errors after cutover. Evidence: rotation entry in secret-access audit.
Model onboarding / model & prompt rollback
Trigger: new model/version or quality-safety regression. Role: AI platform lead. Approval: release gate (all ten items) for onboarding; any on-call for rollback.
- Onboard: register model (provider, version, data eligibility, context limits, hashes for local artifacts) → benchmark + safety suites → shadow comparison → canary → allowlist per tenant policy → update AI/ML-BOM.
- Rollback: pin previous model/prompt version at the gateway/registry (configuration change, immediate) → re-run smoke evaluation → note affected cases in ledger.
Verify: routing shows expected version; no eligibility violations. Escalate: suspected provider compromise → emergency model disable + platform incident.
Agent release / agent disablement
Trigger: new agent version, or safety/quality threshold breach. Role: AI platform lead; disablement by any on-call.
- Release: contract updated + evaluation suite pass + permission diff separately approved → shadow → canary → general.
- Disable: flip agent kill switch (tenant- or global-scope) → workflows fall back to deterministic path or queue → notify owners.
Verify: no new spans from disabled version; queued work draining. Evidence: registry state change in audit log.
Detection release / rollback
Trigger: pipeline promotion or health regression. Role: detection engineer; peer approval mandatory.
- Release: full pipeline (tests, replay, FP, performance, ATT&CK mapping) → shadow → canary → general.
- Rollback: revert to prior version tag; suppression rules for in-flight noise; document cause in repo.
Verify: fire-rate and FP within band. Evidence: pipeline run + approval in repo history.
Incidents
Prompt-injection incident
Trigger: injection metric alert, analyst report, or anomalous agent behavior. Role: platform security on-call.
- Contain: disable affected workflow/agent (kill switch); quarantine offending evidence objects (flag, never delete).
- Investigate from the decision ledger: what context reached which model; which tool calls followed; any policy denials bypassed (should be none).
- Add the payload to the adversarial suite; update sanitizer/classifier; re-run affected cases via replay; notify affected tenants per contract.
Verify: replayed cases produce clean traces; suite catches payload. Evidence: incident record with evidence hashes.
Compromised connector
Trigger: anomalous connector behavior, vendor advisory, credential leak signal. Role: platform security on-call.
- Revoke connector credentials immediately; disable connector (tenant- or fleet-scope as indicated).
- Sweep audit for actions performed via the connector; classify data touched; check egress allowlist violations.
- Rotate adjacent secrets; re-onboard via conformance suite after vendor remediation; tenant notification per contract.
Verify: old credentials dead; clean re-certification. Evidence: timeline + scope report.
Unauthorized action attempt
Trigger: broker or actuator denies an action outside policy, or detects an attempt to bypass approval. Role: platform security on-call. Severity: always an incident, even when blocked.
- Preserve the full trace (agent, workflow, model, prompt, tool versions); freeze the requesting agent version.
- Determine cause: injection, contract error, policy gap, or compromise; fix at the strongest layer.
- Add to adversarial suite; review the zero-tolerance metric with owners.
Verify: replay shows denial holds. Evidence: audit chain + corrective action record.
Audit pipeline failure
Trigger: audit-write errors or integrity-check failure. Role: SRE on-call + security lead (dual).
- Automatic: R3+ execution blocks platform-wide while audit integrity is not guaranteed (fail closed).
- Buffer audit events durably at source; restore audit service; drain buffers in order; run integrity verification.
Verify: hash chain continuous; no gaps in sequence. Escalate: evidence of tampering → platform security incident + forensic hold.
Resilience
Regional cell failover
Trigger: cell health below threshold or regional outage. Role: SRE on-call. Approval: incident commander.
- Freeze non-essential writes; confirm queue durability; route new ingestion to standby per residency policy (sovereign tenants never leave region — they degrade instead).
- Promote replicas within residency limits; replay from checkpoints; reconcile dedup.
Verify: RTO/RPO met; no cross-region residency violation; evidence gaps flagged on affected cases. Evidence: failover report.
Backup restoration
Trigger: data-loss event or quarterly restore test. Role: SRE. Approval: data owner; governance owner if tenant data involved.
- Restore into isolated environment first; verify integrity hashes and tenant-key decryption; validate row counts and lineage continuity; then promote.
Verify: sampled evidence hashes match; RLS intact. Evidence: restore-test record (quarterly minimum).
Emergency kill switch
Trigger: unsafe behavior, suspected compromise, or regulator/customer demand. Role: any on-call may activate; only incident commander deactivates.
- Choose narrowest effective scope: action type → model → tool → agent → workflow → tenant → cell → global.
- Activation is deterministic and model-independent; investigations queue; raw alert receipt continues; automated response halts.
Verify: disabled paths produce zero executions; queues draining post-restore. Evidence: activation/deactivation entries with actor identity in audit log.
Architecture decision records
The material decisions, each with the rejected alternative and a revisit trigger. Status Proposed baseline v1.0 — to be ratified in Phase 0. Items no default can settle are in Open Decisions.
ADR-001 · Deterministic shell, probabilistic core
Decision: AI classifies, correlates, plans, and drafts. Identity, tenancy, policy, workflow state, approval, execution, verification, and audit are deterministic services.
Alternative rejected: agent-framework-centric design where orchestration is the architecture — untestable authority, unreplayable state, injection-to-action paths.
Revisit when: never for authority placement; revisit component boundaries as agent capabilities mature.
ADR-002 · Durable workflow engine owns investigation state
Decision: a durable workflow engine (Temporal-class) with checkpoints, retries, compensation, human waits, versioning, and replay.
Alternative rejected: in-memory agent loops — lost or duplicated work, no replay, no long-running approvals.
Revisit when: engine operational cost dominates, or workflow volume justifies a managed equivalent.
ADR-003 · OCSF internal schema, raw always preserved
Decision: normalize to OCSF with mapping versions and vendor-field preservation; the raw event remains the evidentiary source of truth.
Alternative rejected: proprietary schema (portability loss) or normalize-and-discard (destroys evidence).
Revisit when: OCSF coverage gaps force excessive vendor extensions for priority sources.
ADR-004 · Cell-based tenancy with five tiers
Decision: regional cells bound tenant count and blast radius; tiers from Standard to Customer-managed share one control plane.
Alternative rejected: single pooled data plane with row filters only — one bug from cross-tenant exposure, no sovereignty path.
Revisit when: cell count makes fleet operations the dominant cost — invest in cell automation, not pooling.
ADR-005 · PostgreSQL as system of record; stores by role
Decision: PostgreSQL for transactional truth; WORM object storage for raw evidence; search store as rebuildable projection; Redis ephemeral only.
Alternative rejected: search engine or vector DB as system of record — weak transactional guarantees, mutable evidence.
Revisit when: case-store scale exceeds single-cluster comfort per cell — shard by cell first.
ADR-006 · Central model gateway, no direct provider SDKs
Decision: one gateway enforces allowlists, residency, classification, pinning, budgets, fallback, redaction, accounting, and emergency disable.
Alternative rejected: per-service provider SDKs — policy drift, uncontrolled data transfer, silent version changes.
Revisit when: a workload needs provider features the gateway cannot proxy — extend the gateway, never bypass it.
ADR-007 · Mixed model estate under per-workload policy
Decision: hosted, private-endpoint, and open-weight models selected per workload sensitivity, quality, latency, and cost; open-weight is not assumed safer or cheaper — it carries GPU capacity, patching, integrity, and quality burdens.
Alternative rejected: single-provider simplicity (residency and outage exposure) or local-only purity (quality and operations cost).
Revisit when: benchmarks show a tier consistently dominated on quality-per-cost for its workload.
ADR-008 · Vector index optional and never authoritative
Decision: approximate retrieval only for approved use cases; every hit re-validated against the source of record before influencing a finding.
Alternative rejected: RAG-first evidence architecture — poisoning surface, no chain of custody.
Revisit when: a use case demonstrates recall value that outweighs governance cost.
ADR-009 · Policy-as-code with central PDP, PEPs everywhere
Decision: versioned policy (OPA/Cedar-class) evaluated at gateway, broker, workflow, and response plane; RBAC + ABAC with tenant-bound claims.
Alternative rejected: authorization scattered in application code — unauditable, untestable, divergent.
Revisit when: policy latency requires local evaluation with centrally distributed bundles (expected; plan for it).
ADR-010 · Typed tool broker + canonical query compiler
Decision: agents call typed tools only; model-generated queries exist as canonical intent compiled and AST-validated per vendor.
Alternative rejected: raw LLM query strings to production SIEMs — injection, cost, and correctness risks.
Revisit when: a vendor exposes a safe, parameterized query API that lets the compiler thin out.
ADR-011 · Action-risk model R0–R5 with dual control at R4
Decision: six classes; R3+ needs explicit approval, R4 two-person, R5 prohibited in-platform; audit-write failure blocks R3+.
Alternative rejected: per-action ad-hoc judgment — inconsistent, unanalyzable, untrainable.
Revisit when: operating evidence supports moving a specific, verified, reversible action down a class — one action at a time.
ADR-012 · Tamper-evident audit separate from telemetry
Decision: three record categories; the audit log is append-only, hash-chained, independently retained; the decision ledger is replay-grade.
Alternative rejected: one log stream for everything — sampling and retention needs conflict with forensic integrity.
Revisit when: volume forces tiering — tier telemetry, never audit.
ADR-013 · Durable event bus for ingestion decoupling
Decision: durable, tenant-partitioned messaging (Kafka-class) with DLQs and backpressure between connectors and processing.
Alternative rejected: synchronous ingestion — source spikes become platform outages.
Revisit when: operational burden justifies a managed bus within residency constraints.
ADR-014 · Minimal agent set behind benchmark gates
Decision: twelve specialized agents maximum at target state; each must beat the deterministic baseline in evaluation before release; deterministic-first for everything else (P09).
Alternative rejected: open-ended agent swarm — cost, latency, attack surface, and unattributable behavior.
Revisit when: a new workflow shows measured value for an additional bounded agent.
Risk register
Inherent risk assumes no controls; residual assumes the architecture as designed and operated. Likelihood/impact are this review's assessment for a typical MSSP-scale deployment. Owners are functions, not names.
| ID | Risk | Threat actor | L | I | Inherent | Key controls (preventive · detective · corrective) | Residual | Owner / treatment |
|---|---|---|---|---|---|---|---|---|
| R-01 | Cross-tenant data exposure | Cross-tenant attacker; defect | Med | Severe | Critical | Cells, claims, RLS, tenant keys · continuous canaries, release negative tests · incident + notification runbook | Low–Med | Product security · Mitigate |
| R-02 | Prompt injection alters investigation or action | Malicious evidence source | High | Severe | Critical | Context builder, typed tools, least agency · injection metrics, output validation · quarantine + replay runbook | Medium | AI platform · Mitigate |
| R-03 | Unauthorized or wrong-target response action | Compromised actuator; defect | Low–Med | Severe | Critical | R0–R5, approvals, target re-validation, tokens · post-action verification · rollback + kill switch | Low | Security eng · Mitigate |
| R-04 | Excessive agency / tool abuse | Injected or defective agent | Med | High | Critical | Contracts, broker allowlists, budgets · unauthorized-attempt metric (zero-tolerance) · agent disable | Low | AI platform · Mitigate |
| R-05 | Audit gaps or tampering | Insider; attacker covering tracks | Low | Severe | Critical | Append-only hash-chained store · integrity verification · R3+ execution blocks on failure | Low | Product security · Mitigate |
| R-06 | Secrets exposure via prompts, logs, or traces | Any; often accidental | Med | Severe | Critical | Secret references, call-time resolution · scanning in telemetry pipeline · rotation + revocation | Low | Cloud security · Mitigate |
| R-07 | Unsupported findings accepted as fact | Model hallucination | High | High | High | Evidence-linked claims, UX labeling · grounded-claim metrics, quality agent · human review, reopen flow | Medium | Security eng · Mitigate |
| R-08 | Model provider outage or silent change | Provider | High | Med | High | Pinning, fallback chain, deterministic degraded mode · shadow comparison, health · failover <5m | Low | AI platform · Mitigate |
| R-09 | Connector outage or rate limiting | Vendor; misconfig | High | Med | High | Queues, backpressure, circuit breakers · health model · queued investigations, incomplete-evidence state | Low | SRE · Mitigate |
| R-10 | Data / retrieval poisoning | Adversary seeding content | Med | High | High | Non-authoritative vector index, TI decay/deconfliction · lineage, quality scoring · re-validation vs source | Medium | AI platform · Mitigate |
| R-11 | Compromised open-weight model artifact | Supply-chain attacker | Low–Med | High | High | Artifact hashes, AI/ML-BOM, admission control · benchmark drift detection · model disable + rollback | Low | AI platform · Mitigate |
| R-12 | Data-residency violation | Routing or policy defect | Med | High | High | Regional cells, gateway residency enforcement · routing audit · sovereign tenants degrade rather than move | Low | Governance · Mitigate |
| R-13 | Cost / token exhaustion; agent loops | Adversary; defect | High | Med | High | Budgets at gateway + broker, step caps · cost telemetry, loop detection · circuit breakers, quotas | Low | SRE · Mitigate |
| R-14 | Detection translation errors (semantic drift) | Tooling; complexity | High | Med | High | Replay + FP testing per destination · detection health · rollback | Medium | Detection eng · Mitigate |
| R-15 | Critical false negatives | Adversary evading triage | Med | Severe | High | Deterministic floor rules, escalation bias in policy · FN metrics from reopens/hunts · threshold retuning | Medium | Security eng · Mitigate |
| R-16 | Analyst overreliance on AI output | Organizational | High | Med | High | Evidence-labeled UX, unsupported-claim marking · override/agreement metrics · training, workflow design | Medium | Product · Mitigate |
| R-17 | Privileged insider misuse | Insider; support engineer | Low | Severe | High | SoD, customer-approved support access, JIT · session recording, secret-access audit · revocation, incident | Low–Med | Product security · Mitigate |
| R-18 | CI/CD or artifact supply-chain compromise | Supply-chain attacker | Low–Med | Severe | High | Signed builds, provenance, admission · pipeline integrity monitoring · revocation + rollback | Low | Cloud security · Mitigate |
| R-19 | Recovery failure (backup/restore) | Operational | Low | High | Medium | Quarterly restore tests · integrity hashes · isolated-restore runbook | Low | SRE · Mitigate |
| R-20 | Stale or conflicting threat intelligence | Feed quality | High | Low | Medium | Expiry, decay, deconfliction · source-quality scoring · suppression | Low | Security eng · Mitigate |
| R-21 | Vendor / model lock-in | Commercial | Med | Med | Medium | Gateway abstraction, OCSF, canonical query intent · portability review per ADR · alternative certification | Low–Med | Product · Accept partially |
| R-22 | Fine-tuning contamination or drift | Process | Low | Med | Medium | Deferred to Phase 6; dataset lineage, consent, isolation · eval regression · rollback | Low | AI platform · Defer |
| R-23 | Cell fleet operational sprawl | Operational | Med | Med | Medium | Cell automation, IaC, fleet observability · capacity reviews · consolidation within tiers | Low–Med | SRE · Mitigate |
| R-24 | Evaluation-set leakage into training/prompts | Process | Med | Med | Medium | Set separation, holdout governance · leakage checks · re-baselining | Low | AI platform · Mitigate |
Open decisions — required before build
Fifteen questions that must be answered and recorded in Phase 0. Each carries a recommended default from this review and the consequence of leaving it unresolved.
1 · What is the product, primarily?
Recommended default: an analyst copilot with gated response — not an autonomous SOC worker, not a SOAR replacement, not a detection platform first. If unresolved: every later scope debate reopens; evaluation targets are unanchorable.
2 · Which actions are categorically prohibited; which need single vs dual approval?
Recommended default: the R0–R5 model — R3 single approval, R4 dual, R5 prohibited in-platform. If unresolved: response scope creeps action by action with no principled line.
3 · What is sufficient evidence for each disposition and response?
Recommended default: per-workflow sufficiency rules defined with detection engineering; contradictions and gaps always block policy-controlled closure. If unresolved: “confidence” silently substitutes for evidence.
4 · What is the authoritative internal event and evidence schema?
Recommended default: OCSF plus the evidence-record envelope (ADR-003), versioned mappings. If unresolved: every connector invents its own semantics; replay is impossible.
5 · What data may leave a tenant region, cloud, or customer environment?
Recommended default: nothing raw leaves the cell by default; model calls follow tenant model policy with classification-based redaction; sovereign tenants degrade rather than transfer. If unresolved: residency violations arrive with the first misconfigured tenant.
6 · How is tenant isolation enforced beyond application filtering?
Recommended default: the Multi-Tenancy defense-in-depth stack: cells, claims, RLS, keys, partitioned queues, per-tenant credentials, negative tests. If unresolved: isolation is one WHERE clause away from an incident.
7 · How are human, service, agent, workflow, connector, and actuator identities issued and authorized?
Recommended default: workload identity federation with short-lived, tenant-bound credentials; humans via OIDC/SAML + phishing-resistant MFA. If unresolved: attribution — the platform's core promise — fails.
8 · Which service owns durable workflow state and replay?
Recommended default: the workflow engine (ADR-002); agents are stateless workers. If unresolved: state fragments across frameworks and queues; nothing is reconstructable.
9 · How are models, prompts, tools, policies, schemas, playbooks, detections versioned and rolled back?
Recommended default: everything through the signed control-plane registries with release gates and one-step rollback. If unresolved: silent drift — a provider update becomes a production behavior change nobody approved.
10 · How is quality calibrated per workflow and security outcome?
Recommended default: the five-level evaluation hierarchy with per-workflow calibrated risk scores and human-agreement thresholds. If unresolved: stylistic quality masquerades as security quality.
11 · How are malicious evidence and tool responses contained?
Recommended default: the context-builder architecture plus typed tools and output validation; adversarial suite grows with every incident. If unresolved: the SOC's own telemetry is the attack vector.
12 · How is every action simulated, approved, verified, and reversed?
Recommended default: the response control sequence — dry-run where supported, verification query mandatory, rollback method required before enablement. If unresolved: the first wrong-target isolation is a customer-trust event.
13 · What does the system do when no LLM is available or permitted?
Recommended default: deterministic triage floor, queued investigations, disabled automation, preserved raw evidence, explicit incomplete-evidence status. If unresolved: a provider outage becomes a security-operations outage.
14 · How is the platform itself investigated and recovered when it becomes the incident?
Recommended default: platform IR runbooks, forensic logging, credential revocation, tenant notification, recovery exercises — treated with the same rigor the platform sells. If unresolved: the incident-response product has no incident response.
15 · What responsibilities remain with customer, MSSP, model provider, integration vendor, and operator?
Recommended default: a published shared-responsibility matrix per deployment tier, contract-referenced. If unresolved: every incident becomes a liability negotiation.