>_ 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

The figure groups seven areas of security work by design, testing, and operation. The work overlaps: a policy enforced in production still has to be designed and tested before deployment.

Seven areas of security work across the system lifecycle A 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. These areas overlap across phases. An annotation indicates that discovering a problem after deployment can make it more costly to fix. design build & test operate cost of discovery -> 1.1 · threat modeling 1.2 · data boundaries 1.3 · injection & abuse 1.4 · eval harness 1.5 · red team 1.6 · policy gate 1.7 · monitoring
fig. 1 · security work across the system lifecycle. Hover or focus a node to highlight its description below. Finding a design problem after deployment can mean changing a live system as well as fixing the original mistake.

  1. 1.1 Threat modeling for AI systems

    Identifying what needs protection, who can influence the system, and what access the model and its tools provide.

  2. 1.2 Data leakage boundaries

    Tracing where prompts, embeddings, and outputs can go, including storage, logs, and external services.

  3. 1.3 Prompt injection and tool abuse

    Examining how untrusted input can influence a model's tool calls or actions in production systems.

  4. 1.4 Evaluation harnesses

    Regression suites and adversarial tests for known failure modes, used to assess changes before release.

  5. 1.5 Red-team workflows

    Adversarial testing that looks for ways around the system's intended restrictions.

  6. 1.6 Policy enforcement

    Implementing checks on the actions, data access, and tool calls the system permits.

  7. 1.7 Monitoring and incident response

    Detecting failures in production and defining who responds, how to contain the incident, and what to investigate.

Attack paths and mitigations

Untrusted input can affect retrieval, model output, tool calls, and the data written to logs. The diagram traces three example threats through those components and marks controls intended to address them. A tool call can pass an initial policy check and still cause harm, so testing has to examine what the call does as well as whether it is permitted.

The gates are schematic. Policy enforcement can check a tool call at runtime; an evaluation harness tests behavior before a version is released. Monitoring helps detect a leak and initiate a response, but does not by itself prevent data from leaving. Those are different responsibilities, even when the diagram puts them on one line.

Example attack paths and associated security controls A 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 example threats are paired with controls: T1 prompt injection with policy enforcement, T2 tool abuse with evaluation, and T3 data leakage with monitoring and response. These controls have different roles: runtime checks, testing before release, and detection and response. Their placement is schematic, not a guarantee that a threat is stopped. Hovering or focusing a threat label highlights its route and associated control. T1 · prompt injection T2 · tool abuse T3 · data leakage Untrusted input Retrieval Model Tool calls Production Logs / telemetry External sink policy enforcement ✕ evaluation harness ✕ monitoring & response ✕
fig. 2 · example routes for prompt injection, tool abuse, and data leakage. Hover or focus a threat label to trace the route and highlight the associated control. Dotted continuations show the harm that control is intended to address.

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.

Sovereign data boundary An 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
fig. 3 · an isolated deployment containing source data, a vector database, a local LLM, policy enforcement, evaluation, and audit logs. Crosses mark denied connections in both directions, including an attempt to send audit logs outside the perimeter.

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

Azu

AI agent

1 of 3 · Introduction

Chat about this page

Azu is an AI agent that runs locally on your device. You can chat with Azu and ask questions about the current page. No chat data leaves your device.