>_ Tibor Sloboda

AI Security

Threat modeling, guardrails, red-teaming, policy enforcement, evals, monitoring, and incident response for AI systems.

AI security is systems work. Prompt rules are not enough when models can call tools, process private data, summarize hostile input, or route decisions into production workflows.

Focus areas

Seven practice areas, numbered in lifecycle order: when each one runs, and how much it costs to be wrong by the time it fires.

The seven focus areas, placed where they runA horizontal axis divided into three phases - design, build and test, operate - with the seven focus areas numbered in lifecycle order along it. Threat modeling (1.1) and data leakage boundaries (1.2) sit in design; prompt injection and tool abuse analysis (1.3), evaluation harnesses (1.4), and red-team workflows (1.5) sit in build and test; policy enforcement (1.6) and monitoring and incident response (1.7) sit in operate. An annotation notes that the cost of discovering a failure rises from left to right.designbuild & testoperatecost of discovery →1.1 · threat modeling1.2 · data boundaries1.3 · injection & abuse1.4 · eval harness1.5 · red team1.6 · policy gate1.7 · monitoring
fig. 1 — the seven areas on the lifecycle axis. Hover or focus a node to find it in the list below. The axis annotation is the entire argument for starting security work at design time.

  1. 1.1 Threat modeling for AI systems

    Identifying what a model, its tools, and its data boundary actually expose.

  2. 1.2 Data leakage boundaries

    Tracing where prompts, embeddings, and outputs can end up that they shouldn't.

  3. 1.3 Prompt injection and tool abuse

    Where untrusted input meets a model that can call tools or touch production systems.

  4. 1.4 Evaluation harnesses

    Regression suites and adversarial tests that catch a failure before a user does.

  5. 1.5 Red-team workflows

    Structured adversarial testing before an incident finds the gap for you.

  6. 1.6 Policy enforcement

    Turning acceptable-use rules into something a system actually checks, not just documents.

  7. 1.7 Monitoring and incident response

    Detecting failure in production, with an actual response path once it happens.

Attack paths and mitigations

A mitigation is only real if you can point at the edge it sits on. The figure below is the standard tool-using pipeline — untrusted input, retrieval, model, tool calls, production, with logs branching off toward the outside world — and three attack routes drawn through it. Each route dies at a gate, and the gates sit where the controls actually run: policy enforcement checks the model’s tool calls, the evaluation harness decides what ships to production, monitoring guards what leaves through logs and telemetry. Note what the dashes tell you: tool abuse (T2) starts after the policy gate — a call can be well-formed, policy-clean, and still hostile. That is why one gate is never enough.

Attack paths through an AI system, and the gates that cut themA pipeline runs from untrusted input through retrieval, the model, and tool calls into production, with logs and telemetry branching below the model toward an external sink. Three attack routes traverse it: T1 prompt injection rides untrusted input through retrieval and the model and is cut by the policy enforcement gate before tool calls; T2 tool abuse survives the policy gate and is cut by the evaluation harness gate before production; T3 data leakage flows from the model into logs and telemetry and is cut by the monitoring and response gate before reaching the external sink. Hovering or focusing a threat chip highlights its full route and the gate that stops it.T1 · prompt injectionT2 · tool abuseT3 · data leakageUntrusted inputRetrievalModelTool callsProductionLogs / telemetryExternal sinkpolicy enforcement✕evaluation harness✕monitoring & response✕
fig. 2 — three attack routes through one pipeline. Hover or focus a threat chip to trace its route to the gate that cuts it; the faint dotted continuation is where the attack would have gone. Routes pass through components, not around them — that is the point.

Sovereign boundary model

For systems with strict data-residency requirements, the boundary includes source data, embeddings, model weights, and logs. The diagram illustrates a fully isolated deployment; the appropriate boundary depends on the actual operating requirements.

  <svg class="graph-svg sb" viewBox="0 0 960 420" role="img" aria-labelledby="sb-title sb-desc">
Sovereign data boundaryAn air-gapped perimeter encloses the working system: source data feeding a vector database feeding a local LLM, with a policy engine, an evaluation harness, and audit logging wired beneath them. Outside the perimeter, a managed API, a telemetry sink, and a public cloud service each probe the near wall and are denied, marked with a cross at the boundary. One outbound attempt - audit logs trying to leave through the far wall - is denied from the inside. Nothing crosses in either direction. DATA_BOUND_IP:AIRGAPPED outbound · audit exfil

✕ ✕ ✕ ✕

Managed API Telemetry sink Public cloud Local LLM Vector DB Source data Eval harness Policy engine Audit log 
<figcaption>fig. 3 &mdash; sovereign boundary: the working system &mdash; source data, vector database, local LLM, policy engine, eval harness, audit log &mdash; lives entirely inside an air-gapped perimeter. Every dashed route is a denied crossing (&#10005;): three inbound probes from managed APIs, telemetry, and public cloud, and one outbound attempt &mdash; the audit log trying to phone home. The boundary is bidirectional or it is not a boundary.</figcaption>

For help with the architecture or evaluation of an AI system, see services and rates or get in touch.