An LLM can say anything, which is exactly the problem. The same open-endedness that makes it useful means it can hallucinate, leak data, follow a malicious instruction hidden in its input, or produce something harmful — and in production, in front of real users, those aren't edge cases, they're inevitabilities. Guardrails are the controls that sit around the model to contain what it might do. This post covers the new failure modes LLMs introduce and the layered defenses that keep a production system safe.
An LLM can say anything, which is the problem. The new failure modes — hallucination, prompt injection, data leakage, harmful output — and layered, fail-closed guardrails (input, output, action) with humans in the loop, treated as part of the lifecycle and red-teamed.
Security is eBPF's third domain, and arguably its most natural fit: the kernel sees every syscall, every process, every file access and network connection, so an eBPF program in the kernel is perfectly positioned to watch for and stop malicious behavior in real time. This is why modern runtime-security tools — detecting and blocking threats on live systems — are increasingly built on eBPF.
Security is eBPF's most natural fit: the kernel sees every syscall, process, file access, and network connection, so an eBPF program in the kernel is perfectly positioned to watch for and stop malicious behavior in real time. This is why modern runtime-security tools — detecting and blocking threats on live systems — are increasingly built on eBPF.
The verifier is the reason eBPF exists in its modern form. Running arbitrary code in the kernel would be reckless; running code the kernel has proven safe is not. The verifier is the static analyzer that stands between your program and the kernel, mathematically checking that it can't crash, hang, or misbehave — and understanding it explains both eBPF's safety and its constraints.
The verifier is the reason eBPF exists in its modern form. Running arbitrary code in the kernel would be reckless; running code the kernel has proven safe is not. The verifier is the static analyzer that stands between your program and the kernel, mathematically checking it can't crash, hang, or misbehave — and it explains both eBPF's safety and its constraints.
Governing a model that answers questions is hard; governing one that takes actions is a different problem entirely. Agentic AI — systems that plan, call tools, and execute steps toward a goal with limited human oversight — moves AI from producing outputs to producing consequences. The governance frameworks built for predictive models and even for chatbots don't fully cover an agent that can send an email, move money, or modify a system. This post is about the controls that specifically matter when AI can act.
Governing a model that answers is hard; governing one that acts is a different problem — a wrong action escapes into the world. Why agents break the usual frameworks, and the controls that bound authority and consequences: least privilege, human-in-the-loop for consequential actions, bounded execution, agent identity, and fail-safe defaults.
A computer-use agent can do anything a human can do at a computer — which is exactly why it's dangerous. An agent operating your screen can click the wrong irreversible button, be hijacked by malicious content it sees, or take consequential actions you didn't intend. Safety isn't an add-on for computer-use agents; it's a precondition for using them at all. This post is about bounding an agent that's loose on a real computer.
A computer-use agent can do anything a human can at a computer — which is why it's dangerous: broad power, imperfect reliability, and exposure to prompt injection via on-screen content. Why safety is a precondition, and the controls: least privilege, sandboxing, approval gates, injection defense, and a kill switch — containment by design.
Individual controls — SBOMs, signing, provenance, dependency scanning — only add up to security when they're assembled into a coherent program with priorities, ownership, and a sensible starting point. This closing post turns the pieces into a practical roadmap: what to do first, how the controls reinforce each other, and how to build supply chain security incrementally without trying to boil the ocean.
Individual controls — SBOMs, signing, provenance, scanning — only add up to security when assembled into a coherent program with priorities, ownership, and a sensible starting point. This closing post turns the pieces into a practical roadmap: what to do first (dependency hygiene and SBOMs), how the controls reinforce each other, and how to build supply chain security incrementally without boiling the ocean.
The build system is where source becomes artifact — and where the most dangerous supply chain attacks strike, because tampering there produces a malicious release that looks completely legitimate. Securing the build means making it isolated, reproducible, and trustworthy enough that its provenance actually means something. This post covers hermetic builds, build isolation, and the practices that make "how it was built" a guarantee rather than a hope.
The build system is where source becomes artifact — and where the most dangerous supply chain attacks strike, because tampering there produces a malicious release that looks completely legitimate. Securing the build means making it isolated, reproducible, and trustworthy enough that its provenance actually means something. Hermetic builds, isolation, and platform-generated provenance.
Signing is how you turn "trust me, this artifact is authentic" into "verify it yourself." A cryptographic signature binds an artifact to its producer and proves it hasn't been tampered with since. But traditional signing has a painful key-management problem, and the modern answer — keyless signing with Sigstore — is what finally made artifact signing practical enough to be routine.
Signing turns 'trust me, this artifact is authentic' into 'verify it yourself.' A signature binds an artifact to its producer and proves it wasn't tampered with. But traditional signing has a painful key-management problem, and the modern answer — keyless signing with Sigstore — is what finally made artifact signing practical enough to be routine. Plus the verification half that makes signatures mean something.
An SBOM tells you what's in an artifact. Provenance tells you where it came from and how it was built — a tamper-evident record of the source, the builder, and the steps that produced it. It's the direct answer to the SolarWinds problem: a signed release means nothing if the build itself was compromised, so you need verifiable evidence of the build process, not just the output.
An SBOM tells you what's in an artifact; provenance tells you where it came from and how it was built — a tamper-evident record of the source, builder, and steps. It's the direct answer to the SolarWinds problem: a signed release means nothing if the build itself was compromised. This post covers provenance, attestation, in-toto, and the SLSA framework.
When the next Log4Shell-scale vulnerability is announced, the first question every organization must answer is "are we affected?" — and the teams that can answer it in minutes instead of weeks are the ones with an SBOM. A Software Bill of Materials is a complete, machine-readable inventory of everything in your software. It's the foundation of supply chain response, and increasingly, a requirement.
When the next Log4Shell-scale vulnerability is announced, the first question every organization must answer is 'are we affected?' — and the teams that can answer it in minutes instead of weeks are the ones with an SBOM. A Software Bill of Materials is a complete, machine-readable inventory of everything in your software: the foundation of supply chain response, and increasingly a requirement.
Most of your software is dependencies, so most of your risk is too. Dependency security is the practical, everyday discipline of controlling what you pull in, knowing when it's vulnerable, and updating without breaking — the highest-leverage supply chain work most teams can do. This post covers pinning, scanning, and the update discipline that keeps the dependency tree from becoming a liability.
Most of your software is dependencies, so most of your risk is too. Dependency security is the practical, everyday discipline of controlling what you pull in, knowing when it's vulnerable, and updating without breaking — the highest-leverage supply chain work most teams can do. Pinning, scanning, and the update discipline that keeps the dependency tree from becoming a liability.
To defend the supply chain you have to know how attackers get in — and there are more doors than most teams realize. Malicious packages, hijacked dependencies, dependency confusion, compromised build systems, and poisoned maintainer accounts each exploit a different link in the chain. This post is a field guide to the attack patterns, because each one maps to a specific defense.
To defend the supply chain you have to know how attackers get in — and there are more doors than most teams realize. Malicious packages, dependency confusion, compromised build systems, and poisoned maintainer accounts each exploit a different link. This post is a field guide to the attack patterns, because each one maps to a specific defense.
You don't just ship the code you wrote — you ship the code your dependencies wrote, and their dependencies, and the build system that assembled it all. That entire chain is your attack surface, and attackers have noticed. Software supply chain attacks target the trusted process by which software is built and delivered, and they've become one of the most damaging classes of breach precisely because they weaponize trust. This series is about defending that chain.
You don't just ship the code you wrote — you ship your dependencies' code, and the build system that assembled it all. That entire chain is your attack surface, and attackers have noticed. This opening post explains why supply chain attacks (SolarWinds, Log4Shell, registry attacks) became so damaging, and frames the defense: shift from implicit trust to explicit verification.
Identity is the front door to everything, which makes it the most attacked part of most systems and the place where a single mistake compromises everyone. The protocols are secure by design — but only if you use them correctly, and the failures are remarkably consistent: skipped validations, mishandled tokens, and doing yourself what a library should do. This closing post is the practical security checklist.
Identity is the front door to everything, which makes it the most attacked part of most systems. The protocols are secure by design — but only if you use them correctly, and the failures are remarkably consistent: skipped validations, mishandled tokens, and rolling your own.
Logging a user in is the easy part; keeping them logged in — and, harder than anyone expects, logging them out — is where identity gets subtle. Sessions bridge stateless requests into a continuous identity, single sign-on shares that identity across apps, and single logout is a genuinely hard problem that most systems get partly wrong.
Logging a user in is the easy part; keeping them logged in — and, harder than anyone expects, logging them out — is where identity gets subtle. Single logout is a genuinely hard problem that most systems get partly wrong.
The power of code agents comes with a sharp edge: you are executing code written by an LLM, and an LLM can be wrong, or manipulated into writing something harmful. Running that code unsandboxed is one of the most dangerous things you can do in an application, so sandboxing isn't optional for code agents — it's the price of admission.
The power of code agents comes with a sharp edge: you are executing code written by an LLM, which can be wrong or manipulated. Running it unsandboxed is one of the most dangerous things you can do — so sandboxing is the price of admission.
SAML is older, XML-heavy, and unfashionable — and it still runs enterprise identity, because the corporate world standardized on it a decade before OIDC existed and enterprise software moves slowly. If you build anything sold to businesses, you will meet SAML, and understanding it as "the same federated-login idea as OIDC, different machinery" is what makes it approachable.
SAML is older, XML-heavy, and unfashionable — and it still runs enterprise identity. If you build anything sold to businesses you will meet SAML, and understanding it as 'the same federated-login idea as OIDC, different machinery' makes it approachable.
The "s" in HTTPS is TLS, and it does three things at once that most engineers conflate: it encrypts the connection, verifies you're talking to the real server, and detects tampering. Understanding how — the handshake, the certificates, the chain of trust — demystifies the padlock icon and the certificate errors that block deploys, and it's foundational to every secure connection you make.
The 's' in HTTPS is TLS, and it does three things engineers often conflate: encrypts the connection, verifies you're talking to the real server, and detects tampering. Understanding the handshake, certificates, and chain of trust demystifies the padlock and the cert errors.
Everyone kept using OAuth to log users in, and everyone kept doing it slightly wrong, because OAuth was never designed to answer "who is this user?" OpenID Connect is the fix: a thin, standardized authentication layer on top of OAuth that adds one crucial thing — an ID token that securely tells you who the user is. It's what "Sign in with Google" actually runs on.
Everyone kept using OAuth to log users in, and kept doing it slightly wrong, because OAuth was never designed to answer 'who is this user?' OpenID Connect is the fix: a thin authentication layer on OAuth that adds an ID token. It's what 'Sign in with…' runs on.
When agents from different organizations delegate real work to each other, trust cannot be assumed, so A2A builds authentication into the Agent Card and demands it on every request.
When agents from different organizations delegate real work, trust cannot be assumed, so A2A builds authentication into the Agent Card and demands it on every request.
An MCP server can run code and see context on the model's behalf, which makes it powerful and dangerous in equal measure — this is how to deploy one without handing attackers the keys.
An MCP server can run code and see context on the model's behalf. Authentication, prompt-injection and tool-poisoning risks, human-in-the-loop, sandboxing, and a production checklist.
Sanctions screening looks simple — check if a name is on a list — and is genuinely hard, because names are messy, lists are fuzzy, and the penalty for a miss is among the most severe in all of compliance. It's a string-matching problem with strict-liability stakes, which is exactly what makes the false-positive-versus-false-negative balance so unforgiving.
Sanctions screening looks simple — check if a name is on a list — and is genuinely hard, because names are messy, matching is fuzzy, and the penalty for a miss is among the most severe in compliance: a string-matching problem with strict-liability stakes.
Tokens are the currency of modern identity — they carry proof of authorization and identity across every request. But "token" hides real distinctions: access versus refresh versus ID tokens do different jobs, and a JWT you can read but must validate correctly is a razor that cuts both ways. Most identity vulnerabilities live in how tokens are issued, stored, and checked.
Tokens are the currency of modern identity — access, refresh, and ID tokens do different jobs, and a JWT you can read but must validate correctly is a razor that cuts both ways. Most identity vulnerabilities live in how tokens are issued, stored, and checked.
AI systems add attack surface that traditional security does not cover — the model, its prompts, its retrieved context, and its tools are all attackable — and the only way to know you're defended is to threat-model the whole surface and prove it with red-teaming.
AI adds attack surface conventional security misses — model, prompts, retrieved context, and tools are all attackable. Phase 7: threat-model the whole surface and prove it with red-teaming.
Logs are the oldest and most detailed telemetry — the granular record of what actually happened. But the log line you write for a human to read with grep is nearly useless at scale; the one you write as structured data for a machine to query is the one that saves you at 3 a.m. The shift from text logs to structured logs is the single biggest upgrade most teams can make.
Logs are the most detailed telemetry — the record of what actually happened. But the log line you write for a human to grep is nearly useless at scale; the one you write as structured data for a machine to query is the one that saves you at 3 a.m.
OAuth isn't one procedure — it's a family of flows for different kinds of clients, and picking the wrong one is a security bug, not a style choice. The good news is that modern guidance has collapsed the confusion: for almost every case today, the answer is the authorization code flow with PKCE, and knowing why the alternatives were deprecated is knowing OAuth security.
OAuth isn't one procedure — it's a family of flows for different clients, and picking the wrong one is a security bug. Modern guidance collapsed the confusion: for almost every case, the answer is the authorization code flow with PKCE.
OAuth solved a specific, once-terrible problem: how does an app access your data on another service without you handing over your password? Its answer — a scoped, revocable token granted through a trusted intermediary — is elegant, but only if you remember what OAuth actually is. It's authorization, not login, and everything about it makes sense once you hold that firmly.
OAuth solved a once-terrible problem: how does an app access your data on another service without your password? Its answer — a scoped, revocable token through a trusted intermediary — is elegant, but only if you remember it's authorization, not login.
A model that scores well in evaluation still has to serve real traffic within a latency budget, isolate tenants, plan for capacity, and enforce safety in the request path — and the guardrails have to be inline, not a filter someone can route around.
A model that scores well still has to serve traffic within a latency budget, isolate tenants, plan capacity, and enforce safety in the request path — inline, not as a filter someone can route around. Phase 5.
Half of all identity confusion — and a surprising share of security bugs — comes from blurring two words that sound alike and mean opposite things. Authentication asks "who are you?"; authorization asks "what are you allowed to do?" Every protocol in this series exists to answer one or the other, and mixing them up is how you build systems that are both insecure and broken.
Half of all identity confusion — and a surprising share of security bugs — comes from blurring two words: authentication asks 'who are you?', authorization asks 'what are you allowed to do?' Every protocol in this series answers one or the other.
A single pre-launch red-team decays the moment your model, prompt, or tools change — turning adversarial testing into a sustained program is what keeps an AI system safe past day one.
The capstone: making red-teaming a sustained program — the remediation loop where findings become regression tests, blending automated/manual/external modes, rules of engagement, ship-blocking severity thresholds, governance evidence, and culture.
The DevSecOps series finale — shifting right to runtime, turning compliance into code, closing the incident feedback loop, measuring what matters, and the culture that makes secure the default path.
The capstone: shifting right to continuous security — runtime detection and vulnerability management as a loop, security observability and tamper-evident audit, compliance-as-code with evidence from the pipeline, metrics that matter, and the culture (paved roads, champions).
The finale of the API Security series — how to bake security into the way APIs are designed, built, tested, shipped, and operated, so that every control from the previous seven posts becomes a repeatable part of the pipeline instead of a one-time heroic effort.
The capstone: baking security into the API lifecycle — shift-left threat modeling, CI gates (SAST, SCA, secret scanning, spec-driven authz/BOLA and DAST tests that fail the build), an OWASP-API-Top-10-to-control map, and incident response.
The series finale: how to proactively find AI security failures before attackers do — turning injection, leakage, and excessive-agency risks into a repeatable adversarial test suite that runs in CI, measuring attack success honestly, and standing up incident response for the day a control fails.
Find AI security failures before attackers do: adversarial testing of the whole system, a test taxonomy mapped to the series, automated tooling (PyRIT, garak), a CI security-regression suite that fails the build, honest attack-success-rate measurement, and AI incident response.
Turning red-team attacks into metrics you can act on and track over time — attack success rate, coverage, severity, and trend — plus the honest limits of what any of those numbers can tell you.
Turning attacks into metrics: attack success rate and why it's subtle, scoring success (rule/classifier/LLM-judge with its biases), coverage across the taxonomy, severity weighting, tracking trends per model/prompt version, and honest reporting of residual risk.
Securing the runtime platform end to end — hardened images, least-privilege workloads, default-deny networks, and admission control as the gate that decides what is ever allowed to run.
Securing the runtime platform: minimal non-root images scanned for CVEs, the container isolation model and hardening (drop caps, read-only FS, seccomp), and Kubernetes — Pod Security Standards, RBAC, default-deny NetworkPolicies, and admission control (Gatekeeper/Kyverno).
Part seven of the API Security series: the perimeter and runtime layer that enforces security consistently — the gateway as a policy enforcement point, the limits of a WAF, keeping an honest inventory of every endpoint you expose, hardening defaults, and watching the traffic for abuse you can only see at runtime.
The perimeter and runtime layer: the API gateway as a policy enforcement point (and why it can't replace per-service authz), WAF limits, improper inventory management (shadow/zombie APIs), security misconfiguration, and runtime detection.
Part seven of the AI Security Engineering series: DevSecOps for AI systems — securing the secrets, network, supply chain, prompts, and CI/CD gates that surround the model, so a hardened model doesn't sit inside a soft pipeline.
DevSecOps for AI: secrets in a manager not code, least-privilege runtime identities (no ambient prod creds for agents), egress control, rate/spend limits against model DoS, supply-chain verification in CI, prompts-as-code, and a security-eval gate that fails the build.
Scaling red-teaming beyond manual probing — the building blocks of an automated harness (seed library, mutation, orchestrator, scorer), LLM-driven adaptive attackers, the real tools by role (PyRIT, garak, promptfoo, Giskard), and wiring it all into CI as a repeatable gate.
Scaling red-teaming: the harness building blocks (attack seeds, mutation, orchestrator, scorer), adaptive LLM-driven attackers, the real tools by role (PyRIT, garak, promptfoo, Giskard), and integrating an automated red-team gate into CI.
The two specialist lenses a reviewer switches on for a diff — thinking like an attacker to catch the injection and the missing authorization check, and thinking like production to catch the N+1 query — while knowing exactly where the human eye stops and a scanner, profiler, or load test has to take over.
The specialist lenses: security review (untrusted input to a sink, missing authz/BOLA, secrets, SSRF, new dependencies) and performance review (N+1 queries, unbounded queries, missing indexes) — flag the smells, defer depth to scanners and profilers.
Why your Terraform is a security control point, how misconfiguration scanners catch public buckets and open ingress before apply, and how to encode org guardrails as executable policy with OPA/Rego, Conftest, and Sentinel instead of a wiki page nobody reads.
Securing infrastructure definitions and enforcing guardrails automatically: IaC scanning (Checkov/tfsec/Trivy) for misconfig, drift detection, and policy-as-code with OPA/Rego + Conftest so org rules block bad infra before apply — not in a wiki.
Part six of the API Security series: encrypt every byte in transit and at rest, hand out only the data a caller actually needs, and keep the keys that protect it out of your code and under a rotation policy.
Protecting data in transit and at rest: TLS everywhere (even internal, zero-trust), mTLS for service-to-service, minimizing sensitive data exposure, encryption at rest with managed keys, secrets management, a correct CORS allow-list, and redacting logs.
The defensive layer that screens what goes into a model and what comes out — input rails, output rails, topical rails, and groundedness checks — plus the real tooling ecosystem and a vendor-neutral Python pipeline that wraps a model call and knows how to refuse.
The defensive layer that screens inputs and outputs: input/output/topical/groundedness rails, the real ecosystem (Llama Guard, Granite Guardian, NeMo Guardrails, Guardrails AI, Presidio, hosted moderation), and a vendor-neutral guardrail pipeline — with honest false-positive/negative trade-offs.
Governance is the one phase whose ordering is non-negotiable: every major framework treats it as a lifecycle function established up front, and retrofitting it after an incident is how you end up with unexplainable models and regulatory exposure.
Governance is the one phase whose ordering is non-negotiable — established before real users, not retrofitted after an incident. Phase 1: NIST AI RMF, EU AI Act risk tiers, ISO 42001, and the artifacts to produce now.
Why agents and retrieval turn a prompt injection into real-world action, how to red-team the highest-risk AI surface with benign canaries, and the least-privilege controls that shrink an attacker's blast radius.
The highest-risk modern surface: indirect injection via RAG/tools, tool abuse and excessive-agency exploitation, memory poisoning, multi-step attacks, and data-exfiltration channels — with a canary methodology and least privilege as the primary control.
How to move from hardcoded passwords toward dynamic, short-lived, audited credentials — the hierarchy from bad to good, the role of a real secrets manager, and why a leaked secret is compromised the instant you push it.
Keeping credentials out of code and under control: the bad-to-good hierarchy, secrets managers (Vault/KMS), dynamic short-lived secrets, rotation that consumers actually pick up, and workload identity / OIDC so CI and services never store a long-lived key.
Part five of the API Security series: why limits are a security control and not just an ops knob, how the four rate-limiting algorithms trade off, which dimensions to key on, and how to protect expensive queries and sensitive business flows from bulk abuse.
Rate limiting as a security control (OWASP API4/API6): the algorithms and their trade-offs, keying on authenticated identity not just IP, 429 + Retry-After, protecting expensive operations, and defending sensitive business flows from bulk abuse.
Part five of the AI Security Engineering series: the two OWASP LLM risks that live in the plumbing around the model — the documents your agent retrieves and the models, datasets, and dependencies it is built from — and the Python patterns that treat both as untrusted until proven otherwise.
Securing the components around the model: RAG as an injection and poisoning vector (treat retrieved content as hostile, enforce provenance and per-user authz) and supply-chain risk (safetensors over pickle, model provenance, pinned and vetted dependencies and tools).
A defender's tour of the attacks that target the model and its data — prompt and context extraction, training-data memorization, membership inference and model inversion, model stealing, poisoning and backdoors, and evasion — with what a red-teamer tests and what actually stops each one.
Attacks on the model and its data: system-prompt and training-data extraction, membership inference and model inversion, model stealing, and poisoning/backdoors — what to test and defend, and the honest risk difference between using hosted models and training your own.
Securing everything you didn't write — from finding known-vulnerable dependencies with SCA, to generating an SBOM you actually act on, to proving provenance with signatures and SLSA so you know and verify what you ship.
Securing everything you didn't write: SCA for known-vulnerable dependencies, the supply-chain threat model (typosquatting, dependency confusion, build compromise), SBOMs (SPDX/CycloneDX), and provenance/integrity with SLSA and Sigstore signing.
Part four of the API Security series: treat every byte crossing the boundary as hostile, validate against a schema you control, parameterize at the data sink, and never let a client-supplied URL become a pivot into your network.
Treating every input as hostile: schema/DTO validation (allow-list, reject unknown fields), injection defenses (parameterized queries), and SSRF — allow-listing destinations and blocking internal/link-local ranges including via redirects.
Two tightly-linked OWASP LLM risks that turn a clever prompt injection into real-world damage — and the Python patterns that shrink the blast radius: treat model output as untrusted input, and give agents the least agency they can get away with.
Two OWASP risks that turn an injection into damage: insecure output handling (model output is untrusted input — never eval/shell/SQL it unescaped) and excessive agency (least-privilege tools, allow-lists, human approval for irreversible actions, audit logs).
Four techniques, each protecting against a different threat, each with real costs — how do you actually decide what to use? Privacy-preserving machine learning in practice isn't about picking one silver bullet; it's about understanding your threat model and composing the right techniques to meet it. This closing post is the decision framework the series was building toward: match the tool to the threat, pay the trade-offs honestly, and combine for defense in depth.
Four techniques, each for a different threat, each with real costs — how do you decide? Start with the threat model (what, from whom, at what stage), compose for defense in depth (federated learning + DP + secure aggregation), anchor on differential privacy's provable guarantee, and price the privacy-utility trade-off deliberately.
A defender's field guide to the injection and jailbreak techniques a red-teamer probes for — the taxonomy, why each one works, and how to turn it into a re-runnable test suite that maps every passed test to a concrete fix.
A deeper, test-focused look at injection and jailbreak families — direct vs indirect (the RAG/agent threat), role-play, obfuscation, many-shot, multi-turn, cross-lingual — plus a red-team methodology: build a probe suite, mutate, test input and retrieval paths, measure, re-test.
How the four families of automated security tests — static analysis, dynamic analysis, secret scanning, and instrumented runtime testing — fit together across a pipeline, and why tuning signal-to-noise matters more than adding scanners.
Automated security testing in the pipeline: SAST vs DAST vs IAST and their trade-offs, secret scanning (including git history), where each runs, and making findings actionable so false-positive fatigue doesn't get the scanner muted.
Why the biggest class of API bugs is not about who you are but about what you are allowed to touch — and how to check ownership, function access, and property access on every single request.
The dominant class of API bugs: broken object level authorization (BOLA/IDOR — the #1 API risk), broken function level authorization, and object property level (mass assignment / excessive data exposure) — with allow-listed DTOs, ownership checks, and deny-by-default.
Part three of the AI Security Engineering series: protecting the data that flows through an LLM system — how sensitive information leaks out of prompts, logs, and retrieval, and the engineering controls (redaction, data minimization, per-user retrieval authz, residency choices) that actually stop it.
Protecting data in LLM systems: sensitive-information disclosure, PII in prompts and logs (your observability can be the leak), redaction with Presidio, data residency, and per-user access control on the retrieval layer so RAG doesn't leak across tenants.
Sometimes the goal isn't to compute privately on real data but to produce data that's safe to share, publish, or hand to a less-trusted team — data that looks and behaves like the real thing without being about any real person. Synthetic data and anonymization promise exactly this, and they're widely used — but they also hide the subtlest privacy traps in the whole field. This post covers how to make shareable data, and the honest truth about how well it actually protects privacy.
Sometimes the goal is data safe to share. Anonymization (generalization, suppression, k-anonymity) is fragile against re-identification; synthetic data looks safe but the generator can memorize real people. The fix is the recurring move — differentially private synthetic data — and the lesson that nothing is automatically private.
Before you attack an AI system you need a map of it: the components an adversary can influence, the trust boundaries between them, and a taxonomy that sorts attacks by goal and stage so your red-teaming is systematic instead of a grab-bag of the attacks that happen to trend that week.
Mapping the AI attack surface so red-teaming is systematic: threat-modeling the components (model, prompts, training/RAG data, tools, guardrails) and an attack taxonomy by goal (integrity/availability/privacy/abuse) and stage (training vs inference), aligned to NIST AI 100-2 and ATLAS.
How to design security in from the first sketch instead of bolting it on before launch — mapping security work to every phase of the software lifecycle, grounded in the NIST Secure Software Development Framework, and using STRIDE-based threat modeling as the core design activity.
Designing security in from the start: the secure SDLC mapped to NIST SSDF, security requirements and abuse cases, and threat modeling with the four questions and STRIDE — data-flow diagrams, trust boundaries, and continuous (not one-time) modeling.
The second post in the API Security series — a practical tour of API keys, session cookies, bearer tokens, OAuth 2.0, OIDC and JWTs, plus how to verify a token correctly and where authentication quietly breaks.
Proving who is calling: API keys vs sessions vs bearer tokens, OAuth 2.0 grant types and OIDC, and JWT validation done right — the alg:none / algorithm-confusion pitfalls, verifying signature/exp/aud/iss, and access vs refresh token rotation.
Why the #1 risk on the OWASP LLM Top 10 has no clean fix — the model can't tell your instructions apart from the text it reads — and the defense-in-depth pattern that actually shrinks the blast radius.
The #1 LLM risk: direct vs indirect prompt injection (the latter is the real threat for RAG and agents), jailbreak families, and honestly-rated defense-in-depth — delimiting untrusted data, least-privilege tools, human-in-the-loop, and detection's limits.
What if you could compute on data while it stays encrypted the entire time — never decrypting it, never seeing it, yet getting the correct result? It sounds impossible, but cryptography makes it real. Homomorphic encryption and secure multi-party computation let parties jointly compute on sensitive data that none of them can read, closing the one gap the other privacy techniques leave open: protecting data even during the computation itself. This post covers the most mathematically remarkable tools in the privacy toolkit.
What if you could compute on data while it stays encrypted, never seeing it, yet get the right result? Homomorphic encryption (math on ciphertext — private inference) and secure multi-party computation (secret sharing — the basis of secure aggregation) close the gap of protecting data in use — the strongest and most expensive tools.
The opening post of a hands-on series for builders: what it means to systematically stress-test an AI system — model, prompts, retrieval, tools, and guardrails — to surface its failures before adversaries or ordinary users do, how that differs from pentesting and robustness testing, and the frameworks and ethics that keep the work rigorous.
The opener to a defensive AI red-teaming series: stress-testing AI systems (models + prompts + RAG + tools + guardrails) to find failures before adversaries do — how it differs from pentesting, the frameworks (OWASP GenAI, MITRE ATLAS, NIST AI 100-2), and ethical rules of engagement.
The opening post of a DevSecOps series — how security stops being a gate at the end of delivery and becomes an automated, shared responsibility built into every stage of the pipeline.
The opener to a DevSecOps series: building security into the delivery lifecycle instead of bolting it on — shift-left (and shift-right), security as everyone's job, the CI/CD pipeline as the enforcement point, and the automated controls the series wires up.
Why APIs became the primary attack surface, how API risk differs from classic web-app risk, and the OWASP API Security Top 10 framework this series builds on.
The opener to an API security series: why APIs are the primary attack surface, the OWASP API Security Top 10 (BOLA, broken auth, BFLA, SSRF, misconfiguration, inventory…), how API security differs from web-app security, and how to threat-model an API.
Why LLM and agent applications open a genuinely new attack surface, the mental models to reason about it (OWASP Top 10 for LLM Applications, MITRE ATLAS, NIST AI RMF), and how to threat-model an AI system before you write a line of defensive code.
The opener to a series on securing LLM and agent systems: why AI apps have a new attack surface (instructions and data share one channel, tools grant real power), the OWASP Top 10 for LLM Applications, MITRE ATLAS, and how to threat-model an AI system.
The most direct way to protect data is to never move it. Federated learning trains a shared model across many devices or organizations without their data ever leaving home — the model travels to the data, learns locally, and only the lessons (not the data) come back. It's how your phone's keyboard improves without uploading what you type, and how hospitals can build a shared model without sharing patient records. This post is about learning from data you're never allowed to see.
The most direct way to protect data is to never move it. Federated learning trains where the data lives (phones, hospitals) and shares only model updates — data minimization by architecture. But updates leak too, so it's combined with differential privacy and secure aggregation; it changes the threat model, not the threat.
The theory of differential privacy is elegant; applying it to machine learning training is where it gets real. The key technique, DP-SGD, modifies the ordinary training loop so the resulting model carries a provable privacy guarantee — it demonstrably can't have memorized any individual's data too strongly. This post is about how differential privacy actually gets into a model, the knobs that control it, and the honest trade-offs that decide whether it's worth it.
DP-SGD modifies training — per-example gradient clipping plus calibrated noise, with privacy accounting across every data access — so the resulting model carries a provable guarantee it couldn't have memorized any individual. The knobs (ε, clipping, noise) and the honest costs (accuracy, fairness, compute).
Most privacy protections are hopes dressed as techniques — remove the names, add some noise, trust that it's enough. Differential privacy is different: it's a precise mathematical definition of what privacy means and a provable guarantee that an individual's data can't be inferred from a result. It is the gold standard of privacy, used by the US Census and major tech companies, and understanding its single core idea is understanding what it actually means to protect a person in a dataset.
Differential privacy defines privacy mathematically: the output is essentially the same whether or not any individual is included, so nothing specific about you can be inferred. Calibrated noise, the privacy budget ε, the privacy-utility trade-off, and why DP (US Census, Apple, Google) is the gold standard.
A trained model feels like a safe abstraction — it's just numbers, a learned function, surely it reveals nothing about the specific data it saw. That intuition is wrong, and a family of attacks proves it: models memorize their training data and can be made to give it up. Understanding these attacks is what turns privacy from a vague worry into a concrete threat you can defend against — and it's why the formal techniques in the rest of the series exist.
A trained model feels safe — it's just numbers — but models memorize their training data and can be made to give it up. Membership inference, model inversion, training-data extraction, and model stealing — many working with only black-box API access, which is why a model trained on sensitive data is itself sensitive data.
When an AI agent spends your money, "the user said so" is not evidence. A signed mandate chain is.
A deep dive on the mandate chain as evidence: verifiable credentials (VCs), signing, the non-repudiable Intent→Cart→Payment chain, revocation and expiry, and why this replaces 'trust me, the user said so' with cryptograp…
Machine learning runs on data, and the most valuable data is often the most sensitive: medical records, financial transactions, personal messages, location histories. This creates a fundamental tension — the models that could help most need exactly the data we're least willing to expose. Privacy-preserving machine learning is the set of techniques that resolve this dilemma, letting us learn from sensitive data without surrendering it. This series builds those techniques from first principles, starting with why the problem is real and harder than it looks.
ML wants more, centralized, detailed data; privacy wants less, distributed, minimized — and the highest-value ML sits where that tension is sharpest. Why the naive protections fail (anonymization → re-identification; securing data ≠ securing the model), and the four techniques that make privacy an engineered, provable property.
The last mile of a financial system isn't code — it's who can do what, who approves it, and how you prove the whole thing is correct.
The last mile isn't code — it's who can do what, who approves it, and how you prove it's correct. Segregation of duties, four-eyes, an auditable change trail, and property tests that assert ledger invariants over thousands of scenarios.
In a multi-agent system, a shared identity means one compromised agent carries every agent's blast radius. Here's how I split agent identity across three layers.
Most teams give a whole multi-agent app one workload identity, so one hijacked agent has every agent's blast radius. Splitting identity across app, cloud, and crypto layers shrinks it to a single role and makes the audit trail provable.
Arrays and strings in C are where the pointer model from the last post becomes concrete — and where C's most infamous security bugs live. An array is a contiguous block of memory whose name decays to a pointer; a string is just an array of characters with a null terminator and no length field. Understanding both, and the buffer overflows they invite, is essential C literacy.
Arrays and strings are where the pointer model becomes concrete — and where C's most infamous security bugs live. An array is a contiguous block whose name decays to a pointer; a string is just a char array with a null terminator and no length field. Understanding both, and the buffer overflows they invite, is essential C literacy.
Prompt injection can hijack what a model says, but not what it's allowed to do — as long as policy lives in a middleware pipeline the model never sees.
A system prompt saying never delete records is a suggestion the model can be talked out of. A gateway that returns FORBID for the delete tool cannot. Put enforcement where the model can't reach it and prompt injection stops mattering for access control.
An autonomous agent injects its own plan-and-execute tools at runtime. If your gateway is fail-closed, you have to find and allowlist them — deliberately.
An autonomous harness injects its own tools at runtime, tools that don't exist at build time. Fail-closed governance is only complete when it turns that blind spot into a visible block, then allowlists the known-safe internals deliberately.
How passive device and behavior signals become a trust score for auth and fraud — without turning into a surveillance liability.
How device signals and behavioral biometrics build a trust signal for auth and fraud, with privacy and false-positive trade-offs.
An agent can tighten a workload's policy, or claim a tool the workload never mentioned — but it can't loosen an explicit forbid. Here's the resolution rule.
An agent can tighten a workload's policy or claim a tool it never mentioned, but it can't loosen an explicit forbid. The subtlety everyone botches: an explicit forbid is a floor, while silence is an absence a tighter layer may fill.
Lay out a two-tier retail CBDC — central-bank ledger, intermediaries, retail wallets, and the offline mode that makes engineers nervous.
Lay out a two-tier retail CBDC: central-bank ledger, intermediaries, retail wallets, and offline modes.
Protect PINs with DUKPT key-per-transaction derivation and point-to-point encryption all the way to the HSM.
Protect PINs with DUKPT key-per-transaction derivation and point-to-point encryption to the HSM.
Design MPC / threshold-signature custody so no single party or HSM holds a whole key.
Design MPC / threshold-signature custody so no single party or HSM holds a whole key.
Solving the sending-side reliability problem — nonce sequencing, fee estimation, and replacing a transaction that gets stuck in the mempool.
Solve the sending-side reliability problem: nonce sequencing and gas/fee estimation, including stuck-transaction replacement.
How a custodial exchange hands every user a unique deposit address from a single seed, then safely consolidates the funds into treasury.
BIP-32/44 hierarchical-deterministic address derivation, per-user deposit addresses, detection/confirmation, and sweeping to cold storage.
How a custodian proves it holds what it owes, what the cryptography actually guarantees, and where the guarantee stops.
How a custodian proves it holds customer assets: Merkle tree of liabilities, on-chain reserve attestation, and the limits of PoR.
How split knowledge, dual control, and a layered key hierarchy keep a working key from ever appearing in the clear.
Teaches how to run cryptographic key management for payments: HSM-backed key hierarchies (LMK/ZMK/ZPK), key ceremonies with split knowledge and dual control, rotation, and PIN-block translation.
Securing bank-to-bank and scheme connectivity with mutual TLS, detached JWS signatures for non-repudiation, and replay protection built from nonces and timestamps.
Teaches how to secure bank-to-bank and scheme connectivity: mutual TLS with certificate pinning/rotation, detached JWS/XML message signing for non-repudiation, and replay protection with nonces and timestamps.
How to safely credit on-chain deposits and finalize settlement: confirmation-depth thresholds, mempool tracking, chain-reorg detection with balance rollback, and idempotent handling of replaced transactions.
Teaches how to safely credit crypto deposits and finalize settlement: confirmation-depth thresholds, mempool/pending tracking, chain-reorg detection and balance rollback, and idempotent handling of replaced transactions.
How to engineer a fiat-backed stablecoin: mint-on-deposit and burn-on-redeem flows tied to a reserve ledger, a 1:1 reserve invariant, and continuous reconciliation between on-chain supply and off-chain custody balances.
Teaches how to engineer a fiat-backed stablecoin: mint-on-deposit / burn-on-redeem flows tied to a reserve ledger, 1:1 reserve invariant checks, and reconciliation between on-chain supply and off-chain custody balances.
How to architect wallet tiers, HD-derived deposit addresses, HSM/MPC signing quorums, and sweep flows so no one key, and no one person, can move funds.
Teaches how to architect custody: hot/warm/cold wallet tiers, HSM or MPC key custody, withdrawal approval quorum, address derivation (HD wallets), and sweep flows from deposit to cold storage.
How a chip card proves it is genuine on every single transaction — and why a cloned magstripe never could.
How the chip generates an ARQC, the issuer validates it and returns an ARPC, plus offline data authentication (SDA/DDA/CDA) and terminal risk management.
When software spends money on your behalf, the merchant has to answer two questions before the charge clears: which agent is this, and what did the human actually let it do.
How a merchant verifies WHICH agent is acting and WHAT it may do.
How a custodian actually safekeeps client assets — account structures, the custody network, settlement instructions, and the books-and-records engine that keeps it all honest.
How a custodian holds assets in omnibus vs segregated accounts, the CSD/sub-custodian network, settlement instructions, and asset-servicing (income, proxy, tax).
How Visa and Mastercard are reshaping tokenization so an AI agent can pay on your behalf — with scoped credentials, agent-aware identity, and the network doing what it has always done: authenticate, authorize, tokenize.
How the card networks are adapting tokenization for agents.
OWASP Agentic Top 10 coverage with YAML policy files, two API surfaces, and a metric bridge that shows policy denials in Grafana.
Request → N-eyes approve → window-of-time → automatic expiry, with every transition written to a hash-chained audit log. The package that closes Gap #1 from the PCSE map.
Every Professional Cloud Security Engineer exam bullet, mapped to a file path in an RBI FREE-AI aligned Go platform. Where the implementation matches, where the analog substitutes, and where the honest gaps are.
The mental model that says no two adjacent layers share a single point of failure for the same class of attack. From TLS to OTel, the eleven layers a customer request crosses before an answer comes back.
The long-form security narrative for a multi-agent financial assistant — authentication, authorisation, tenant isolation, dual-identity audit, envelope encryption, hash-chained logs, governance, red team, BCP.
Twelve months of running multi-agent AI in a regulated context. SLIs that matter, the incident runbook, drift detection, continuous adversarial testing, secret rotation, compliance posture as code.
Passkeys are FIDO2; FIDO2 is the spec; Ed25519 is the signature algorithm. The full registration + assertion flow in 200 lines of stdlib Go.
Two signals do most of the work for detecting compromised sessions: impossible travel between consecutive logins, and credential-stuffing density across an IP range. The Go implementation.