Planned design — working prototype, not a production service

Technology

How PurifySec uses Anthropic's Claude API. PurifySec is built by the AI division of Purify Solution Co., Ltd. (Korea). A working prototype runs on the Claude API; this page describes the target architecture we are building toward. Not every component below is implemented yet, and details may change.

Per-alert request flow (design)

What happens when one alert comes in

Claude is called by our application at runtime, once per investigation, as part of the product. The steps below are the design the prototype is built around.

  1. Build the request. The orchestrator sends a Messages API request with a versioned system prompt (defensive role, evidence rules, output contract), the read-only tool definitions and the normalized alert. Alert and log text is wrapped in a delimited block marked as untrusted data. The system prompt and tool definitions form a stable, cacheable prefix.
  2. Tool-use loop. When Claude returns a tool_use block (for example search_events for the same host in the last 24 hours), the orchestrator checks it against an allowlist and the customer's authorized data sources, runs the read-only query and returns a tool_result. The loop has a capped number of turns.
  3. Structured result. Claude's final answer must match the triage JSON schema (verdict, suggested priority, summary, evidence references, ATT&CK candidates, next steps). The orchestrator validates it and checks that every cited event ID exists in the data actually retrieved; invalid output is retried or flagged.
  4. Routing. First-pass triage is designed to use a smaller Claude model; high-severity or low-confidence cases, and analyst follow-up questions, go to a larger Claude model with the cached case context.
  5. Human decision. The draft lands in the analyst review queue as awaiting_analyst_approval. Only an analyst can approve it into a ticket or report. The model call, tool calls, prompt version and decision are written to the audit log.

Architecture

Planned system overview

Claude is the reasoning core. Our application provides the connectors, tools, schemas, safeguards and review workflow around it.

PurifySec planned architectureCustomer-owned SIEM, EDR, identity logs and code flow through read-only connectors and pre-processing into the PurifySec orchestrator, which calls Claude through the Anthropic Messages API with tool use. Claude calls read-only query tools. Schema-validated structured triage goes to an analyst review queue; only approved outputs become tickets and reports. An offline evaluation harness tests changes and an audit log records every step.Customer-owned systemsSIEM alertsEDR telemetryIdentity & cloud logsCode repositoriesIngest & pre-processRead-only connectorsNormalize fieldsRedact secrets / PIIMark logs as untrustedPurifySec orchestratorModel routerPrompt-cache prefixTool executor (allowlist)JSON schema validationClaude (Messages API)Smaller model: bulk first-pass triageLarger model: deep investigationRead-only query toolssearch_events · get_hostget_user · lookup_attackStructured triage (JSON)verdict · priority · evidenceATT&CK candidatesnext steps (draft)Analyst review queueapprove · edit · rejecthuman approval gateApproved outputstickets · incident reportsremediation notesEvaluation harnessoffline, labeled casesregression gate forprompt / model changesrequesttool_use/JSONscoped, read-only queriesvalidatedAudit log — every model call, tool call, output and analyst decision is recorded (model, prompt version, timestamps)
Planned architecture (simplified). Arrows show data flow; the audit log spans every step; the evaluation harness runs offline.

Claude API design

How Claude is used

Anthropic Messages API

All analysis and drafting goes through the Messages API. A versioned system prompt defines Claude's defensive role, the evidence rules and the output contract. Claude is the core of the product: PurifySec's AI features are designed to run on Claude models.

Tool use for SIEM/EDR queries

Claude gets typed, read-only tools defined with JSON Schema, for example search_events, get_host_context, get_user_context and lookup_attack_technique. Our orchestrator executes each call against an allowlist, scoped to the data sources the customer has authorized, with time-range and rate limits. No tool can change a customer system.

Structured JSON outputs

Triage results must match a fixed JSON schema (verdict, suggested priority, summary, evidence references, ATT&CK candidates, next steps). Outputs are validated server-side; anything invalid is retried or flagged for the analyst instead of being shown as a finished result.

Prompt caching

Stable content (system prompt, tool definitions, ATT&CK reference material and the long log context of an open incident) is placed in a cacheable prefix, so follow-up questions on the same case reuse it. This is designed to cut cost and latency for long-context investigations.

Model routing

A smaller, faster Claude model (for example, the Haiku family) handles high-volume first-pass triage and extraction. A larger Claude model (for example, Sonnet or Opus) handles multi-step investigations, correlation and incident reports. Cases escalate on high severity, low confidence or analyst request.

Evaluation harness

A planned offline test set of labeled synthetic and sample alerts (and, with permission, pilot cases) scores verdict and priority agreement with analysts, ATT&CK mapping quality, schema validity, evidence faithfulness (every cited event must exist in the source) and cost/latency per alert. It runs on every prompt or model change as a regression gate.

tool definition — illustrative, simplified
{
  "name": "search_events",
  "description": "Read-only search over customer-authorized SIEM/EDR events.",
  "input_schema": {
    "type": "object",
    "properties": {
      "query":      { "type": "string" },
      "time_range": { "type": "string", "description": "e.g. last_24h" },
      "max_results":{ "type": "integer", "maximum": 200 }
    },
    "required": ["query", "time_range"]
  }
}

Safeguards

Security, data handling and human control

Prompt-injection defenses

Logs, alerts and code can contain attacker-controlled text, so all of it is treated as untrusted data, never as instructions. Content is wrapped in clearly delimited data blocks, the system prompt tells Claude to ignore instructions found inside data, and instruction-like content is flagged to the analyst. Because tools are read-only, outputs are schema-checked and a human approves every result, injected text is designed to have no path to an action.

Data handling

Only data from systems the customer owns or is authorized to manage. Data minimization and redaction of secrets and personal data before model calls. Minimal retention: pilot data is kept only for the pilot and deleted within 30 days after it ends unless agreed otherwise. Under Anthropic's commercial terms, API customer content is not used to train Anthropic's models, and PurifySec does not train or fine-tune models on customer data.

Audit logging

Every model call, tool call, output and analyst decision is designed to be recorded with timestamps, the model and prompt version used and the approving analyst, so any triage result can be traced and reviewed later.

Human approval gates

PurifySec drafts; people decide. Nothing leaves draft state without analyst approval, and the product takes no autonomous containment or remediation actions on customer systems.

Defensive scope

No offensive tooling, exploit development or malware analysis. Use is limited to defensive work and aligned with Anthropic's Usage Policy. See our Responsible Use policy.

Application, not a model provider

PurifySec is an application built on the Claude API. We do not resell access to Claude or offer models of our own; what we offer is PurifySec's triage workflow, not model access.

Talk to us about the design

Security teams interested in an early-access pilot, or in giving feedback on this architecture, can reach us by email.

Request early access