Founder & CEO, DeepInspect Inc.
Software engineer and architect. Founder of DeepInspect.ai. Publishes deeply technical AI-governance posts at singhspeak.com.
NIS2 took effect at the Member State level by October 18, 2024. The directive covers essential and important entities across 18 sectors. AI used in those operations falls under Article 21 cybersecurity risk management and Article 23 incident reporting. Audit trail expectations are operational.
DORA took effect January 17, 2025. The regulation treats AI vendors as ICT third-party service providers. Financial entities must maintain a register of contractual arrangements, monitor concentration risk, and demonstrate exit strategies. AI inference sits squarely inside the obligation.
HIPAA Security Rule audit controls require recording activity in systems that contain PHI. AI deployments produce that activity at the prompt layer. OCR audits request per-request records of PHI exposure to AI services. Application logs fail. The architecture that survives is independent of the application.
ISO 27001 is the information security management system standard. ISO 42001 is the AI management system standard published December 2023. The two standards integrate at the controls layer. Annex A controls in ISO 27001:2022 cover the same evidence ISO 42001 expects for AI-specific risk treatment.
SOC 2 reports cover five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. AI deployments touch all five. The audit evidence that AICPA expects has to be operational, not architectural. Application logs and policy documents fail. The records that pass are per request.
A Business Associate Agreement with an AI vendor transfers HIPAA obligations under specific conditions. OpenAI, Anthropic, Microsoft, AWS, and Google offer BAAs to enterprise tiers. The agreement covers what the vendor does with PHI; it does not eliminate the covered entity duty to record disclosures.
HIPAA requires that PHI is redacted or de-identified before disclosure to entities outside a Business Associate Agreement. AI prompts routinely contain PHI. Inline redaction at the AI request boundary is the only architecture that produces the per-request evidence HHS expects under a HIPAA audit.
NIST AI RMF is a voluntary US framework. The EU AI Act is binding law with penalties reaching 35M EUR or 7% of global turnover. The two frameworks converge on the same operational evidence: per-request records that capture identity, classification, policy state, and decision outcome.
NIST AI RMF 1.0 defines four functions: Govern, Map, Measure, Manage. The framework is voluntary, but federal procurement and state AI laws increasingly cite it as the baseline. Implementation runs to dozens of decisions across identity, classification, policy enforcement, and audit. Most deployments stop at Govern.
SaaS companies that embed AI features in product flows are pulled into the EU AI Act through their customers. If the customer uses the SaaS in a high-risk use case, the customer is the deployer and the SaaS company is often the provider. The mandate takes effect August 2, 2026.
GDPR governs the processing of personal data. The EU AI Act governs the operation of AI systems. The two regimes overlap on automated decision-making and divergent on per-decision evidence. GDPR records describe what data is processed. AI Act records describe what an AI system did with a specific request.
A 23-item operational checklist for EU AI Act high-risk compliance, organized across scope, documentation, evidence, monitoring, and incident reporting. The mandate takes effect August 2, 2026. Items 12 to 18 are where most deployments fail.
EU AI Act compliance breaks into six operational workstreams: scope classification, technical documentation, conformity assessment, runtime evidence, deployer monitoring, and incident reporting. The mandate takes effect August 2, 2026. Most organizations are running three of the six and missing the rest.
Article 6 of the EU AI Act establishes a two-branch test for classifying an AI system as high-risk. Branch one covers safety components of regulated products. Branch two covers the Annex III use cases. The classification triggers the full operational regime from August 2, 2026.
Annex III of the EU AI Act lists the eight categories of AI systems classified as high-risk. Inclusion in Annex III triggers the full obligations of Articles 8 to 27 from August 2, 2026. Most enterprise teams are inside the scope without realizing it.
Article 99 of the EU AI Act sets three penalty tiers reaching 35M EUR or 7% of global turnover for prohibited practices, 15M EUR or 3% for high-risk non-compliance, and 7.5M EUR or 1% for supplying misleading information. The mandate takes effect August 2, 2026.
Article 26 of the EU AI Act puts operational obligations on the deployer of a high-risk AI system. The deployer must monitor operation, suspend use under specific risk conditions, keep automatically generated logs, and inform the provider and authorities. The mandate takes effect August 2, 2026.
Article 19 of the EU AI Act sets the operational floor for log retention from high-risk AI systems at six months and specifies what the automatically generated logs must contain. The mandate takes effect August 2, 2026. Application logs fail the structural test.
Article 13 of the EU AI Act requires providers of high-risk AI systems to design them so deployers can interpret outputs, understand limitations, and exercise human oversight. The mandate takes effect August 2, 2026. Generic model cards fail the test.
Mandiant M-Trends 2026 measured median attack handoff at 22 seconds. At that tempo, log-and-alert fails as a control. Inline enforcement at the AI request boundary makes the policy decision before the request reaches the model. Under 50 ms enforcement overhead is invisible against 500 ms to 5 second model inference.
Model guardrails are trained behaviors inside the inference process. They degrade under fine-tuning, adversarial prompting, and role-play framing. External enforcement at the AI request boundary produces deterministic controls and identity-bound audit records that guardrails alone cannot.
Zero trust applied to AI means evaluating every model request against verified identity, current policy, and prompt-level classification. The architectural pattern is an enforcement proxy at the HTTP AI request boundary. The post-authentication gap is the most common failure mode in current deployments.
NIST Pillar 1 names verified agent identity as the foundation of the AI agent identity and authorization framework. Per-agent identifiers, delegated authority from the authorizing user, and structured propagation to the model API call are the production requirements. Static service credentials fail the test.
AI agent security is the operational practice of constraining autonomous agents to act only within delegated authority and producing per-decision audit records that survive regulatory review. The NIST three-pillar framework names the architecture. Application logs and model guardrails do not satisfy it.
Six agentic AI architecture patterns dominate production deployments today: ReAct, plan-and-execute, multi-agent crews, retrieval-augmented agents, code-executing agents, and tool-using single agents. The security architecture differs across each. The enforcement layer always sits at the HTTP AI request boundary.
LangChain, LangGraph, AutoGen, CrewAI, and the OpenAI Assistants API each ship a different agent loop. The security properties of each framework determine what an enforcement layer can see and what it cannot. The architectural divergence matters at the AI request boundary.
Generative AI returns a response to a human-issued prompt and waits for the next instruction. Agentic AI issues prompts on its own initiative, applies the response, and chains the next call. The architectural divergence has direct consequences for identity, policy enforcement, and audit trails.
Agentic AI security is the practice of constraining what autonomous agents can request, what data they can include in prompts, and what evidence each decision leaves behind. Static credentials, model guardrails, and application logs fail the test. The enforcement layer has to sit at the HTTP AI request boundary.
IBM Cost of Data Breach data shows that organizations breached through unsanctioned AI tools pay an average of $670,000 more per incident than the cross-industry baseline, take 247 days to detect, and lose customer PII in 65% of cases.
Article 12 of the EU AI Act mandates that high-risk AI systems automatically record events over the system lifetime. The logs must reconstruct what happened, who initiated it, and what data was involved. Penalties reach 15M EUR. Most AI deployments produce zero compliant records today.
On May 8, 2026, GitGuardian classified 28,000 passwords on public GitHub as LLM-generated. The mechanism is per-model Markov chain analysis applied to a dataset of 34 million credentials observed between November 2025 and March 2026. Detection at the leak point is the start of the forensic chain. Attribution comes next: which authenticated user issued the prompt, which model returned it, under what role. Those answers come from AI traffic logs that captured identity at the call boundary. This post covers what that capture looks like in practice.
On April 30, 2026, six national cybersecurity agencies published Careful Adoption of Agentic AI Services. It defines five risk categories for agentic AI: privilege, design and configuration, behavioral, structural, and accountability. Three of those (privilege, behavioral, accountability) are enforceable at the agent-to-LLM traffic boundary. The other two belong to deployment architecture. This post maps the three operational categories to the runtime control patterns that satisfy them.
UK AISI put agent task-completion duration on a two-month doubling curve. Quarterly audit cadences fall behind almost immediately. The gap looks like an audit calendar problem, but the mechanism underneath is a missing system of record for AI decisions, written synchronously at decision time, identity-bound, and signed inline.
Zero-trust AI enforcement applies the "never trust, always verify" principle to AI traffic. Every LLM request is authorized per authenticated identity, inspected against policy on the request side before forwarding, and recorded in a tamper-evident audit ledger as part of the same request lifecycle. The model receives only prompts that have already cleared policy.
A defensible AI audit trail is a per-request record of identity, input, policy decision, mutation, output, and policy version, committed to append-only storage with a per-record cryptographic signature that lets any single record be verified independently. It survives FRE 901 authentication, HHS OCR requests, and EU AI Act Article 12 scrutiny. Most AI deployments produce logs. Few produce evidence.
HIPAA Technical Safeguards under 45 CFR 164.312 apply to AI systems the moment PHI enters a prompt. The Security Rule requires audit controls, transmission security, and access control on your side of the API. A Business Associate Agreement with an LLM vendor governs the vendor only. Your obligations remain.
The EU AI Act obligations for high-risk AI systems apply from August 2, 2026. Article 9 requires a documented risk management system. Article 12 requires automatic record-keeping. Article 13 requires transparency to deployers. Article 14 requires human oversight. Enterprises deploying high-risk AI systems need enforcement and audit infrastructure in place before that date.
Mandiant M-Trends 2026 reports that attack handoff time collapsed from 8 hours to 22 seconds. At that tempo, log-and-alert on AI traffic is structurally incapable of preventing damage. If your AI enforcement operates on a review cycle measured in minutes, the breach is complete before the first alert fires. AI traffic enforcement must be inline and synchronous.
On April 8, Fannie Mae issued Lender Letter LL-2026-04, a governance framework for AI and ML in mortgage origination and servicing. It takes effect August 8. Freddie Mac already enforces similar requirements since March 3. Both GSEs now require approved seller/servicers to operate an auditable AI governance program. Most lenders have no infrastructure to comply.
IBM's Cost of Data Breach Report studied 600 breached organizations and found that one in five experienced breaches linked to shadow AI. Those breaches cost $670,000 more on average. Customer PII exposure jumped to 65%, compared to 53% across all breaches. Intellectual property carried the highest cost per record.
Last week, *The Register* reached out to the major AI application vendors—Microsoft, SAP, Oracle, Salesforce, ServiceNow, and Workday—and asked a simple question: How much liability do you accept when your AI agents make bad decisions? Microsoft and SAP declined to comment. Oracle, Salesforce, ServiceNow, and Workday didn't respond. That silence is your answer. For every CISO, CRO or head of legal deploying AI today, that silence has a direct consequence: You are the insurer of last resort for your vendor's model.
On March 18, Meta's internal AI agent exposed sensitive user and company data to engineers who shouldn't have seen it. The exposure lasted two hours. Meta classified it as Sev-1. Here's the part that should concern every security architect: the agent was fully authenticated. It had valid credentials. It passed every identity check. And it still caused a data breach. This is the post-authentication gap.
Last year, researchers disclosed EchoLeak (CVE-2025-32711), a zero-click Indirect Prompt Injection in Microsoft 365 Copilot. A poisoned email forced the AI assistant to silently exfiltrate sensitive business data to an external URL. The user never saw it, never clicked a link, and never authorized the transfer, but the data left anyway. Most leaders I talk to think they are "covered" because their LLM provider is SOC2 compliant or has a signed DPA. However, in the eyes of the law, the liability remains with the deployer
NIST's comment window on AI agent identity and authorization closes April 2. If you are deploying AI agents and haven't read the framework, this is the post. Not because the comment window matters to your engineering roadmap, but because NIST just put formal language around a structural gap that most organizations are already sitting in.
Stanford's Trustworthy AI research has demonstrated that model-level guardrails can be materially weakened under targeted fine-tuning and adversarial pressure. In controlled evaluations summarized by the AIUC-1 Consortium briefing, (developed with CISOs from Confluent, Elastic, UiPath, and Deutsche Börse alongside researchers from MIT Sloan, Scale AI, and Databricks), refusal behaviors were significantly degraded once safety patterns were shifted.
On February 23rd, [Anthropic published](https://www.anthropic.com/news/detecting-and-preventing-distillation-attacks) something the industry had suspected but hadn't seen documented at this scale. Three Chinese AI labs (DeepSeek, Moonshot AI, and MiniMax) ran coordinated campaigns against the Claude API. They generated over 16 million exchanges through approximately 24,000 fraudulent accounts. The goal was not to steal user data but to steal the model itself.
Aurascape's research team this week published SilentBridge, a class of indirect prompt injection attacks against Meta's Manus AI agent. The attack exfiltrated email, extracted secrets, achieved root-level code execution, and exposed cross-tenant media files via CDN — all three variants scored CVSS 9.8 (Critical): network-exploitable, no privileges required, no user interaction. The user had authorized Gmail and the agent used it exactly as permitted. Vulnerabilities discovered September 2025, Manus mitigated November 2025, coordinated disclosure February 2026.
The Clinejection attack chained prompt injection, cache poisoning, and a credential isolation failure into a supply chain compromise. Here is the attack anatomy and what structural controls actually stop it.
Most RAG stacks retrieve top-K chunks first and enforce permissions later in the app. At scale, this breaks the trust boundary and degrades retrieval quality. When users only have access to a subset of the corpus, post-filtering collapses top-K into a tiny context window, even when many relevant authorized chunks exist deeper in the index. The fix is to make retrieval identity-aware so authorization becomes part of ranking. In the blog, I walk through how to design identity-aware retrieval so access control is enforced during search, not after it.
The most complex risks in the 2026 OWASP list are not about a single bad action, but about how agents exist over time, interact with each other, and propagate behavior across systems. Unchecked blast radius occurs when **probabilistic agent behavior becomes persistent, trusted, and shared across systems**. This post continues from my previous two pieces on [Loss of Intent as a Failure Mode in OWASP Agentic AI Risks](/blog/loss-of-intent-as-a-failure-mode-in-owasp-agentic-ai-risks-2026) (Part 1) and [Identity and Execution Risks in Agentic AI – The Capability Gap](/blog/identity-and-execution-risks-in-agentic-ai-the-capability-gap-owasp-2026) (Part 2) and is the final part of the series.
When moving from intent to execution, the security model for Agentic AI shifts from intent interpretation to traditional systems hardening. Once an LLM can invoke tools and assume identities, the capabilities we grant an agent become the primary attack surface. This post continues from my first piece on [Loss of Intent as a Failure Mode in OWASP's Agentic AI Risks](/blog/loss-of-intent-as-a-failure-mode-in-owasp-agentic-ai-risks-2026). Here, I focus on the second bucket in the [OWASP Top 10 for Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/): agents with too much power.
OWASP recently released the Top 10 Vulnerabilities for Agentic Applications (2026). One thing is clear that the agentic systems fail differently than traditional applications or simple LLM integrations. The failure mode is not bad output, but the system taking a valid action for the wrong reason. In this post, I break down three OWASP vulnerabilities that stem from loss of intent, explain how they show up in real systems, and outline some mitigations.
Agents often appear structured at the planning level, but at runtime their execution becomes increasingly non-deterministic once tools, retries, partial failures, and replanning are introduced. This can easily become an economic denial of service (EDoS) attack.
Aikido Security recently uncovered a new class of CI/CD vulnerabilities they call **PromptPwnd**. The gist of the issue is simple: steps in the CI/CD workflows (e.g. GitHub Actions and GitLab pipelines) are increasingly using AI agents like Gemini CLI, Claude Code and OpenAI Codex to triage issues, label pull requests or generate summaries. These workflows sometimes embed untrusted user content—issue titles, PR descriptions or commit messages—directly into the prompts fed to the model. In this blog I will explore the core of the issue and some potential solutions.
The core of the issue with the Antigravity failure was that the AI assistant treated data as instructions, then executed those instructions through its tool layer with no human in the loop. This can happen not just in IDEs but agents in general.In this blog, I will demonstrate the failure using a local model and some scripting and will present good practices on how to prevent them.
From a development perspective, most AI security problems come from the workflow around the model, not the model itself. The issues usually show up in the inputs, the data paths, and the decisions that run without any guardrails.
AI adoption is accelerating across industries, transforming how businesses operate and innovate. As companies embrace AI, it is crucial to understand the security and privacy implications. This article will explore security considerations when building custom AI solutions and integrating AI into business operations.