Model Supply Chain
9 articles
The AI Security Operating Model: Who Owns What Across AppSec, MLOps, GRC, Legal, Privacy, and SOC
A credible AI security operating model assigns ownership across AppSec, product security, AI platform engineering, MLOps, data governance, privacy, legal, GRC, SOC, red team, procurement, and business teams. The goal is not companyal purity; the goal is clear accountability for controls, evidence, incidents, and claims.
Private Benchmarks for AI Security: Skills, Operating Models, Controls, and Governance Evidence
Private AI security benchmarks can help organizations compare skills, operating models, control coverage, evidence maturity, and role expectations against defined datasets or frameworks, but they must be presented as directional advisory tools rather than certification, audit opinion, or proof of internal security maturity.
The Future of AI Security Engineering: From AppSec to AgentSec to Autonomous SOCs
The future of AI Security Engineering is a platform discipline that extends AppSec into LLM applications, creates AgentSec for autonomous workflows, builds AI-native telemetry for detection and incident response, and turns governance into continuous evidence rather than annual paperwork.
Secrets Management for AI Apps: API Keys, Model Providers, Tool Credentials, and Delegated Access
AI applications need disciplined secrets management across model provider keys, vector stores, tool credentials, OAuth tokens, browser sessions, cloud keys, notebooks, logs, prompts, and agent runtimes. Secure design requires centralized secret storage, short-lived and scoped credentials, delegated authorization, redaction, rotation, revocation, and incident-ready evidence.
Cloud Security for AI Workloads: GPUs, Secrets, Buckets, Model Endpoints, and Notebook Risk
Cloud security for AI workloads requires inventorying AI assets, protecting model endpoints, securing GPU and notebook environments, managing secrets, locking down object storage and vector stores, scanning containers, limiting egress, monitoring cost, and integrating AI infrastructure into normal cloud security operations.
Threat Modeling LLM Applications: Data Flows, Trust Boundaries, Tool Calls, and Abuse Cases
LLM threat modeling should map assets, actors, data flows, trust boundaries, prompt assembly, retrieved content, model providers, tool calls, memory, outputs, identities, approvals, logs, and abuse cases. The output should become controls, tests, telemetry requirements, and incident-response assumptions.
LLMOps Security: CI/CD, Secrets, Eval Gates, Model Registry Controls, and Deployment Promotion
LLMOps security requires CI/CD controls for prompts, tools, model configuration, provider routing, evals, secrets, registries, deployment promotion, monitoring, rollback, and governance evidence. AI release processes must track every artifact that can change system behavior.
Securing Open-Source Models: What to Check Before Running a Model in Production
Open-source models require a production intake process covering provenance, license review, file formats, remote code, unsafe serialization, dependencies, containers, evals, serving infrastructure, monitoring, rollback, and governance evidence.
The Agentic Anarchy Problem: Why AI Agents Break Traditional IAM Models
AI agents break traditional IAM because they act across user intent, application authority, and tool permissions. A secure agent program requires explicit identity, delegated authorization, scoped credentials, and policy enforcement that lives outside the model.