← All posts

AI Security Solutions

97 posts on ai security solutions.

ChatGPT DLP: Detecting and Preventing Sensitive Data in Prompts

ChatGPT DLP is the practice of detecting and preventing sensitive data from entering ChatGPT prompts. Traditional DLP operating at the email gateway, the storage layer, and the endpoint misses prompt-layer data movement. The architectural fix moves DLP into the AI request path with prompt-level classification, identity-aware policy, and per-decision audit records. This piece walks through where ChatGPT DLP needs to operate, what classifiers matter, and how it differs from network DLP that watches egress packets without prompt context.

chatgptai-dlpllm-dlpenforcementdata-protection
Read post →

AI Prompt Risk Scanner: A Free Tool To Check What Your AI Prompts Actually Expose

The AI Prompt Risk Scanner is a free tool that inspects a sample of your organization prompts against the same detection rules a production inspection layer would apply. Paste a prompt or upload a batch, and the scanner returns the data classes detected, the regulatory exposures triggered, and the policy outcomes that would fire under standard rules. This piece walks through what the scanner inspects, how the rules work, and what to do with the results.

ai-securityprompt-inspectiontoolsshadow-aicompliancedlp
Read post →

AI Firewall: What It Actually Inspects, Where It Sits, and the Audit Record It Produces

The phrase "AI firewall" gets applied to four very different products. The category collapses when you ask what each one inspects, where in the request path the inspection happens, and whether the record series survives EU AI Act Article 12 review. This piece walks through the four product shapes that get marketed as AI firewalls, the architectural property each one has and lacks, the inspection target the term should refer to in a regulated deployment, and the audit record the inspection layer commits at decision time.

ai-firewallinline-enforcementai-gatewayllm-securityaudit-logsai-policy-enforcement
Read post →

LLM Firewall: How the Inspection Layer Differs From a Network Firewall and a Model Guardrails Library

An LLM firewall is the inspection layer that sits inline between the calling identity and the LLM endpoint, evaluating identity-bound policy at the HTTP request boundary and committing a per-decision audit record. The layer differs from a network firewall (which inspects TCP and TLS metadata) and from a model guardrails library (which runs inside the inference path). This piece walks through the inspection target the LLM firewall has, the request-time decisions the layer commits, the deployment topology that fits a production stack, and the audit record the layer produces.

llm-firewallinline-enforcementai-gatewayllm-securityaudit-logsai-policy-enforcement
Read post →

Open Source LLM Guardrails: The Libraries Available, Where They Sit, and What They Cannot Replace

Open source LLM guardrails libraries cover prompt-side and response-side filtering inside the application or inference path. Llama Guard, NeMo Guardrails, Guardrails AI, LMQL, and Rebuff each occupy a different position in the stack and produce different control surfaces. This piece walks through the libraries available, the architectural position each one takes, the controls they produce, and the regulatory profile that requires an external inspection layer on top of any of them.

llm-guardrailsopen-sourcellm-securityai-policy-enforcementinline-enforcementmodel-safety
Read post →

AI Prompt Risk Scanner: A Free Tool to Check Prompts for PII, PHI, Secrets, and Injection Patterns

Most production AI applications send prompts to vendor LLM endpoints without an inspection layer. The prompt content carries PII, PHI, secrets, and prompt-injection vectors at rates the application teams underestimate. This page walks through the free prompt risk scanner the DeepInspect team built, the four classifiers it runs, and the report format that tells you what your traffic actually carries.

prompt-riskprompt-scannerpii-detectionphi-detectionprompt-injectionfree-tool
Read post →

AWS Bedrock Guardrails Architecture Deep Dive: Where the Inspection Sits and What It Cannot See

AWS Bedrock Guardrails sit inside the model invocation path on the AWS side of the API boundary. The architecture covers AWS-hosted endpoints with policies AWS authors and evaluates. This piece walks through the Bedrock Guardrails request path, the four policy categories AWS exposes, where the inspection actually runs, the audit records the deployer receives, and the deployment patterns the Bedrock-only customer and the multi-cloud customer should each consider.

aws-bedrockbedrock-guardrailsai-securityai-architectureinline-enforcementaudit-logs
Read post →

Azure AI Content Safety Architecture Deep Dive: Where the Inspection Sits and What It Cannot See

Azure AI Content Safety runs inside the Azure-hosted classification path. The product covers text, image, prompt-shield, groundedness, and protected-material checks the deployer composes through the Content Safety endpoint. This piece walks through the request path, the API surfaces, the policy categories, the audit records the deployer receives through Azure Monitor and the Foundry observability stack, and the deployment patterns the Azure-only customer and the multi-cloud customer should each consider.

azure-aicontent-safetyai-securityai-architectureinline-enforcementaudit-logs
Read post →

AI DLP: Why Traditional Data Loss Prevention Misses the LLM Request Path and What Replaces It

Traditional DLP sits at the network edge or endpoint and inspects files and email. AI DLP has to sit at the HTTP request layer between authenticated users or agents and the LLM endpoint, because the prompt is the data and the prompt is inside an encrypted POST body the network DLP never sees. This piece walks through where each DLP layer terminates inspection, the regulatory framing under EU AI Act Article 12 and HIPAA, and the inspection architecture that produces a defensible record.

ai-dlpllm-dlpdata-loss-preventionai-securityinline-enforcementeu-ai-act
Read post →

AI Control Plane: What Sits at the Request Boundary and What an Auditor Reviews

The phrase "AI control plane" gets applied to four different layers in the stack. Each layer has a different inspection target, a different enforcement timing, and a different audit record. This piece walks through what an AI control plane has to do at the HTTP boundary between authenticated users or agents and the LLM, where most candidate products fall short of EU AI Act Article 12 review, and the record series the inspection layer commits at decision time.

ai-control-planeai-gatewayinline-enforcementai-policy-enforcementaudit-logseu-ai-act
Read post →

AI Policy Enforcement: Where the Decision Happens and the Record That Survives Review

AI policy enforcement has to operate at a specific layer in the request path to produce a record that survives an EU AI Act Article 12 review. Most stacks place the enforcement inside the application that makes the AI call, which fails the traceability test. This piece walks through where the enforcement has to sit, the properties the layer must carry (deterministic, identity-aware, fail-closed, sub-50ms), the record series the layer commits, and the regulatory framing that makes the placement non-optional.

ai-policy-enforcementai-gatewayinline-enforcementeu-ai-actaudit-logsai-security
Read post →

Zero Trust Applied to AI Systems: The Per-Request Identity, Policy, and Audit Boundary

Zero-trust architecture replaces the perimeter assumption with per-request verification of identity, device, and policy. Applied to AI systems, the same principle moves the verification to the AI request boundary: who is making the call, what classification the request carries, what policy version evaluates the call, and what audit record the layer commits. This piece walks through the four zero-trust principles and how each one maps to a concrete decision the AI request path has to commit on every call.

zero-trustai-securityidentity-awareaudit-logsinline-enforcementpolicy-enforcement
Read post →