InfoSec Compliance & AI Governance For over 20 years, DISC InfoSec has been a trusted voice for cybersecurity professionals—sharing practical insights, compliance strategies, and AI governance guidance to help you stay informed, connected, and secure in a rapidly evolving landscape.
Large Language Models (LLMs) are revolutionizing the way developers interact with code, automating tasks from code generation to debugging. While this boosts productivity, it also introduces new security risks. For example, maliciously crafted prompts or inputs can trick an LLM into producing insecure code or leaking sensitive data. Countermeasures include rigorous input validation, sandboxing generated code, and implementing access controls to prevent execution of untrusted outputs. Continuous monitoring and testing of LLM outputs is also essential to catch anomalies before they escalate into vulnerabilities.
The prompt itself has become a critical component of the attack surface. Prompt injection attacks—where attackers manipulate input to influence the model’s behavior—pose a novel security threat. Risks include unauthorized data exfiltration, execution of harmful instructions, or bypassing model safety mechanisms. Effective countermeasures involve prompt sanitization, context isolation, and using “safe mode” configurations in LLMs that limit the scope of model responses. Organizations must treat prompt security with the same seriousness as traditional code security.
Securing the code alone is no longer sufficient. Organizations must also focus on securing prompts, as they now represent a vector through which attacks can propagate. Insecure prompt handling can allow attackers to manipulate outputs, expose confidential information, or perform unintended actions. Countermeasures include designing prompts with strict templates, implementing input/output validation, and logging prompt interactions to detect anomalies. Additionally, access controls and role-based permissions can reduce the risk of malicious or accidental misuse.
Understanding the OWASP Top 10 for LLM-powered applications is crucial for identifying and mitigating security risks. These risks range from injection attacks and data leakage to model misuse and broken access control. Awareness of these threats allows organizations to implement targeted countermeasures, such as secure coding practices for generated code, API rate limiting, proper authentication and authorization, and robust monitoring of model behavior. Mapping LLM-specific risks to established security frameworks helps ensure a comprehensive approach to security.
Building trust boundaries and practicing ethical research are essential as we navigate this emerging cybersecurity frontier. Risks include model bias, unintentional harm through unsafe outputs, and misuse of generated information. Countermeasures involve clearly defining trust boundaries between users and models, implementing human-in-the-loop review processes, conducting regular audits of model outputs, and following ethical guidelines for data handling and AI experimentation. Transparency with stakeholders and responsible disclosure practices further strengthen trust.
From my perspective, while these areas cover the most immediate LLM security challenges, organizations should also consider supply chain risks (like vulnerabilities in model weights or third-party APIs), adversarial attacks on training data, and model inversion risks where sensitive information can be inferred from outputs. A proactive, layered approach combining technical controls, governance, and continuous monitoring is critical to safely leverage LLMs in production environments.
Here’s a concise one-page visual brief version of the LLM security risks and mitigations.
LLM Security Risks & Mitigations: One-Page Brief
1. LLMs and Code Interaction
Risk: LLMs can generate insecure code, leak secrets, or introduce vulnerabilities.
Countermeasures:
Input validation on user prompts
Sandbox execution for generated code
Access controls and monitoring outputs
2. Prompt as an Attack Surface
Risk: Prompt injection can manipulate the model to exfiltrate data or bypass safety mechanisms.
Countermeasures:
Prompt sanitization and template enforcement
Context isolation to limit exposure
Safe-mode configurations to restrict outputs
3. Securing Prompts
Risk: Insecure prompt handling can allow misuse, data leaks, or unintended actions.
Countermeasures:
Structured prompt templates
Input/output validation
Logging and monitoring prompt interactions
Role-based access control for sensitive prompts
4. OWASP Top 10 for LLM Apps
Risk: Injection attacks, broken access control, data leakage, and model misuse.
Countermeasures:
Map LLM risks to OWASP Top 10 framework
Secure coding for generated code
API rate limiting and authentication
Continuous behavior monitoring
5. Trust Boundaries & Ethical Practices
Risk: Model bias, unsafe outputs, misuse of information.
Countermeasures:
Define trust boundaries between users and LLMs
Human-in-the-loop review
Ethical AI guidelines and audits
Transparency with stakeholders
Perspective
LLM security requires a layered approach: technical controls, governance, and continuous monitoring.
At DISC InfoSec, we help organizations navigate this landscape by aligning AI risk management, governance, security, and compliance into a single, practical roadmap. Whether you are experimenting with AI or deploying it at scale, we help you choose and operationalize the right frameworks to reduce risk and build trust. Learn more at DISC InfoSec.
Prompt injection attacks can have serious security implications, particularly for AI-driven applications. Here are some potential consequences:
Unauthorized data access: Attackers can manipulate AI models to reveal sensitive information that should remain protected.
Bypassing security controls: Malicious inputs can override built-in safeguards, leading to unintended outputs or actions.
System prompt leakage: Attackers may extract internal configurations or instructions meant to remain hidden.
False content generation: AI models can be tricked into producing misleading or harmful information.
Persistent manipulation: Some attacks can alter AI behavior across multiple interactions, making mitigation more difficult.
Exploitation of connected tools: If an AI system integrates with external APIs or automation tools, attackers could misuse these connections for unauthorized actions.
Preventing prompt injection attacks requires a combination of security measures and careful prompt design. Here are some best practices:
Separate user input from system instructions: Avoid directly concatenating user input with system prompts to prevent unintended command execution.
Use structured input formats: Implement XML or JSON-based structures to clearly differentiate user input from system directives.
Apply input validation and sanitization: Filter out potentially harmful instructions and restrict unexpected characters or phrases.
Limit model permissions: Ensure AI systems have restricted access to sensitive data and external tools to minimize exploitation risks.
Monitor and log interactions: Track AI responses for anomalies that may indicate an attempted injection attack.
Implement guardrails: Use predefined security policies and response filtering to prevent unauthorized actions.
Strengthen your AI system against prompt injection attacks, here are some tailored strategies:
Define clear input boundaries: Ensure user inputs are handled separately from system instructions to avoid unintended command execution.
Use predefined response templates: This limits the ability of injected prompts to influence output behavior.
Regularly audit and update security measures: AI models evolve, so keeping security protocols up to date is essential.
Restrict model privileges: Minimize the AI’s access to sensitive data and external integrations to mitigate risks.
Employ adversarial testing: Simulate attacks to identify weaknesses and improve defenses before exploitation occurs.
Educate users and developers: Understanding potential threats helps in maintaining secure interactions.
Leverage external validation: Implement third-party security reviews to uncover vulnerabilities from an unbiased perspective.
Why the simplest agent harness is also the most secure, most governable, and most auditable one…
Every component you add to an AI agent is a component an attacker can reach, an auditor must test, and your team must explain after an incident. That is the whole argument of this post, and it is why the most effective agents I review are also the plainest.
I see the same pattern in agent design reviews across B2B SaaS and financial services. Engineers who would reject a needless microservice in a web app will happily ship a five-agent pipeline, a vector database, and three MCP servers. The job underneath usually needed one model call inside a loop.
The demo looks impressive. The threat model does not. Each extra agent is another identity. Each extra tool is another path to a real-world effect. Each extra MCP server is another supplier in your chain. Each extra document in the context window is another place an injected instruction can hide.
Thesis: complexity in an agent harness is not a neutral engineering choice. It is attack surface, audit scope, and liability, accrued one convenient decision at a time. The cheapest security control you will ever implement is the component you decided not to build.
The golden rule, read as a security engineer
Faan Rossouw at AionSec recently published Stop Overengineering Your Agents, and it names the discipline cleanly. His golden rule of harness engineering: “Only ever make things as complex as they need to be.”
He builds it out of progressive disclosure, the context-engineering principle that a model should receive only what the current step requires and pull in more on demand. The idea comes from UX design, and engineers know it as lazy loading. Rossouw’s move is to apply the same shape, exactly what the job needs, nothing more, to every harness decision: tools, MCP, skills, orchestration, and RAG. The stopping point differs per layer. The rule is not “use less everywhere”. It is “match the need, then stop”.
He also cites Anthropic’s own guidance in Building Effective AI Agents: start with the simplest workable solution, add complexity only when it earns its place, and accept that the right answer is sometimes no agent at all. When the vendor selling model calls tells you that, believe it.
Rossouw frames the rule as an engineering principle. I want to add the governance reading, because it is the same rule wearing a different badge:
Discipline
Name for the same idea
UX design
Progressive disclosure
Software engineering
Lazy loading, YAGNI
Context engineering
Minimal, just-in-time context
Security architecture
Least privilege, least functionality, attack surface reduction
AI governance
Proportionality: controls scaled to intended use and impact
Audit
Scope minimisation: fewer components, fewer controls to evidence
The security community has preached least privilege for fifty years. Agent builders are rediscovering it from the performance side. Good: when the cost argument and the security argument point the same way, the right design stops needing a champion.
Complexity is attack surface, layer by layer
Every layer of a harness has a “just enough” point. Everything past it is risk you chose to carry with no business return. The table maps each layer to what overbuilding looks like, the threat it invites, and the matching category in the OWASP Top 10 for Agentic Applications (ASI) or the OWASP LLM Top 10.
Harness layer
Right-sized
Overbuilt
Threat it invites
OWASP mapping
Context
What this step needs, pulled just in time
Every policy, ticket, and email pre-loaded “in case”
More untrusted text in the window means more room for indirect prompt injection and sensitive data leakage
ASI01 Agent Goal Hijack; LLM01, LLM02
Tools
The few tools this job requires, narrowly scoped
A general execute_command or http_request tool “for flexibility”
A hijacked agent inherits every capability you granted, whether or not the task needed it
Only when knowledge is too large to inject directly
A vector store for a 40-page policy set
Embedding leakage, poisoned documents, and weak access control on the index
LLM08 Vector and Embedding Weaknesses
Autonomy
Human approval on consequential actions
Fully autonomous loops for convenience
Over-trust of confident output and actions no one would have approved
ASI09 Human-Agent Trust; ASI10 Rogue Agents
Read the “Overbuilt” column as a list of findings. I have written most of them in real assessment reports, and none of them was there because the business needed it. They were there because they were easy to add and nobody asked whether the job required them.
One compounding effect deserves its own line. Risks in a harness multiply rather than add. A broad tool is dangerous; a broad tool plus pre-loaded untrusted context is an exploit path; add a second agent that trusts the first agent’s output and the path now crosses a trust boundary nobody drew. Removing any one of those components breaks the chain.
Does this job need a model? The deterministic default is a security control
Rossouw pushes the rule down to the smallest unit: for each step, ask whether it needs a model at all. His answer is that code is the default, and the model earns a step only when the work requires interpretation, meaning ambiguity, judgment, or meaning.
His example is detecting beaconing in network telemetry. Whether a connection is regular enough to be a beacon is arithmetic, so code does it. Whether that regular connection is malicious or a software updater checking in is judgment, so the model does it. Same data, two jobs.
From a security and assurance view, that split matters more than the performance gain:
Property
Deterministic code
Model step
Prompt injection
Not applicable; input cannot rewrite the logic
Every input is a potential instruction
Testing
Unit tests prove behaviour
Evaluations estimate behaviour at a pass rate
Repeatability
Identical on every run
Varies with model version, prompt, and context
Audit evidence
Code, tests, and change records
Prompts, evals, traces, and drift monitoring
Failure mode
Usually loud
Can be wrong in ways that look right
Cost per run
Effectively zero
Paid on every call
This turns into a design rule I now use in reviews: controls belong in code; judgment belongs in the model. Authorisation checks, rate limits, allow-lists, value thresholds, data-classification gates, and approval routing are deterministic decisions. If your agent “decides” whether it is allowed to send a wire, export a dataset, or delete a record, you have placed a security control inside the one component that can be talked out of it. AionSec makes the same point in a companion piece, Your Prompt Is Not a Security Boundary.
In practice, most of a well-built agent is ordinary software. The model is a small, well-fenced judgment engine inside it.
Run every step through this gate. Only work that needs open-ended judgment reaches an agent, and even then the bounds live in code.
The smallest harness is the most auditable one
In my last post, The Harness Is the Contract, I argued that the useful question is not whether an agent can act. It is whether every consequential path was declared, bounded, and left evidence another party can verify. The golden rule is what makes that standard achievable at all.
Consider the work each property demands, and how it scales with harness size:
Declared. For every tool, you must write down its worst case if the agent is fully adversarial. Twelve tools means twelve worst cases, plus their combinations. Three tools is an afternoon. A general execute_command tool has no worst case you can write down, which is exactly the problem.
Bounded. Each path needs a deterministic limit outside the model: scope, rate, value, approval. Every extra agent, MCP server, and memory store is another place a bound has to be enforced and tested.
Verifiable. Each component must emit evidence a sceptical third party can rely on. A five-agent pipeline produces five interleaved traces and the hand-offs between them. A single agent with three tools produces one trace you can actually read.
Overengineering does not only add risk. It makes your governance claims harder to prove, and controls are rarely why organisations fail audits; evidence is. That held at Virtual Data Room, where we took the AI management system through ISO/IEC 42001 Stage 2 certification on the first attempt. The MCP Governance Standard I wrote there leaned on the same instinct: every integration had to justify itself before it was allowed into the execution path.
Here is how right-sizing lines up with the frameworks your customers and regulators will ask about. Treat it as a crosswalk, not a claim that one control satisfies another.
Art. 12 record-keeping, Art. 14 human oversight, Art. 15 robustness and cybersecurity, Art. 26 deployer obligations
Logs that reconstruct actions; oversight points on consequential steps
OWASP ASI Top 10
ASI02, ASI03, ASI04, ASI08 shrink directly as tools, permissions, suppliers, and agents shrink
Threat model per declared path; test results per ASI category
The practical upshot for a CISO: the right-sizing review is not an engineering nicety you hope happens. It is a documented risk-treatment decision, and it belongs in your AI management system with an owner and a date.
What the rule does not cut: controls are not overengineering
There is a lazy reading of “less engineering” that I want to head off, because I have already heard it in client meetings: “Simplicity first, so we’ll skip the approval step and the logging for now.” That is not the golden rule. That is the golden rule used as an excuse.
The rule says match the need. For any agent that touches customer data, money, production systems, or regulated decisions, the need includes the safety layer. So spend your complexity budget deliberately:
Spend less on
Spend enough on
Number of agents
Policy enforcement outside the model
Number of tools and their breadth
Human approval on consequential, irreversible actions
Pre-loaded context
Input and output validation at trust boundaries
Third-party MCP servers
Supplier vetting and version pinning for the ones you keep
Persistent memory
Tamper-evident logs that reconstruct what the agent did
Clever orchestration patterns
Kill switch, rate limits, and spend caps
The left column is capability. The right column is assurance. Capability you do not need is risk; assurance you do need is not overhead. A simple agent with strong guardrails beats a sophisticated agent with weak ones every time, in production and in the audit.
One more caution: “simple” is a property of the system, not of the diagram. A single agent with one run_sql tool against the production database looks minimal on a whiteboard. It is not. Measure simplicity by the size of the blast radius, not by the number of boxes.
The Right-Sizing Review: twelve questions before you ship
Run this at design review and again before each release. Any “no” or “not sure” is either a component to remove or a risk to accept in writing.
Scope
Could this be a single model call, or a workflow with fixed steps, instead of an agent?
For each step, can you say why it needs judgment rather than code?
Context and memory
Does each step receive only the data it needs, pulled at the time it needs it?
Does persistent memory exist for a stated purpose, with scope, expiry, and attribution?
Tools and identity
Can you name the worst case of every tool if the agent is fully hijacked, in one sentence?
Is any tool general-purpose (shell, raw SQL, arbitrary HTTP) where a narrow function would do?
Does the agent run on credentials scoped to this task, rather than a shared service account?
Integrations
For each MCP server, what does it give you that a direct API call would not?
Is every third-party server and model version pinned, reviewed, and owned?
Orchestration
If there is more than one agent, what can the second one do that the first could not, and how is trust between them checked?
Assurance
Are authorisation, limits, and approvals enforced in code outside the model?
Could a sceptical outsider reconstruct what the agent did last Tuesday from your logs alone?
Twelve questions sounds like a lot. On a right-sized agent, it takes under an hour. On an overbuilt one, it takes a week, and that difference is the finding.
A 30-day right-sizing plan for agents already in production
Most teams are not designing from scratch. They are living with agents that grew. Here is how to shrink them safely.
Week 1: Inventory. List every agent, tool, MCP server, memory store, vector index, and credential. Record the owner and the business purpose of each. Anything with no owner is your first finding.
Week 2: Justify. Run the twelve questions against each agent. Tag every component keep, narrow, or remove. Expect a third of tools and most general-purpose tools to land in the last two buckets.
Week 3: Cut and move controls. Remove unused tools and servers. Replace broad tools with narrow functions. Move any authorisation logic that lives in a prompt into code. Scope credentials per task.
Week 4: Prove it. Re-test against the OWASP ASI categories that changed. Record each decision as a risk treatment in your AI management system, with evidence. Set the review to repeat at every major model or tool change.
The usual outcome is an agent that is cheaper to run, faster, more accurate, and has a threat model that fits on one page.
My perspective
The AI industry is about to learn the lesson the cloud industry learned a decade ago: most breaches will not come from exotic attacks on the model. They will come from capability nobody needed, granted to a component nobody reviewed, logged in a way nobody could reconstruct.
Rossouw is right that something about building with AI pulls disciplined engineers toward complexity. I would add that governance teams feel the same pull in reverse: piling on frameworks and policies instead of asking what the system actually does. The answer for both is the same rule. Build what the job needs. Govern what you built. Prove both.
Less engineering is not less rigour. It is rigour applied before the code exists, which is the cheapest place it will ever be.
Right-size your agents with DISC InfoSec
DISC InfoSec helps B2B SaaS and financial services teams build agents that are secure by design and certifiable on evidence. We led Virtual Data Room through ISO/IEC 42001 Stage 2 certification on the first attempt, and we bring that same practitioner lens to your agent harness.
Start wherever you are on the readiness ladder:
Free 20-minute call. Walk through one agent and leave with the three components most likely to be overbuilt.
Gap assessment. ISO 42001 gap assessment or ISO 27001 gap assessment.
7–10 day Quick-Start. An Agent Right-Sizing Review against OWASP ASI, ISO 42001, and NIST AI RMF, with a prioritised cut list and evidence pack.
Implementation and certification support, or an ongoing vCISO / vCAIO retainer.
DiscInfosec – CISSP, CISM, ISO/IEC 42001 and 27001 Lead Implementer, is Principal Consultant at DISC InfoSec in Petaluma, California.
Publishing notes
Field
Value
Meta title
Less Engineering, More Effective AI Agents: Why Simple Harnesses Are Secure
Meta description
Every tool, agent, and MCP server you add is attack surface and audit scope. A practitioner’s guide to right-sizing AI agents against OWASP ASI, ISO 42001, and NIST AI RMF.
Primary keyword
AI agent security
Secondary keywords
agent harness, overengineering AI agents, least privilege AI agents, MCP security, OWASP agentic top 10, ISO 42001 AI agents
Slug
/less-engineering-more-effective-ai-agents
Internal links
The Harness Is the Contract; The Security Risks Hiding in AI Agent Memory
The cheapest security control you will ever implement is the component you decided not to build. Every tool you give an agent is a capability an attacker inherits. Every extra agent is another identity. Every MCP server is another supplier. Before you add one, ask the question Anthropic and AionSec both ask: does this job need it at all?
Agent memory is the least-governed data store in most enterprises, and it is filling up with secrets. An agent that remembers can be taught. An agent that can be taught can be poisoned. And whatever it has learned sits somewhere, usually in plain text, usually outside any control you would recognize from your ISMS.
Last week I argued that the harness is the contract: every consequential path an agent can take should be declared, bounded, and leave evidence another party can verify. Memory is the part of the harness that breaks that model quietly. A tool call happens once and shows up in a log. A memory write persists, gets replayed in every future session, and can change behavior weeks after the input that caused it.
That is why a new Help Net Security interview with Vectorize CEO Chris Latimer deserves the attention of every CISO running agents in production. His headline advice is blunt: if you do one security check this quarter, make it agent memory. I agree, and I want to go further, into what that check should look like and how it maps to the frameworks your auditors already use.
What “agent memory” actually means
Agent memory is any state an agent writes during one run and reads back as trusted context in a later run. That last clause is the whole security problem. Retrieval-augmented generation reads from a corpus someone curated; memory reads from a corpus the agent itself wrote, often from inputs nobody reviewed.
Notice the right-hand column. In a database you would never accept “anyone whose text the agent read” as the write-access policy. For most memory stores in production today, that is effectively the policy.
Four signals from the field
Latimer’s interview is short, but it lands four points that match what I see in agent design reviews.
Secrets are migrating into memory. When he read through the memory banks of the coding agents he used, he found API keys, credentials, and sensitive documents that developers had fed in, and that the agents had promoted to long-term memory. The data your secure SDLC was built to protect now sits in plain text on workstations, in cloud memory services, and in markdown files.
Extensions are the poisoning vector. He names plugins, skills, and MCP integrations as the likely entry points, because people install things that look useful without reading them. His attacker scenario targets first-time coders with a too-good-to-be-true plugin that quietly scans memory for credentials and ships them to an external endpoint.
Provenance is the forensic question. After an incident, what you most need to know is where a memory came from: an MCP server, a tool response, or an insider. Better still is filtering hostile writes before they persist, which is the idea behind OWASP’s Agent Memory Guard.
Access control is the gap vendors can’t close yet. Most products stop one user’s session from reading another user’s memories. Team memory and graduated access, the RBAC and ABAC patterns enterprises take for granted in databases and APIs, are mostly not there.
His quarterly audit prediction is the one to act on. He expects CISOs to find two things: no governance over which memory systems are in use, and a startling volume of keys, database passwords, and confidential business data sitting in those systems, ready to be exfiltrated.
That second finding is not an AI problem. It is a data-classification and secrets-management failure that AI has made faster and harder to see.
Six risks hiding in agent memory
Memory risk is durable risk. A prompt injection that lands in the context window dies with the session; one that lands in memory becomes a standing instruction.
1. Memory poisoning. Attacker-controlled text is written into memory and replayed as trusted context in future sessions. The entry point is rarely the chat box. It is a web page the agent summarized, a ticket it triaged, a tool response, or a plugin that writes directly to the store. The effect is delayed, so the incident and its cause show up weeks apart.
2. Secrets at rest in the wrong place. Every credential a developer pastes into a session is a candidate for promotion to long-term memory. Those stores rarely have encryption at rest, secret scanning, or retention limits. Your vault is hardened; the agent’s notes file next to it is not.
3. Cross-user and cross-tenant leakage. In multi-tenant products, the question is whether one customer’s memory can surface in another customer’s session. Tenant filters applied after retrieval can be talked around. They belong inside the vector query itself, enforced by the store, not the model.
4. Malicious extensions reading memory. A skill or MCP server runs with the agent’s access. If the agent can read its memory, so can the extension, and nothing stops it from sending what it finds to an external endpoint. This is supply-chain risk with a data-exfiltration payload.
5. Embedding and summary leakage. Teams treat embeddings as anonymized math. They are not; they can be inverted enough to leak source text. Summaries are worse, because they compress sensitive facts into short, retrievable sentences.
6. Unbounded retention. Memory stores grow without an owner, a retention schedule, or a deletion path. That turns a GDPR erasure request, a customer offboarding, or a legal hold into a question nobody can answer with confidence.
Where these risks sit in the threat frameworks
Every one of the six risks already has a home in the frameworks your security team uses. The work is connecting them to the memory store, which most threat models leave off the diagram.
OWASP’s Agent Memory Guard is the reference implementation for ASI06. It sits between the agent and the store, screens every read and write, and maps each finding to allow, redact, quarantine, or block. In its published benchmark it caught 92.5% of 40 attack payloads with zero false positives, and its misses were API tokens slightly longer than its fixed-length patterns. Treat it as a strong first layer, not the whole defense.
The governance lens: memory is data, and data has owners
The fastest way to get memory under control is to stop treating it as an AI novelty. It is a data store. Your AIMS and ISMS already have controls for data stores; memory just hasn’t been put in scope.
Framework
Where agent memory lands
What the auditor will ask for
ISO/IEC 42001
A.7 Data for AI systems, especially A.7.5 data provenance; A.6.2.8 event logs; A.10.3 suppliers
Memory inventory, provenance records per write, supplier assessments for memory vendors and MCP servers
ISO/IEC 27001:2022
A.5.9 asset inventory, A.5.12 classification, A.8.12 data leakage prevention, A.5.33 protection of records
Memory stores in the asset register, classified, with DLP and retention applied
Evidence that memory poisoning and leakage were tested and are monitored
EU AI Act
Art. 10 data governance and Art. 15 robustness for high-risk systems; Art. 26 deployer obligations
Proof that memory can’t silently degrade a high-risk system’s accuracy or robustness
GDPR / CCPA
Storage limitation, right to erasure, deletion requests
A working deletion path that reaches memory, embeddings, and summaries
Having taken virtual data room organization through ISO 42001 Stage 2 on the first attempt, I can tell you what certification auditors reward: a complete inventory, named owners, and evidence that reviews actually happened. Agent memory needs exactly that, and in most organizations today it has none of it.
A control framework for agent memory: govern the lifecycle, not the model
Apply the harness test to memory: every write is a declared path, every store is bounded, and every read leaves evidence. That gives five control points across the memory lifecycle.
Lifecycle stage
Declared
Bounded
Verifiable evidence
1. Admit (write)
Allow-list of sources that may write to memory; extensions denied write by default
Secret and PII scanning before persist; injection screening; size and growth limits
Provenance tag on every entry: source class, session, identity, timestamp
2. Store
Every memory store in the asset register with an owner and classification
Encryption at rest; no plain-text markdown for anything above Internal; tenant partitioning
Asset register entry; configuration evidence; SHA-256 baselines on protected keys
3. Retrieve (read)
Read scope defined per user, team, and agent role
Access filters enforced in the store’s query, not by the model; extensions get no read by default
Read logs with requesting identity and entries returned
4. Retain and expire
Retention schedule per memory class
TTLs; deletion that reaches embeddings and summaries; legal-hold override
Deletion job logs; erasure request test results
5. Respond
Incident playbook covering memory poisoning
Quarantine and point-in-time rollback
Snapshots; poisoning test results; post-incident provenance trace
Two rules do most of the work. Secrets never belong in memory: detect them at write time, block them, and rotate anything you find. No extension gets memory access it did not declare: a plugin that needs to read your agent’s memory should have to say so, and you should have to say yes.
Your 90-day plan: find it, bound it, prove it
Latimer’s informal audit is the right first step. Here is how I would turn it into a quarter of work that ends with evidence an auditor will accept.
Start with discovery, because you cannot bound what you have not found. Latimer’s prediction is that you will find unvetted memory tools on developer workstations and small shared servers, so scope the inventory to endpoints, not just production.
Five questions to ask any agent memory vendor
Can you enforce access by team and role inside the store, or only by user session?
Is every memory entry tagged with its source, and can I query by source after an incident?
Do you scan for secrets and PII before a write persists, and what happens when you find one?
When I delete a user, do their embeddings and summaries go too, and can you prove it?
Can a third-party skill or MCP server read memory it did not request, and where is that logged?
If a vendor struggles with the first question, Latimer’s experience says you are not alone. Put the gap in your risk register and compensate with network isolation and aggressive retention until the product catches up.
The bottom line
Memory is what turns an agent from a tool into a colleague, and it is what turns a one-time injection into a standing compromise. The organizations that get this right will not have better models. They will have an inventory, an owner, a write policy, and a log, the same four things that have governed every other data store for twenty years.
If your agents remember, your governance has to remember too.
Not sure what your agents have been memorizing? DISC InfoSec runs a focused Agent Memory Risk Review: we inventory memory stores across endpoints and production, scan for exposed secrets, map findings to ISO 42001, the OWASP Agentic Top 10, and NIST AI RMF, and hand you a remediation plan you can take into your next audit. Book a free 30-minute call or email info@deurainfosec.com.
DISC InfoSec, ISO/IEC 42001 and 27001 Lead Implementer, CISSP, and CISM. We led VDR organization through ISO 42001 Stage 2 certification on the first attempt.
Meta title: The Security Risks Hiding in AI Agent Memory (and a 90-Day Fix)
Meta description: Agent memory is filling up with secrets and poisoned context. Six risks, their OWASP and ISO 42001 mappings, and a 90-day plan to govern it.
But for AI agents, the model may not be the most important security boundary.
The real security boundary is the harness.
Think of the model as the reasoning engine.
The harness is the scaffolding that turns reasoning into action.
It determines:
→ What tools the agent can access → What data it can retrieve → What memory it can retain → Which identity and credentials it operates under → What code or runtime it can execute → Which systems it can reach → What policies constrain its behavior → Whether a human must approve an action → What gets logged, monitored, and audited
This creates a critical distinction:
An LLM generates a probabilistic suggestion. The harness determines whether that suggestion becomes a real-world consequence.
Consider a simple instruction:
“Delete the old customer database.”
The model may generate that instruction.
But the harness determines whether the instruction becomes an actual deletion.
Does the agent have:
• Database access? • Delete privileges? • Valid credentials? • A database tool? • Access to the production environment? • Approval to perform destructive actions? • Policy restrictions? • Audit logging? • A recovery mechanism?
The harness isn’t just scaffolding for an AI agent.
It is part of the security architecture.
DISC InfoSec Perspective
The next generation of AI security will not be won solely by building better models.
It will be won by building better control planes around models.
Organizations should start treating the AI agent harness as a first-class security component—subject to threat modeling, identity controls, least privilege, policy enforcement, monitoring, testing, and audit.
Because when AI moves from generating answers to taking actions, the distance between a model’s probabilistic output and a deterministic business consequence becomes the most important security boundary to understand.
AI Agent Security ≠Model Security.
AI Agent Security = Model + Harness + Authority + Tools + Data + Runtime + Controls.
ForceAI for production agent control
ForceAI gives customers one control plane for agent activity, models, MCP tools, sensitive data, runtime policy, and enterprise actions. Teams can define operating mandates, enforce action level authorization, monitor effects, and revoke only the authority at risk.
We help organizations secure AI agents before they act—protecting every decision, tool call, and action before it impacts your business – Vikalp (Vik) Paliwal, CEO, ForceAI Security
Disc InfoSec — Principal Consultant, DISC InfoSec (Deura Information Security Consulting LLC), Petaluma, AICP, CISSP, CISM | ISO/IEC 42001 & ISO/IEC 27001 Lead Implementer | PECB Authorized Training Partner
As requested, we would be happy to share either the Generic AI Acceptable Use Policy Template (SMB) or the Generic AI Management Policy Template (ISO 42001) for your review, so you can assess the coverage and determine which best meets your requirements.
Agentic AI Governance: Mitigating Liability and Protecting Information Assets
The model decided to do that” is not a legal defense
The previous post in this series covered agent security controls — tool scoping, separating decision from execution, memory hygiene, egress control. That’s the engineering layer. This post is about the layer above it, the one a board, an insurer, a regulator, or opposing counsel will actually examine.
The reframe that matters is simple and unforgiving: an action taken by your agent is an action taken by your organization. There is no legal or contractual construct in which “the model decided to do that” reduces your exposure. Autonomy distributes execution. It does not distribute liability.
So the two questions this post answers are the ones I’d want answered before signing off on any agent going to production:
If this agent does something harmful, where does the liability land and what reduces it?
What information assets can this agent reach, and what stops them leaving?
Why agents invert the asset protection model
For thirty years, information security has been organised around keeping unauthorised actors away from assets. Perimeters, access control, segmentation, DLP — all of it assumes the adversary is unauthorised.
An agent is authorised. It holds legitimate credentials, calls sanctioned APIs, reads permitted repositories, and does so at machine speed. When an agent exfiltrates data, no access control was violated. The agent used exactly the permissions you gave it, in a sequence you didn’t anticipate, because its context was partly written by someone else.
That’s why the operating principle from the OWASP Agentic Security Initiative work is agency as the security boundary. An agent is not trustworthy because its underlying model is trustworthy. Trust attaches to what the agent is permitted to do, not to what produced its intentions.
Which yields a principle most organisations don’t have yet, distinct from least privilege:
Least agency — give an agent only the autonomy required for the business objective, separately from minimising its permissions.
An agent can be perfectly least-privileged and still over-agentic: narrow permissions, but authority to act on them without validation. Both dials need setting.
Where the liability actually lands
Four distinct channels, and they don’t behave the same way.
Contractual. This is the nearest-term exposure and the one most organisations walk into unknowingly. Your customer DPAs, MSAs, security addenda, and — critically — your completed vendor security questionnaires are representations. If you answered “all access to customer data is logged and reviewed” before deploying an agent that reads customer data through a service account with no per-action logging, that answer is now inaccurate. Vendor questionnaire responses are the most commonly overlooked liability surface in agent deployment, because nobody re-reads them when architecture changes.
Regulatory. Under the EU AI Act, deployers of high-risk systems carry direct obligations under Article 26 — ensure staff competence, monitor operation, notify incidents, retain logs for at least six months, inform affected workers — and Article 14 requires human oversight that constitutes a demonstrated capability to intervene, interrupt, and disregard. Under GDPR and CCPA/CPRA you remain the controller regardless of how autonomous the processing became. California’s ADMT rules add risk-assessment and notice obligations where agents contribute to significant decisions.
Negligence and standard of care. This one is slower-moving and more consequential. OWASP’s agentic guidance, ISO/IEC 42001, and the NIST AI RMF are converging into a recognised reference standard for reasonable practice. Once a documented, freely available standard exists, failing to implement its obvious provisions becomes evidence of a failure to meet the standard of care. “We didn’t know agents could be prompt-injected” stopped being credible some time in 2025.
Supply chain and value chain. Your model provider’s terms limit their liability; they do not transfer yours. If an agent harms your customer, your customer sues you. ISO 42001’s A.10.3 is specifically about allocating responsibilities across the AI value chain — and the allocation you write down is the one you’ll be held to. Read your provider terms for what they don’t cover.
The practical implication: liability mitigation is not primarily about preventing incidents. It’s about being able to demonstrate that you exercised reasonable care, in writing, before the incident. Which is an evidence problem, not a security problem.
Risk tiering: the one artifact that makes the rest tractable
Most agent governance fails because it tries to apply uniform controls to non-uniform risk. Tier first, then control proportionally. Four tiers, and the tier drives who signs and what’s mandatory.
Tier
Definition
Typical examples
Mandatory controls
Approval authority
1 — Assistive
Produces information or recommendations; cannot independently execute consequential actions
Drafting, summarisation, low-risk analysis
Inventory, owner, acceptable use, basic logging
Team lead
2 — Controlled action
Executes reversible or low-impact actions under bounded permissions
Materially affects legal rights, safety, critical infrastructure, regulated decisions, major financial outcomes, or irreversible operations
Credit or eligibility decisions, payment initiation, regulated disclosure, security control modification
Tier 3 plus human approval for consequential actions, independent policy enforcement, segregation of duties, formal TEVV, documented residual-risk acceptance, tested emergency shutdown
Executive + documented board or committee awareness
Two notes from applying this. Tier assignment should be based on maximum action impact, not typical action impact — an agent that files tickets 99% of the time and can delete a production table 1% of the time is a Tier 3 agent. And anything unclassified defaults to the higher tier, not the lower one; ambiguity is not an argument for less control.
Use a plain 5Ă—5 likelihood Ă— impact model, and raise the impact rating whenever the agent can access regulated data, reach production, move money, modify security controls, affect legal or rights outcomes, execute code, control physical systems, or propagate actions to other agents.
Deployment gates: turning governance into a decision
An agent should not reach production until seven gates pass. This is the mechanism that converts principles into a defensible record, and it’s the thing to build first because everything else hangs off it.
Gate
What it establishes
Owner
1 — Inventory
Agent identified, owner assigned, business purpose documented, risk tier assigned
Kill switch, rollback, credential revocation, and incident response procedure each tested, recovery owner assigned
SecOps + engineering
7 — Governance
Risk assessments approved, ISO 42001 and NIST AI RMF crosswalks completed, residual risk accepted, evidence package complete
Risk owner
Gate 6 is where I see the most theatre. A kill switch that exists in a runbook and has never been executed is not a control — it’s an assumption. Test it, record the test, and record how long it took.
The output of the gate process should be one explicit disposition, not a vague sign-off: approved, approved with conditions, restricted, remediate before deployment, rejected, or suspended — each with the risk tier, material findings, residual risk, required controls, control owners, approval authority, and an expiry date. Approvals without expiry dates decay into permanent permission.
Prohibited design patterns
The fastest way to raise the floor across an organisation is a short list of patterns that are critical findings unless explicitly justified and formally risk-accepted:
Unrestricted shell, filesystem, or internet access
Shared administrator credentials, or long-lived unrestricted tokens
Model output alone authorising a privileged action
Autonomous modification of security controls, or autonomous credential creation
Unvalidated dynamic tool loading; untrusted MCP servers in privileged workflows
Untrusted agent-to-agent delegation
Persistent memory without provenance or lifecycle control
Production access without rollback; no tested kill switch for high-impact agents
An agent approving its own high-impact action
An agent controlling its own security monitoring
Those last two deserve their own sentence. They are segregation of duties, restated for non-human actors. We have decades of consensus that the person who initiates a payment shouldn’t approve it, and that administrators shouldn’t be able to edit the logs that record their activity. Both principles apply unchanged to agents, and both are routinely violated in agent architectures because the agent is convenient and the separation is friction. If you write one governance rule this quarter, write that one.
The corollary for incident response: do not rely on the compromised agent to determine whether it is compromised. Detection, containment, and forensics must sit outside the agent’s own execution path — which is also why monitoring at the syscall, network, and identity layers beats monitoring the agent’s self-reported activity.
Protecting the information assets specifically
Agents create asset classes your data inventory probably doesn’t cover.
Agent memory is a data store. It holds fragments of everything the agent has processed, usually with no classification, no retention schedule, and no owner. It needs all three. Memory also needs provenance — you should be able to say where an entry came from and whether the source was trusted — plus TTLs, write authorisation, quarantine, and rollback.
Deletion rights now reach further than most programs realise. A GDPR erasure request or a CCPA deletion request has to propagate to agent memory, conversation state, vector embeddings, and cached retrieval indices. Embeddings derived from personal data are still personal data. Most deletion pipelines were built before any of these stores existed, and I’d treat “can we actually delete from the vector store and the agent’s memory” as a question to answer before the first request arrives rather than during the response window.
Prompts and system instructions are assets. They encode business logic, control boundaries, and sometimes proprietary process knowledge. They’re also a target — extraction gives an attacker your control design. Version them, restrict who can change them, and treat a prompt change as a change requiring reassessment.
Audit evidence is an asset. The logs proving your controls operated are what stand between you and an adverse inference. They need integrity protection and retention aligned to the longest applicable requirement — for EU high-risk deployers, at least six months under Article 26, though contractual and litigation-hold needs often run longer.
And on classification: the agent’s context window should be governed by your data classification scheme, not by whatever the retrieval layer happened to return. Restricted data should be redacted before entering context, not filtered on the way out.
Controls are not effective because they exist
A rating scale worth adopting verbatim, because it forces honesty. Rate every agent control from 0 to 5: 0 not implemented, 1 ad hoc, 2 partially implemented, 3 defined, 4 implemented and evidenced, 5 measured, tested, and continuously improved.
Most organisations sit at 3 and report 4. The gap between “defined” and “evidenced” is exactly where audit findings live. A control should not be rated effective merely because a policy exists.
One crosswalk caution, since I do this work for a living and see it done badly: do not claim an ISO 42001 control is satisfied because an OWASP mitigation is in place. They’re different instruments. OWASP ASI gives you agent-specific threat identification and testing; 42001 gives you management-system accountability, documented process, risk treatment, and continual improvement; the NIST AI RMF gives you the GOVERN / MAP / MEASURE / MANAGE lifecycle. Record an explicit crosswalk with the applicability decision, implementation status, owner, and evidence for each — not a mapping table asserting equivalence. An auditor will test the claim, not the table.
Monitoring and reassessment triggers
Track as security KPIs: denied and unauthorised tool calls, privilege-escalation attempts, prompt-injection detections, policy violations, anomalous actions, credential misuse, exfiltration attempts, memory-integrity violations, and inter-agent authentication failures.
Track as risk indicators — these are leading, and they’re the ones governance functions miss: agent permission growth, new tools and connectors, model version changes, prompt changes, skill changes, MCP or A2A changes, new memory sources, new data classifications entering scope, and new autonomy levels.
Reassess on any of: model change, major prompt change, tool or permission change, new external agent or MCP connection, material architecture change, new sensitive data in scope, new regulatory requirement, security incident, or significant behavioural drift. Note that most of those are routine engineering events, which is why annual review cycles don’t work for agents. Tie reassessment to change control, not to the calendar.
From the practitioner’s chair
Two things I’d emphasise from having done this rather than read about it.
When I led ShareVault — a virtual data room platform serving M&A and financial services clients — through ISO 42001 Stage 2 certification on the first attempt, and later served as internal auditor, the recurring lesson was that controls were almost never the failure point. Evidence was. The organisations that struggle aren’t the ones without controls; they’re the ones that can’t produce the artifact showing a control operated on a specific date under a specific policy version.
And when I audited that organisation’s MCP Governance Standard and produced a v1.1 redline with 27 changes — covering OAuth 2.1 with PKCE, token audience validation, SSRF and egress controls, tool manifest integrity, and confused-deputy protections — the pattern across nearly all of them was one idea: authority must be bound to a specific action rather than held ambiently by a component. An unaudienced token is authority without a destination. An unverified tool manifest is authority without a definition. A confused-deputy gap is authority without a requester. Liability follows unbound authority with remarkable consistency.
What to do in the next 90 days
Inventory the agents, including the ones nobody registered. You cannot govern, tier, or defend what isn’t listed. Expect to find more than you think, particularly agent features embedded in tools you already buy.
Tier them by maximum action impact and identify every Tier 3 and Tier 4 agent. Those get attention first; the rest can wait.
Re-read your customer commitments and your last three vendor questionnaire responses against what your agents can now actually do. Fix the inaccurate answers before a customer finds them.
Publish the prohibited-patterns list as policy, and require a named risk acceptance for any exception.
Test one kill switch end to end and write down how long it took. That single artifact will tell you more about your real posture than any maturity assessment.
Stand up the gate process and route the next agent through it. The first one is slow; the fifth is routine.
The organisations that come through the next two years cleanly won’t be the ones that avoided agent incidents. They’ll be the ones who can show a documented risk decision, made by a named person, on a dated record, with the evidence that the controls they claimed were operating actually were.
Work with DISC InfoSec
DISC InfoSec helps B2B SaaS and financial services organisations deploy agentic AI that survives both an attacker and an auditor: agent discovery and inventory, risk tiering, OWASP ASI assessment, MCP and tool-permission review, deployment gate design, human oversight architecture, and the evidence packages that map to ISO/IEC 42001, NIST AI RMF, and EU AI Act Articles 14 and 26.
We led VDR organization through ISO 42001 Stage 2 certification on the first audit attempt as the internal practitioner, served as internal auditor, and authored their MCP Governance Standard. If you have agents in production and no dated record of who accepted the risk, that’s the assessment to run now.
DISC InfoSec — Principal Consultant, DISC InfoSec (Deura Information Security Consulting LLC), Petaluma, CA CISSP, CISM | ISO/IEC 42001 & ISO/IEC 27001 Lead Implementer | PECB Authorized Training Partner
This post is security and governance guidance, not legal advice. Liability allocation and regulatory scope should be confirmed with counsel.
Frameworks and references
OWASP Agentic Security Initiative; OWASP Top 10 for Agentic Applications; OWASP Agentic AI Threats and Mitigations; OWASP AI Agent Security Cheat Sheet
ISO/IEC 42001:2023 — Clauses 4–10; Annex A control themes including AI policy, impact assessment, lifecycle, data management, responsible use, third-party relationships, logging and monitoring, incident management
NIST AI RMF 1.0 (NIST AI 100-1); NIST AI 600-1 Generative AI Profile
Regulation (EU) 2024/1689 (EU AI Act), Arts. 14, 26
AI Agent Security: Nobody Authorized That Action, and That’s the Problem
The last two posts in this series ended in the same place from different directions. The one on AI-executable workflows argued that when the convertible tasks leave, what remains valuable is specification, oversight, evidence, boundary judgment, and the signature. The one on Bay Area startups argued that enterprise buyers now ask for those things before they sign.
Agents are where both arguments stop being abstract. A chatbot that gives a bad answer produces a bad answer. An agent that gets manipulated moves money, deletes records, emails your customer list, or opens a pull request. The failure mode changes from wrong output to unauthorized action — and unauthorized action is a category that security, compliance, and legal all have opinions about.
So the organizing question for this post is not “how do I make my agent safe.” It’s the one I keep landing on: when this agent takes an action, can you say who authorized it, what it was allowed to do, and prove it? Everything below is in service of being able to answer that.
Two sources worth reading in full alongside this: the OWASP AI Agent Security Cheat Sheet (CC BY-SA 4.0), which is the best free control catalogue for this problem, and Tigera’s AI Agent Security guide, which is stronger on the infrastructure and identity side. I’m synthesising both here with the governance layer they mostly leave implicit.
Why agents break the model you already have
Three structural shifts, and each one invalidates a control you probably rely on.
Data became instructions. Your input validation assumes data is inert (harmless). For an LLM it isn’t — a retrieved document, an email body, a webpage, a tool response, a Jira comment can all carry instructions the agent will follow. This is indirect prompt injection, and it means every data source your agent touches is now part of its instruction surface. Traditional sanitisation doesn’t help because there’s no syntax to strip; the payload is just words.
The actor is nondeterministic. Access control assumes a caller who does the same thing given the same permissions. An agent’s next action is a probabilistic function of its context, and its context is partly attacker-controllable. You cannot reason about what it will do; you can only bound what it can do.
Identity got separated from a human. Agents authenticate as service accounts, often with credentials broader than any human user, and frequently act on behalf of a user without carrying that user’s authorisation scope. That gap is the confused deputy problem: the agent has authority the requester doesn’t, and the requester can steer the agent. Tigera’s framing is the right one — treat each agent as a first-class managed identity with its own credentials, lifecycle, and decommissioning, rather than a process borrowing someone else’s.
A threat model you can hold in your head
OWASP enumerates thirteen risks and Tigera seven. Overlapping them, I find five clusters more useful for actually designing controls, plus one meta-risk:
Cluster
What it covers
The control that matters most
Instruction integrity
Direct and indirect prompt injection, goal hijacking, malicious configuration fed through developer consoles
Trust boundaries between instructions and data; never let retrieved content carry authority (untrusted data)
Memory poisoning that persists across sessions or users, sensitive data accumulating in context
Per-user memory isolation, TTL and size limits, integrity checks, redaction before persistence
Egress and exfiltration
Data leaked through tool calls and API requests, denial of wallet from unbounded loops
Egress allowlists, payload inspection, hard limits on tokens, cost, retries, and chain depth
Multi-agent propagation
One compromised agent escalating through others, cascading failure
Signed inter-agent messages with replay protection, trust levels, circuit breakers
Shadow agents(meta)
Agents nobody registered, running with unknown permissions
Discovery and a registry — you cannot control what isn’t inventoried
Note how many of these are authorisation problems wearing AI clothing. That’s deliberate. The genuinely novel risks are instruction integrity and memory poisoning; the rest are old problems whose blast radius grew because the caller is now unpredictable and fast.
The control set, in priority order
1. Default-deny tool scoping
The single highest-leverage control. An agent with a general execute_command tool and wildcard permissions has, in effect, your entire environment as its attack surface. The alternative is narrow, purpose-built tools: read-only where possible, scoped to specific paths or resources, with explicit deny patterns for credential-shaped things (.env, .pem, anything matching secret patterns) and separate tool sets per trust level so a user-facing agent and an internal one never share a registry.
Practical test: for every tool your agent can call, can you state the worst thing that tool can do if the agent is fully adversarial? If the answer requires thinking, the tool is too broad.
2. Separate the decision from the execution
This is the best idea in the OWASP sheet and the one most implementations skip. An approval prompt in the agent’s own loop is not a control — the loop is the thing under attack.
The pattern: the agent proposes an action; an independent policy service validates scope, privilege, and approval state before anything executes. And critically, the approval is bound to the exact action — actor, tool name, target resource, normalised parameters, timestamp, expiry. An approval that says “yes, send the email” and not “yes, send this email to this recipient with this body” can be redirected between approval and execution.
Four details that make the difference between a real gate and a decorative one:
Short-lived authorisation artifacts with replay protection for anything irreversible.
Step-up authentication for critical actions — payment initiation, privilege changes, bulk deletion, production deployment, account recovery.
Idempotency where possible; explicit duplicate confirmation where it isn’t.
Fail closed. If risk classification, policy lookup, approval validation, or audit logging fails, the action does not proceed. A system that executes when logging is down produces exactly the actions you can’t account for.
Risk-tier your actions explicitly — reads and safe queries at the bottom, writes and API calls in the middle, external communication and code execution above that, irreversible and financial operations at the top — and set the auto-approval ceiling per tier rather than per agent. Anything not in the mapping should default to the highest tier, not the lowest.
3. Agents as first-class identities
Unique credentials per agent, issued through your existing IdP or SPIFFE/SPIRE rather than shared secrets. Long-lived API keys replaced by short-lived, tightly scoped, auto-rotated tokens — and in multi-agent flows, a fresh token minted per hop so authority doesn’t accumulate down the chain. Real lifecycle management: created, updated, and decommissioned deliberately, with dormant identities disabled automatically.
The governance payoff is attribution. When actions carry a verifiable agent identity, “who did this” has an answer, and that answer survives an auditor asking it six months later.
4. Memory and context hygiene
Validate before you persist, not after. Scope memory per user and per session so one tenant’s poisoned entry can’t surface in another’s context. Set TTLs and size caps. Redact credential and PII patterns before writing to memory rather than filtering on read. Add integrity checks so tampered entries fail verification instead of quietly steering a future session.
Memory poisoning is the risk most teams haven’t modelled, because it’s the only one where the attack lands in one session and detonates in another. That delay also makes it the hardest to attribute after the fact.
5. Egress control and cost bounds
Agents talk to external services, and that channel is the exfiltration path. Allowlist outbound endpoints, broker calls through a gateway you control so policy is enforced before the request leaves, inspect payloads for sensitive data, and rate-limit. Watch for the exfiltration signatures: unusual encoding in URLs, oversized payloads to webhook or HTTP tools, repeated calls to unfamiliar endpoints.
And set hard ceilings on tokens, cost, retries, and tool-chain depth. Denial of wallet is a real availability-and-budget risk, and unbounded recursion is how a bug becomes an incident with an invoice attached.
6. Adversarial testing as a release gate
Agents should be tested before production and re-tested after any material change — prompts, tools, memory, retrieval, policies, or model provider. Keep a repeatable abuse-case matrix: prompt override, tool misuse, privilege escalation, memory poisoning, data exfiltration, recursive tool abuse, approval bypass, multi-agent chaining. Each with a specific expected denial, version-controlled, running in CI.
One warning from the OWASP sheet deserves repeating verbatim in your review process, because it’s the kind of thing that only occurs to someone who has seen it: review test changes carefully, because an attacker may try to weaken or remove security tests in the same pull request that changes agent behaviour.
The part that turns controls into evidence
Everything above is security engineering. Here’s where it becomes governance — and where, in my experience, the gap between “we have controls” and “we can demonstrate control” gets exposed.
For every high-risk agent action, log structured decision metadata: action classification, risk score where applicable, authorisation outcome, approval identifier, execution result, and policy version. That last field is the one people forget, and it’s the one that lets you answer “what rules were inforce when this happened?” — which is the question that actually gets asked during an incident review.
Then monitor for drift in the oversight layer itself: repeated approval bypass attempts, elevated privilege usage, abnormal tool invocation frequency, sudden increases in high-risk actions, and changes in approval behaviour over time. An oversight mechanism degrades quietly — approvers start rubber-stamping, thresholds get relaxed for a deadline — and nothing alerts you unless you instrument for it.
For production agents, retain validation evidence: the tested agent version, model provider, tool policy and retrieval configuration; the abuse cases executed and their expected results; the approval, denial, timeout, and circuit-breaker behaviour observed; and any accepted residual risk with its compensating control. That last item is what separates a mature program from a hopeful one — mature programs have documented accepted risks, not zero risks.
Where this maps:
Framework
Anchor
ISO/IEC 42001
A.6 (AI system lifecycle), A.9.2 (responsible use), A.10.3 (supplier and value-chain responsibilities), Clause 9.2 (internal audit evidence)
NIST AI RMF 1.0
MAP for context and tool inventory; MEASURE for adversarial testing; MANAGE for monitoring, response, and residual risk
EU AI Act
Art. 14 human oversight as demonstrated capability to intervene, interrupt, and disregard; Art. 26 deployer duties including staff competence, monitoring, incident notification, and log retention of at least six months
ISO/IEC 27001
A.5.15 / A.8.2 for agent authorisation; A.8.16 monitoring; A.5.7 threat intelligence feeding the abuse-case matrix
The overlap is the point. An agent action log built to answer who authorised this, what context did the system have, what did it decide, was that consistent with policy simultaneously serves your incident response, your ISO 42001 internal audit, and an Article 26 request. Build it once.
From the practitioner’s chair
DISC InfoSec audited a client’s MCP Governance Standard and produced a v1.1 redline with 27 changes. Worth being specific about what those changes were, because the distribution is instructive.
They covered OAuth 2.1 with PKCE, token audience validation, SSRF and egress controls, tool manifest integrity, and confused-deputy protections. But the pattern across most of them was the same single idea: authority must be bound to a specific action, not held ambiently by a component. A token that isn’t audience-validated is authority without a destination. A tool manifest without integrity checking is authority without a definition. A confused-deputy gap is authority without a requester. Almost every finding was a variation on authority floating free of the thing it was supposed to authorise.
If you take one design principle from this post, take that one. It generalises further than any specific control in the list above.
The other thing I’d say from the audit chair: the controls are rarely the hard part. When we led VDR through ISO 42001 Stage 2 certification, the difference between passing and a nonconformity was almost never whether a control existed — it was whether we could produce the artifact proving it operated. Agents make that harder, because the volume of actions is high and the actions are taken by something that can’t be interviewed. Design the evidence trail at the same time as the control, or you’ll be reconstructing it under deadline.
Worth a sober note on where the industry actually is: across recent 2026 surveys, roughly a fifth of organisations can automatically terminate a misbehaving agent’s access, and a substantial share of deployed agents run with no security oversight or logging at all. If your kill switch has never been tested end to end, you don’t have one — you have a plan to find out during an incident.
No agent gets a tool whose worst-case use we haven’t written down.
Irreversible actions are validated and authorised by a service the agent does not control, against an approval bound to the exact action.
Every agent has its own identity, its own short-lived credentials, and a decommissioning date.
If classification, policy lookup, approval validation, or audit logging fails, the action does not execute.
Any change to prompts, tools, memory, retrieval, policy, or model provider re-runs the adversarial test suite before release.
Work with DISC InfoSec
DISC InfoSec helps B2B SaaS and financial services organisations deploy AI agents that survive both an attacker and an auditor: agent and tool inventories, MCP and tool-permission review, prompt injection and agent security assessment, human oversight design, and the evidence architecture that maps to ISO/IEC 42001, NIST AI RMF, and EU AI Act Articles 14 and 26.
I led VDR through ISO 42001 Stage 2 certification on the first attempt as the internal practitioner, served as internal auditor, and authored their MCP Governance Standard. If you have agents in production and no clear answer to who authorised that action, that’s the assessment to run now.
DISC InfoSec — | ISO/IEC 42001 & ISO/IEC 27001 Lead Implementer | PECB Authorized Training Partner
“Sorry, Typo”: Why a Markdown File Is Not a Security Control
PCWorld ran a piece last week on the one command you should never let an AI coding agent execute: rm -rf. The reporting is solid and the anecdotes are grim — developers who let an agent handle a routine cleanup task and lost a home directory, a project tree, or an entire drive. In one widely shared case, the agent was asked to create a backup, wrote it to the wrong location, recursively force-deleted the drive, and then apologized for the typo.
The recommended fix was to add a rule to CLAUDE.md or AGENTS.md instructing the agent never to run recursive forced deletions, including reordered flags, aliases, shell wrappers, and equivalents like find -delete or git clean -fdx.
That advice is directionally correct and worth doing. But it is not a control, and the distinction is the entire point of this post.
A CLAUDE.md instruction is a prompt. It is processed by the same probabilistic layer that generated the destructive command in the first place. You are asking the thing that made the mistake to please remember not to make the mistake. In control language, that is an awareness measure — the equivalent of a wall poster reminding staff not to click phishing links. Useful. Not the thing you point an auditor at.
Real controls sit below the model, in a layer the model cannot argue with.
Threat modeling the coding agent
Before reaching for controls, model the thing. An AI coding agent is a process with a shell, network egress, credentials, and a non-deterministic decision function. Run STRIDE against it as you would any other element in a data flow diagram:
STRIDE
Threat against the agent
Likelihood
Impact
S — Spoofing
A malicious or typosquatted MCP server registers tools the agent trusts; a poisoned dependency masquerades as a legitimate package
M
H
T — Tampering
Agent modifies its own configuration, hooks, CI definitions, or .env files; commits changes no human reviewed
M
H
R — Repudiation
No durable log of which tool calls ran with which arguments; post-incident, nobody can reconstruct what the agent did
H
H
I — Information disclosure
Agent reads ~/.ssh, ~/.aws, credential stores, or an entire knowledge base and emits contents into a prompt, a commit, or an outbound request
H
C
D — Denial of service
Unbounded agent loop; destructive deletion of source, database dumps, or infrastructure state
M
C
E — Elevation of privilege
Agent runs under a broad service account and performs actions the invoking human is not authorized to perform
H
C
Read that table again and notice what rm -rf actually is. It is one instance of D, in one row, on one machine. It is the failure mode that gets written up because it is loud and immediately visible. The rows that will actually end up in a breach notification are I and E, and they are silent.
This is OWASP’s Excessive Agency category (LLM06 in the 2025 Top 10 for LLM Applications). The vulnerability is not that the model is wrong sometimes — the model will always be wrong sometimes. The vulnerability is that a wrong decision has been wired to an unbounded capability.
The enforcement stack
Five layers, in order of how much they actually protect you. Each one holds when the layer above it fails.
1. Identity and scope — what the agent is
The agent is a non-human identity. Treat it like one. It gets its own service account, not a developer’s personal credentials. Its permissions are the union of what it needs for the task at hand, not the union of what its human operator happens to be entitled to.
This single decision determines blast radius. Everything downstream is mitigation.
2. Deny rules — declarative policy
Claude Code evaluates permission rules in deny → ask → allow order, and a deny at any settings level cannot be re-allowed by another level or by bypass mode. Managed (organization-level) denies are absolute. Write the deny list first, then decide how permissive to be about everything else:
Two engineering notes that matter more than the syntax:
Deny the binary, not the flag combination. Pattern matching is prefix-based. A rule targeting the literal string rm -rf misses rm -fr, rm -r -f, rm --recursive --force, an alias, and anything wrapped in a shell script. Deny rm itself and grant exceptions deliberately.
Test that your rules fire. There are open reports of Bash permission patterns not being enforced as documented (see anthropics/claude-code issue #18846). An untested control is a documented control, which is worse than no control because it produces false assurance. Write a five-line test that attempts each denied command and confirms it is blocked. Re-run it after every CLI upgrade.
3. Policy-as-code hooks — the part that actually generalizes
A PreToolUse hook intercepts every tool call before execution and returns allow, ask, or deny. Two properties make this the load-bearing layer:
It can parse the command rather than string-match it, so it catches the evasions a glob pattern cannot.
It fires even under --dangerously-skip-permissions.
That second property is the one to underline. In practice, “approval fatigue” is what kills agent security programs — a developer running several parallel sessions turns every confirmation prompt into a reflexive keystroke within about a day. The answer is not to demand more discipline from tired humans. It is to move the decision into code that does not get tired.
Hooks are also where the auditability comes from: a hook that logs every intercepted command with arguments, timestamp, session ID, and decision is your non-repudiation control for the R row above.
4. OS-level sandboxing — containing what does run
Permissions decide whether a call executes. Sandboxing decides what it can reach once it does. Claude Code’s sandbox uses Seatbelt on macOS and bubblewrap on Linux/WSL2 (native Windows and WSL1 are unsupported). Devcontainers, ephemeral VMs, and per-project containers do the same job at a coarser grain.
The rule of thumb: an agent operating with reduced human oversight should be operating inside a boundary that makes the reduced oversight defensible. Autonomy and isolation are traded against each other, and the trade has to be explicit.
5. Recoverability — the control that assumes the others failed
Version control on a remote the agent has no credentials to force-push to. Database backups on a system the agent cannot reach. And a restore you have actually performed at least once, because an untested backup is a hypothesis.
Governance mapping
For clients who need this to land in a management system rather than a wiki page:
Control
ISO/IEC 42001
NIST AI RMF
NIST CSF 2.0
Agent inventory, ownership, approved-use policy
Clause 6, Annex A (AI policy, roles, impact assessment)
GOVERN, MAP
GV.OC, ID.AM
Scoped non-human identity, least privilege
Annex A (resources, lifecycle controls)
MANAGE
PR.AA
Deny rules, hooks, sandboxing
Annex A (operational controls)
MANAGE
PR.PS, PR.IR
Tool-call logging and anomaly review
Annex A (monitoring, event logging)
MEASURE, MANAGE
DE.CM, DE.AE
Human approval for irreversible actions
Annex A (human oversight)
MANAGE
GV.RM
Agent incident handling and post-mortem
Annex A (incident management)
MANAGE
RS.MA, RC.RP
If you are already certified to ISO 27001, most of this is control extension rather than new work. The gap is almost always the same two things: the agent is not in the asset inventory, and no one has written down what it is permitted to do.
My perspective: the deletion story is the distraction
A lost home directory is recoverable, embarrassing, and over in a day. I want to close on the two failure modes that are neither loud nor recoverable, because they are where I expect the next several years of AI governance findings to concentrate.
Monitor for harmful instructions, because the agent cannot tell instructions from data
Every AI agent shares one architectural property: it has no reliable mechanism for distinguishing content it should reason about from commands it should obey. Everything arrives as tokens. The system prompt, the developer’s request, a README, a Jira comment, a dependency’s post-install script, a scraped web page, a row in a database, a response from an MCP tool — all of it lands in the same context window with the same claim to authority.
That means every data channel into the agent is also an instruction channel. The PCWorld story involved a wrong command the agent generated on its own. The same execution path is reachable by a command an attacker put there — planted in a code comment, an issue description, a vendor’s documentation page, a poisoned retrieval chunk. This is indirect prompt injection, and it is the vector I would use against a client whose agents are wired to real systems.
The cross-privilege version is worse and gets overlooked. A low-privilege user leaves a comment on a shared ticket. A senior engineer’s agent reads that ticket as context and follows the embedded instruction with the senior engineer’s entitlements. Nobody exploited a CVE. The AI layer was simply used as a confused deputy, and the privilege boundary your IAM team spent two years building was crossed sideways.
So: log prompts, completions, retrieved chunks, and every tool call with arguments. Feed them somewhere queryable and set detections on the sequences that indicate manipulation rather than on individual events — an unusual tool paired with an unusual argument, a retrieval followed immediately by an egress attempt, a sudden shift in the ratio of reads to writes, credential-shaped strings appearing in output. This is not novel detection engineering; it is the same behavioral analytics we already apply to service accounts, pointed at a new identity class. The organizations that will struggle are the ones treating agent activity as application telemetry rather than as security-relevant audit evidence.
Do not give an agent your whole knowledge base or database
This is where I push hardest with clients, and where I get the most resistance, because broad access is what makes the demo impressive.
Grant an agent read access to the entire knowledge base and you have collapsed, in a single configuration line, every compartment your organization built deliberately over years. HR files, board material, unreleased financials, customer contracts, security findings, the incident log. The access control model no longer reflects need-to-know; it reflects what was convenient to index.
Three reasons that is not a defensible position:
Read is exfiltration. “Read-only, so it’s low risk” is the most common error in this space. The entire value of a knowledge base is aggregation — a single well-crafted retrieval can surface more in one query than a determined insider could assemble in a month of browsing. Confidentiality impact does not require write access.
Broad service accounts break tenant and role isolation. If the agent queries under its own privileged identity rather than the requesting user’s, then every user effectively inherits the agent’s permissions. Row-level security, tenant filters, and role-based restrictions all sit underneath the layer the agent bypassed. Retrieval must be scoped to the invoking user’s actual entitlements, and vector stores must filter by tenant before results reach the context window — not after.
Aggregation changes the classification. Individually innocuous records combine into something that is not. A regulated institution can hold twenty datasets each rated internal-use and produce, through unrestricted joined retrieval, an output that is material non-public information or a reportable privacy event. Your data classification scheme almost certainly does not model this, because it was written for humans who could not join twenty datasets in 400 milliseconds.
The practical posture: per-purpose retrieval scopes rather than one omniscient index. Identity propagation so the agent’s reach is bounded by the human it acts for. Egress allowlists so a successful injection has nowhere to send anything. Human approval on irreversible and cross-boundary actions. Time-boxed and revocable credentials. Treat every tool response and retrieved document as untrusted input, because that is exactly what it is.
None of this is anti-AI. I use these tools daily and they have materially changed how much a small consultancy can deliver. But the governance question is not whether to adopt agents — that is settled. It is whether your agents are entitled to less than they can currently reach.
In financial data rooms, where a single unauthorized disclosure can move a transaction, that question has a very short answer. Everyone else is on the same trajectory; they just have not been tested yet.
DISC InfoSec helps B2B SaaS and financial services organizations build AI governance programs that survive an audit — ISO 42001 and ISO 27001 implementation, AI risk assessments, and vCISO advisory. If your organization has deployed AI agents faster than it has governed them, let’s talk.
“security against defeat implies defensive tactics; ability to defeat the enemy means taking the offensive” Sun Tzu
This quote is essentially saying:
If your goal is simply to avoid losing, you play defense. If your goal is to actually defeat the opponent, you must eventually take the initiative.
In simpler terms:
“Security against defeat implies defensive tactics” If you’re focused on preventing an attack or minimizing damage, you’re primarily reacting to what the adversary does. You protect assets, patch vulnerabilities, monitor systems, and respond to incidents.
“Ability to defeat the enemy means taking the offensive” If you want to consistently outmaneuver the adversary, you need to be proactive. You look for weaknesses before the attacker does, hunt for threats, test your defenses, and anticipate attacks.
In cybersecurity
This maps very well to the difference between defensive security and proactive security:
Defensive mindset
Offensive/proactive mindset
Patch vulnerabilities
Actively hunt for vulnerabilities
Monitor alerts
Threat hunt
Respond to attacks
Simulate attacks
Wait for indicators
Search for attacker behavior
Protect the perimeter
Assume the perimeter will be breached
Reduce damage
Find and eliminate attack paths
For example, a company that only waits for a vulnerability scanner to tell it what is wrong is primarily defending against defeat.
A company that continuously performs threat hunting, penetration testing, attack-surface discovery, red teaming, and adversary simulation is taking the offensive.
The deeper lesson: You cannot win a security war by merely absorbing attacks. Defense keeps you from losing; proactive action creates the conditions for winning.
That concept fits especially well with modern AI-accelerated vulnerability discovery: if attackers can discover weaknesses faster than your traditional security program can react, the defender has to become more proactive.
In the era of AI everywhere
Defensive security is no longer enough
Traditional defensive security assumes you can build a strong perimeter, deploy controls, monitor events, detect anomalies, and respond when something happens.
That model still matters—but AI is changing the economics of the attack.
Attackers can use AI to:
Discover vulnerabilities faster
Generate convincing phishing and social-engineering content
Automate reconnaissance
Adapt attacks dynamically
Analyze large amounts of stolen data
Scale attacks that previously required significant human effort
So the defender’s problem isn’t simply “Can we detect an attack?”
It’s increasingly:
“Can we discover and eliminate the attacker’s opportunities before they exploit them?”
Defensive vs. proactive security
Think of it as two layers:
Defensive security = Don’t let them win.
You protect, detect, respond, recover, and contain.
Proactive security = Don’t let them get the opportunity to attack successfully.
You continuously discover, test, validate, hunt, simulate, and remediate.
In an AI-driven environment, proactive security becomes much more important because the attacker can operate at machine speed.
The biggest shift: from alerts to attack paths
This is where I think cybersecurity is heading.
Instead of asking:
“How many vulnerabilities do we have?”
we should ask:
“Which weaknesses can an adversary actually chain together to compromise something valuable?”
That changes vulnerability management from a batch process into a continuous risk-discovery process.
And there’s another problem: AI itself becomes part of the attack surface
Organizations now have:
AI applications
LLMs
AI agents
APIs
RAG systems
Vector databases
Model providers
AI-generated code
Shadow AI
Autonomous workflows
So we’re no longer protecting just IT infrastructure.
We’re protecting AI-enabled business processes.
That introduces risks such as prompt injection, data leakage, model abuse, excessive agent permissions, insecure AI integrations, supply-chain risks, and uncontrolled use of AI.
My perspective
I would summarize the future of cybersecurity as:
Defensive security keeps the adversary out. Proactive security assumes the adversary is looking for a way in—and continuously looks for that way first.
And with AI, the winning organizations won’t necessarily be the ones with the most security tools.
They’ll be the ones that can continuously discover risk, prioritize what matters, validate their defenses, and remediate faster than the threat can exploit them.
In the AI era, security has to move from “detect and respond” toward “discover, anticipate, validate, and disrupt.”
That is where I see the real evolution from defensive cybersecurity to proactive cybersecurity.
AI Risk Management: The Discipline Your AI Strategy is Missing
Most organizations discovered last year just how much AI they were already running. A customer support chatbot here. Copilot in the IDE. Einstein scoring leads in the CRM. A fraud model someone built in 2021 that nobody owns anymore. When I run AI inventories for clients, the number of AI systems they think they have and the number they actually have are never the same — and the gap is where the risk lives.
That gap is exactly what AI risk management exists to close.
What Is AI Risk Management?
AI risk management is the discipline of identifying, evaluating, and treating the risks that AI systems introduce across their entire lifecycle — not just the security risks, but the fairness, robustness, transparency, privacy, and accountability risks that traditional security programs were never designed to catch.
Here’s the distinction that matters: prompt injection and jailbreaks are the security slice of AI risk. They get the headlines. But the risks that actually put organizations in front of regulators look different. A hiring model that screens out candidates from a protected class. A credit model that’s 95% accurate overall but 60% accurate on the demographic it impacts most. A production LLM that hallucinates a policy your company never had — to a customer, in writing. A model that drifted quietly for eighteen months because nobody was watching, and no one could explain its decisions when a regulator asked.
None of those are breaches. All of them are business-ending risks in the wrong context.
The most widely adopted framework for managing this is the NIST AI Risk Management Framework (AI RMF 1.0). It’s voluntary, but it has become the lingua franca of AI risk — cited in contracts, RFPs, executive orders, and increasingly in customer security questionnaires. If you speak NIST CSF, the shape will feel familiar. The AI RMF organizes the work into four functions:
GOVERN is the persistent layer: written AI principles, a named AI risk owner, approval gates for high-impact deployments, and — critically — someone with the authority to stop a deployment. If nobody in your organization can say “no” to an AI system, you don’t have governance. You have hope.
MAP establishes context per system: what does this AI actually do, who does it affect, what does “broken” look like, and — the question I find most clarifying in practice — is the decision reversible? A spam filter making a wrong call is an annoyance. A mortgage denial is not.
MEASURE is where the engineering happens: accuracy evaluated on data slices rather than aggregates, fairness metrics (demographic parity, equalized odds, calibration — which conflict, and choosing among them is a governance decision, not a technical one), robustness against adversarial inputs and distribution shift, and explainability. A model you cannot explain is a model you cannot defend in a regulatory inquiry.
MANAGE treats what MEASURE surfaces: retrieval-augmented generation for hallucination, monitoring and scheduled retraining for drift, human-in-the-loop for high-stakes decisions, vendor risk reviews for third-party models — and a decommissioning plan for every model, because an unowned production model is the AI equivalent of an unmaintained dependency.
Layer the regulatory landscape on top — the EU AI Act with its risk tiers and phased enforcement, the Colorado AI Act, NYC’s bias audit law for automated hiring tools, FTC and EEOC enforcement authority — and the picture is clear: AI risk management is no longer optional for any organization deploying AI in consequential decisions.
My Perspective: What a Proper AI Risk Management Program Actually Buys You
I led the ISO 42001 AI Management System implementation at ShareVault, a virtual data room platform serving M&A and financial services clients — an environment where the data is deal-sensitive and the tolerance for AI failure is effectively zero. Taking that program through a successful Stage 2 audit taught me what separates AI risk management as a paper exercise from AI risk management as a working system. Here’s what a proper program delivers:
It converts unknown risk into managed risk. The inventory step alone is worth the engagement. You cannot govern what you haven’t cataloged, and shadow AI — the tools employees adopted without review — is present in every organization I’ve assessed. Visibility precedes control, always.
It prevents the expensive failures, not just the embarrassing ones. Biased outcomes in hiring or credit carry regulatory penalties, litigation exposure, and remediation costs that dwarf the price of evaluating the model before deployment. Fairness testing during MEASURE costs days. A disparate-impact claim costs years.
It turns compliance from a scramble into a byproduct. Organizations with a working AI RMF-aligned program aren’t rebuilding from scratch when the EU AI Act’s high-risk requirements apply to them, or when a state law lands, or when an enterprise customer’s due-diligence questionnaire asks how they govern AI. The documentation, the impact assessments, the human oversight mechanisms — they already exist. Frameworks like NIST AI RMF and ISO 42001 map cleanly onto each other and onto the regulations. Build once, answer everywhere.
It becomes a sales asset. This is the part most organizations underestimate. In B2B — especially financial services — your customers’ risk teams are now asking about your AI. Being able to hand over an AI system inventory, model documentation, and evidence of independent audit doesn’t just pass procurement. It shortens sales cycles. At ShareVault, ISO 42001 certification became a differentiator precisely because the market is full of AI claims and short on AI evidence.
It lets you move faster, not slower. The counterintuitive one. Teams without governance hesitate on every AI deployment because nobody knows what’s acceptable. Teams with clear approval gates — rigorous review for high-impact systems, lightweight paths for low-impact ones — ship with confidence. Good governance is a throttle, not a brake. Overengineering the process kills it; right-sizing it accelerates everything.
The organizations getting AI risk management right in 2026 aren’t the ones with the thickest policy binders. They’re the ones who treated it as an operating discipline: inventory what you have, understand what it affects, measure what matters, treat what you find, and build the governance layer that keeps it working after the consultants leave.
Leadership must treat regulatory security, privacy & AI compliance as a strategic risk management priority. Noncompliance can lead to financial penalties, litigation exposure, reputational damage, and loss of customer trust. Top management should ensure that security, privacy & AI compliance risks are incorporated into enterprise risk assessments, evaluated using risk-based decision-making frameworks, reported regularly to executive leadership and governing bodies, and addressed through mitigation strategies aligned with organizational risk tolerance.
The ones getting it wrong will find out the way organizations always find out — in production, in public, or in front of a regulator.
HD is Principal Consultant at DISC InfoSec, a boutique cybersecurity and AI governance consultancy. He holds CISSP, CISM, AICP, ISO 27001 Lead Implementer, and ISO 42001 credentials, and led the ISO 42001 AIMS implementation and internal audit at ShareVault through a successful Stage 2 certification audit.
If your organization is deploying AI and can’t yet answer “how do you govern it?” — let’s talk. Book a consultation: info@deurainfosec.com
As enterprise adoption of generative AI accelerates, the operational gap between “AI as productivity tool” and “AI as governed enterprise application” has widened. Anthropic has moved to close that gap by introducing 28 integrations with security and compliance tools that allow IT and security teams to manage Claude in the same way they manage other applications in their environments. The announcement reframes Claude from a standalone SaaS product into a workload that fits inside an organization’s existing control plane.
The technical foundation for this is the newly introduced Claude Compliance API. It is a REST API that gives enterprise IT and security teams programmatic access to Claude activity data, replacing manual exports and periodic reviews with real-time programmatic access to usage data and customer content, enabling continuous monitoring and automated policy enforcement. In other words, Anthropic is treating governance signals as first-class telemetry rather than as an after-the-fact audit artifact.
Two data domains are exposed through the API. The first covers conversation content from Claude Enterprise — chats, uploaded files, and projects — which organizations can pipe into their existing security, monitoring, and data loss prevention pipelines. This is the layer where sensitive data exposure, prompt-side leakage, and content-policy violations get detected.
The second domain covers activity events from Claude Enterprise and the Claude Platform, including user logins, administrative actions, and configuration changes. This is the audit-trail layer that satisfies access governance, change management, and forensic reconstruction requirements — the kind of evidence external auditors actually open tickets about.
The 28 launch partners span a broad swath of the enterprise security stack: DLP, SASE, data security, SIEM, security operations, identity management, eDiscovery, AI security posture management, and observability. The named providers include Cloudflare, Cribl, CrowdStrike, Cyera, Datadog, Forcepoint, Fortinet, Geordie AI, IBM Guardium, Microsoft Purview, Mimecast, Netskope, Okta, Palo Alto Networks, Proofpoint, Relativity, ReliaQuest, Rubrik, SailPoint, Smarsh, Snyk, Sumo Logic, Tenable, Theta Lake, Trellix, Varonis, Wiz, and Zscaler. The breadth signals that Anthropic is meeting enterprises wherever their existing investment already sits.
The promised user experience is deliberately undramatic. For organizations already running one of these platforms, enabling coverage over Claude usage involves connecting and configuring the Claude instance so the data flows into the same dashboards and alerting workflows used for everything else. That framing matters: governance friction is the single biggest reason shadow AI proliferates, and “it shows up in your existing SIEM” is a far more compelling story to a CISO than “stand up a parallel monitoring stack for AI.”
Taken together, the move positions Claude as governable infrastructure rather than an unmanaged endpoint. It directly addresses the most common objection raised in enterprise AI risk assessments — that AI usage is opaque, ungoverned, and lives outside the controls that already govern email, file shares, and SaaS. By exposing both content and activity telemetry through a documented API, Anthropic is essentially handing customers the evidence base required to demonstrate operational controls during audits.
My perspective: this is one of the more consequential governance announcements from a frontier lab to date, and it deserves attention from anyone implementing ISO 42001, NIST AI RMF, or the EU AI Act in practice. Most AI governance programs I see fail not at the policy layer but at the evidence layer — clauses A.6.2.6 (operation), A.6.2.8 (monitoring), and A.9 (performance evaluation) of ISO 42001 all require demonstrable, ongoing oversight of AI system use, and until now that evidence has typically been cobbled together from screenshot exports and vendor attestations. A Compliance API that streams content and activity data into Purview, Netskope, or Varonis converts those clauses from aspirational language into something an internal auditor can actually sample. It also collapses the artificial boundary between “AI governance” and “information security governance,” which is the right outcome — AI systems are information systems, and treating them as a separate compliance silo has always been a structural mistake.
That said, two cautions are worth flagging. First, the API gives you the capability to monitor; it does not give you the program. Without a defined AI acceptable use policy, a classified inventory of AI use cases, role-based access boundaries, and a triage workflow for what to do when DLP fires on a Claude conversation, the telemetry just becomes noise in another dashboard. Second, ingesting conversation content into DLP and eDiscovery tools creates new data-protection obligations of its own — privacy impact assessments, retention schedules, and access controls on the captured prompts and outputs themselves. Organizations should plan for the governance of the governance data before turning the firehose on. For practitioners building toward ISO 42001 certification or a Stage 2 audit, this announcement is the kind of vendor-provided control surface that materially shortens the path to demonstrable conformity — provided the management system around it is actually built.
DISC InfoSec is an active ISO 42001 implementer and PECB Authorized Training Partner specializing in AI governance for B2B SaaS and financial services organizations.
Microsoft Just Open-Sourced the Missing Piece of AI Agent Security: A Practitioner’s Take on RAMPART and Clarity
On May 20, Microsoft’s AI Red Team released two open-source tools that should be on every CISO’s and AI program owner’s reading list this week: RAMPART, a continuous testing framework for AI agents, and Clarity, a structured design-review tool. Both have been battle-tested inside Microsoft before being handed to the community, and together they begin to close one of the most uncomfortable gaps in enterprise AI today — the gap between “we shipped an agent” and “we shipped an agent that holds up under adversarial pressure and audit scrutiny.”
Coming from a practitioner who has spent the last two years implementing ISO 42001 in production environments, my honest reaction: finally. Let me explain why these tools matter, where they fit in a governance program, and where I think organizations will still get this wrong.
What Microsoft Actually Released
RAMPART is a test harness built on top of Microsoft’s existing PyRIT red-teaming library, designed to slot directly into a CI/CD pipeline. Developers write pytest-style tests describing adversarial scenarios — prompt injection, data exfiltration via tool calls, jailbreak attempts — and the framework runs them on every code change. Each test connects through a thin adapter, orchestrates an interaction with the agent, evaluates the outcome, and returns a clear pass/fail signal that can be gated in CI like any other integration test. Because AI systems are probabilistic, RAMPART supports running the same test multiple times and setting a pass threshold rather than demanding deterministic outcomes.
The real-world proof point Microsoft shared is telling: their incident response team took a reported vulnerability, used RAMPART to generate 100 variants of that vulnerability, applied mitigations, and validated each one — collapsing weeks of expert work into hours.
Clarity addresses a different and arguably more expensive failure mode: bad design decisions that become baked into the agent’s architecture. It guides engineers through structured conversations covering problem clarification, solution exploration, failure analysis, and decision tracking. Multiple AI “thinkers” independently examine the proposed system from different angles — security, human factors, adversarial scenarios, operational concerns — and surface the kinds of questions an experienced architect or safety engineer would ask. The output is committed to the repo as human-readable markdown in a .clarity-protocol/ directory, which means design decisions become reviewable artifacts rather than tribal knowledge.
Why This Matters for Security Discipline in Agent Development
Most AI agent failures I’ve seen in client environments don’t trace back to model behavior. They trace back to two earlier failures: nobody wrote down the threat model before the agent was built, and nobody set up continuous adversarial testing after it shipped. RAMPART and Clarity address exactly these two gaps — and they do it in a way that maps cleanly onto how engineering teams already work.
Shifting Agent Safety Left — Without Slowing Anyone Down
The defining problem with AI agent security today is that the testing usually happens in the wrong place at the wrong time. Pre-launch red team engagements are expensive, sporadic, and stale within a sprint. Post-incident reviews are valuable but, by definition, too late. RAMPART changes the economics by making adversarial tests behave like unit tests: cheap to run, repeatable, and enforceable through pull request gating. When a developer adds a new tool to the agent — say, the ability to query a customer database — the safety test for that new capability gets added in the same PR. This is what “secure SDLC” actually looks like for AI agents, and it’s something most internal AI programs have been describing in slide decks but failing to implement in code.
Making Design Decisions Auditable
Clarity is the more underrated of the two tools. ISO 42001, the NIST AI RMF, and the EU AI Act all require organizations to demonstrate that they considered foreseeable risks during system design — not just that they ran some tests at the end. Auditors increasingly ask: “Show me the design review record. Show me the failure modes you considered and the decisions you made.” In most organizations, that record doesn’t exist. It lives in someone’s head, a Slack thread, or a Jira ticket that got closed eight sprints ago. Clarity’s commitment to writing design decisions as markdown artifacts inside the code repo is genuinely useful for compliance evidence — it turns ephemeral architectural conversations into the kind of durable, reviewable record that an ISO 42001 internal auditor or an EU AI Act conformity assessment will ask for.
Closing the “Variant Problem” in AI Incident Response
The detail from Microsoft’s writeup that should grab every incident responder is the 100-variant test. When a real vulnerability is reported in a traditional system, you patch the specific exploit and move on. AI agents don’t work that way. The same underlying weakness can be triggered by hundreds of semantically equivalent prompts, and patching one doesn’t patch the others. RAMPART’s ability to generate variants of a reported vulnerability, test mitigations against all of them, and validate the fix is the kind of capability most enterprise security teams have been trying to build in-house with mixed results. Having Microsoft hand this over as open source — battle-tested against real incidents — meaningfully lowers the cost of doing AI incident response properly.
Where Organizations Will Still Get This Wrong
Tools don’t fix governance gaps. Tools amplify whatever discipline already exists. Three predictions about how RAMPART and Clarity get deployed:
1. Teams will adopt RAMPART without adopting a threat model. RAMPART runs the tests you write. If you only write tests for the prompt injection scenarios you happen to think of, you get a false sense of coverage. Organizations that haven’t done the upstream work of mapping their agent’s attack surface — tool calls, retrieval sources, prompt-completion logging, orchestration handoffs — will end up with a green CI pipeline and the same underlying risk.
2. Clarity will be treated as documentation, not governance. The whole point of structured design reviews is that decisions get challenged before they become technical debt. If Clarity outputs become files that nobody reads in code review, the tool fails. The discipline isn’t in running Clarity. It’s in treating its output as a gate.
3. Both tools will live inside the AI team, not the security organization. This is the failure mode I’ve written about repeatedly. AI agents touch sensitive data, call APIs, and make decisions on behalf of users — they are production systems with security blast radius. If RAMPART and Clarity sit only with the ML engineers and never get visibility from the security team, the org has automated the wrong half of the problem. ISO 42001 explicitly requires defined ownership of AI system risk; this is exactly the kind of shared responsibility these tools enable, if the org bothers to set it up.
My Perspective: This Is the Beginning, Not the End
Microsoft’s release is a meaningful contribution to the AI security commons, but it’s important to be clear-eyed about what it does and doesn’t solve. RAMPART and Clarity are excellent at what they do — adversarial testing in CI and structured design review with artifact output — and they bring genuine engineering rigor to two phases of the AI development lifecycle that have been governed mostly by good intentions.
What they don’t do is replace the broader governance program. An organization that runs RAMPART tests on every PR but has no data classification, no model change management policy, no inventory of which agents are touching which data sources, and no defined accountability for AI risk has automated the testing without building the governance underneath it. These tools are most valuable when they slot into an existing AI management system — ISO 42001 or equivalent — that already defines who is accountable, what risks the organization has accepted, and how evidence gets collected for audit. Without that scaffolding, they become another set of green checkmarks in a dashboard nobody trusts.
The trajectory here is also worth watching. We are moving, fast, toward a world where enterprise procurement asks vendors for evidence of AI agent testing the same way it asks for SOC 2 reports today. The organizations that adopt RAMPART and Clarity now — and, more importantly, build the governance program around them — will be the ones that can answer those procurement questions with confidence in 12 months. Everyone else will be scrambling to retrofit security discipline into agents that are already in production, talking to customers, and quietly accumulating risk.
Microsoft just gave the community two of the right tools. The harder question is whether your organization has the governance discipline to use them well. That part doesn’t come from GitHub.
At DISC InfoSec, we help B2B SaaS and financial services organizations build the AI governance scaffolding — ISO 42001, NIST AI RMF, EU AI Act — that makes tools like RAMPART and Clarity actually deliver value. If you’re standing up an AI agent program and want a practitioner’s view of what holds up under audit, let’s talk.
AI security spans a broader attack surface than traditional infosec because the model itself is now part of what you’re defending. The pillars most practitioners converge on:
Data security and integrity. Training, fine-tuning, and RAG data are all attack surfaces. Poisoning, label flipping, and backdoor insertion happen upstream; data lineage, provenance tracking, and integrity controls are the defense. This is also where most privacy obligations land (PII minimization, retention, consent).
Model security. Protecting the model itself from adversarial inputs (evasion), model extraction/stealing, membership inference, and inversion. Includes hardening against prompt injection and jailbreaks for LLMs, which behave differently from classical adversarial ML threats.
Access and identity. Who can query, fine-tune, deploy, or modify a model — and under what authorization. RBAC/ABAC on inference endpoints, secrets management for API keys, separation of duties between data science, MLOps, and production. Often the weakest link in real-world incidents.
Supply chain. Pre-trained foundation models, open-source libraries, HuggingFace artifacts, datasets, and embedding providers all enter your trust boundary. SBOM-equivalents for ML (model cards, dataset cards, signed artifacts) and vendor due diligence are increasingly non-negotiable.
Infrastructure and MLOps security. The pipelines, notebooks, registries, feature stores, and orchestration layers — most of which were built for velocity, not security. Standard cloud/container hardening applies, plus pipeline-specific concerns like notebook sprawl and unsecured model registries.
Output and content safety. Guardrails against harmful, biased, hallucinated, or leaked outputs. For agentic systems this expands to tool-use safety, sandboxing, and constraining what actions a model can take downstream of a malicious prompt.
Monitoring, detection, and observability. Drift, anomaly detection on inputs/outputs, abuse pattern detection, and audit logging sufficient to reconstruct an incident. Most orgs underinvest here relative to classical SIEM coverage.
Governance and assurance. The wrapper that makes the rest defensible to auditors, regulators, and customers — ISO 42001, NIST AI RMF, EU AI Act obligations, internal AI use policies, risk registers, and impact assessments. Without this, the technical controls have no organizational accountability behind them.
Resilience and incident response. Red-teaming (both classical and AI-specific), tabletop exercises that include model failure modes, rollback capability for compromised models, and IR playbooks that recognize a poisoned model or a prompt-injected agent as a real incident class.
The practitioner shorthand I’d use: classical CIA still applies, but you’ve added a model that can be attacked, a pipeline that can be poisoned, and an output channel that can be weaponized — so you need controls at each of those layers plus the governance to prove the controls exist.
Here’s the same set of pillars reframed as an accountability matrix, then a candid take on what actually works in implementation.
Pillar
Primary Owner
Oversight Authority
Audit Cadence
Monitoring Cadence
Data security & integrity
Data Owner / CDO (with Security as partner)
CISO + DPO; AI Governance Committee for high-risk datasets
Annual formal audit; ad-hoc on schema or source changes; per-release for training data
Annual IR plan review; semi-annual tabletop incl. AI-specific scenarios
Continuous detection; quarterly drills; post-incident reviews on every Sev-2+
A few notes on how to read this matrix in practice. Primary Owner is who builds and runs the control; Oversight Authority is who signs off that it’s working and gets fired if it isn’t — those should never be the same person. Audit cadence is the minimum floor; trigger-based audits (model retraining, vendor change, regulatory update, security incident) almost always matter more than the calendar. Monitoring cadence is calibrated to risk tier — a high-risk EU AI Act system gets continuous output sampling; an internal productivity tool gets weekly.
My perspective on implementation and monitoring
Most orgs get the matrix roughly right on paper and then fail in three predictable ways.
First, ownership ambiguity at the seams. Data security is “owned” by the data team, model security by ML engineering, supply chain by procurement — and the seams between them are where incidents happen. A poisoned third-party dataset is a supply chain failure that becomes a data integrity failure that becomes a model security failure. If you can’t name a single accountable person for cross-pillar incidents (in most orgs, that’s the CAIO or vCAIO function), the matrix is decorative. The fix is a RACI that explicitly forces a single accountable owner per AI system end-to-end, not per pillar.
Second, monitoring theater. Continuous monitoring gets written into every policy and then implemented as a dashboard nobody opens. The pillars where this fails hardest are output safety and model security — both require sampling and human review, not just telemetry. A useful test: if your AI monitoring would not catch a slow drift that degrades outputs over six months, you don’t have monitoring, you have logging. Build at least one human-in-the-loop checkpoint per high-risk system, and treat the sampling rate as a control to be audited.
Third, audit cadence misaligned with model lifecycle. Annual audits are an artifact of financial reporting cycles, not AI risk. Models change faster than audit cycles — a quarterly cadence for high-risk systems is the realistic floor, with trigger-based reassessment on retraining, material data source change, or material behavior change. ISO 42001 surveillance gives you the annual external check; your internal cadence has to be tighter than that to actually catch things between surveillance visits.
The pillar that’s chronically under-resourced is governance and assurance, and it’s the one that determines whether everything else is defensible. Without a documented risk register, control mapping (NIST AI RMF + ISO 42001 + sector-specific), and board-level reporting, the technical controls exist but can’t be proven to exist — which fails every audit, every customer security questionnaire, and every regulator inquiry. That’s why the practitioner pattern that actually works is: build the governance layer first (even thin), then layer technical controls into it. The reverse — strong technical controls with no governance wrapper — is what we see in most “we have AI security” pitches, and it collapses the first time someone asks for evidence.
The honest summary: technical controls are the easy part; the hard part is sustained ownership, sampling discipline, and auditable evidence. The orgs that pass real ISO 42001 Stage 2 audits aren’t the ones with the fanciest guardrails — they’re the ones that can produce the access review from last Tuesday and the red-team report from last quarter without scrambling.
DISC InfoSec is an active ISO 42001 implementer and PECB Authorized Training Partner specializing in AI governance for B2B SaaS and financial services organizations.
The newly released 2026 OWASP catalogue on GenAI data security risks highlights how rapidly the security landscape is evolving for organizations deploying LLMs, RAG pipelines, and agentic AI systems. Unlike traditional application security frameworks, this catalogue focuses specifically on the unique ways AI systems process, store, retrieve, and expose data across increasingly autonomous workflows. The release signals that AI security is no longer a niche concern but a central governance issue for enterprise technology leaders.
One of the most important themes in the catalogue is that AI risk spans the entire data lifecycle. Security exposure is not limited to the model itself; vulnerabilities can emerge during training, embedding generation, vector storage, inference, telemetry collection, and long-term memory retention. This broader attack surface means organizations must evaluate security controls across every stage of AI operations rather than relying on conventional perimeter-based protections.
OWASP emphasizes several high-priority risks that security leaders should treat as foundational concerns during architecture reviews. Sensitive Data Leakage remains one of the most immediate threats, especially when models unintentionally reveal confidential information through prompts, retrieval systems, logs, or generated outputs. Because GenAI systems often aggregate large volumes of internal and external data, the likelihood of accidental disclosure increases significantly without strong governance controls.
Another major concern is Agent Identity and Credential Exposure. Agentic AI systems increasingly interact with APIs, enterprise applications, browsers, and cloud environments using privileged credentials. If these identities are compromised, attackers may gain broad access to systems and sensitive resources. This risk becomes especially critical as organizations adopt autonomous agents capable of performing multi-step actions with limited human oversight.
The catalogue also highlights Data, Model, and Artifact Poisoning as a core threat category. Malicious actors may manipulate training datasets, embeddings, vector databases, prompts, or model artifacts to influence AI behavior or corrupt outputs. Because AI systems rely heavily on probabilistic reasoning and external context retrieval, poisoning attacks can be subtle, persistent, and difficult to detect through traditional security monitoring approaches.
A notable shift in the OWASP framework is the equal treatment of regulatory exposure alongside technical vulnerabilities. The inclusion of DSGAI 08 reflects growing recognition that compliance failures, privacy violations, and governance gaps can create business risk comparable to direct cyberattacks. This changes the conversation in executive and board-level security discussions, where AI governance is increasingly tied to legal accountability, auditability, and reputational protection.
The report also introduces several threat categories that have little precedent in classical application security. Risks such as cross-context conversation bleed, vector store membership inference, prompt over-sharing, and browser assistant overreach illustrate how AI systems create entirely new modes of data exposure. These are not simply extensions of existing AppSec problems; they emerge from the contextual reasoning, memory persistence, and autonomous behavior that define modern AI architectures.
Overall, the OWASP catalogue demonstrates that GenAI security requires a dedicated discipline rather than incremental updates to traditional cybersecurity programs. Organizations deploying AI at scale must rethink identity management, data governance, monitoring, retrieval security, and compliance frameworks together. The report serves as both a warning and a roadmap for enterprises integrating AI into critical business operations.
From my perspective, the most important takeaway is that AI security is shifting from a “model risk” conversation to a “systemic operational risk” conversation. The danger no longer comes only from what the model knows, but from how interconnected AI systems interact with data, memory, tools, users, and external environments. Many companies are still treating GenAI deployments like standard SaaS integrations, when in reality they behave more like dynamic decision-making ecosystems. The organizations that succeed will be the ones that build AI governance and security into architecture decisions from the beginning rather than attempting to retrofit controls after deployment.
DISC InfoSec is an active ISO 42001 implementer and PECB Authorized Training Partner specializing in AI governance for B2B SaaS and financial services organizations.
AI Security Tool Evaluation: A Reality Check for CISOs
Artificial intelligence is fundamentally reshaping how applications are built, deployed, and attacked. Unlike traditional systems, AI introduces a dynamic and unpredictable attack surface—especially with the rise of agentic AI that can act autonomously. This shift demands a completely new approach to security evaluation.
Most organizations are still relying on legacy application security tools, which were designed for deterministic code. These tools struggle to keep up with AI systems that evolve, learn, and behave differently over time. As a result, CISOs are facing a widening gap between AI adoption and AI security readiness.
The core issue is visibility. Many organizations do not have a clear inventory of their AI assets—models, datasets, agents, and dependencies. Without this foundational understanding, it becomes nearly impossible to secure or govern AI effectively.
To address this, modern AI security evaluation must start with discovery. CISOs need tools that can map the entire AI footprint, including hidden dependencies and third-party integrations. This concept is often referred to as an AI Bill of Materials (AI-BOM), which provides a structured view of the AI supply chain.
Once visibility is established, the next step is risk assessment. AI systems require new testing approaches such as adversarial testing, red teaming, and behavioral analysis. Unlike traditional vulnerability scanning, these methods simulate real-world attacks against AI models and agents to uncover hidden risks.
Governance is another critical pillar. AI security tools must enable organizations to enforce policies aligned with emerging standards like the EU AI Act, NIST AI RMF, and ISO/IEC 42001. Security is no longer just about detection—it must include enforceable controls across the AI lifecycle.
A major shift highlighted in the framework is the need for unified platforms. Fragmented tools create blind spots and operational inefficiencies. Instead, organizations should prioritize integrated solutions that combine visibility, testing, governance, and runtime protection into a single system.
Runtime defense is becoming increasingly important where you may need AI Governance enforcement. AI agents can take actions in real time, interact with external systems, and trigger cascading effects. Security tools must monitor and control these behaviors dynamically, not just during development.
Another key insight is collaboration. AI security is no longer owned by a single team. CISOs, AI leaders, developers, and security engineers must work together to ensure safe adoption. This requires tools and processes that bridge gaps between governance, engineering, and operations.
Ultimately, the goal of AI security tool evaluation is not just to reduce risk but to enable innovation. Organizations that can securely adopt AI will move faster and gain competitive advantage, while those relying on outdated approaches will struggle to keep pace.
Perspective & Recommendations (from a GRC / vCISO lens)
Here’s the blunt truth: most AI security tool evaluations today are feature-driven, not risk-driven.
CISOs are still asking:
“Does this tool scan prompts?”
“Does it detect jailbreaks?”
But they should be asking:
“Can this tool enforce governance?”
“Can I prove compliance and control effectiveness?”
My perspective:
AI security is quickly becoming a governance problem disguised as a tooling problem.
If you don’t tie tools to:
Risk scenarios
Regulatory obligations
Business impact
…you’re just buying expensive dashboards.
What I recommend (practical + actionable)
1. Start with AI Risk Scenarios, not tools
Define:
Model misuse
Data leakage
Prompt injection
Autonomous agent abuse
Then evaluate tools against these risks.
2. Demand “control enforcement,” not just detection
Most tools find issues. Few can:
Block unsafe actions
Enforce policies
Provide audit evidence
That’s the gap regulators will focus on.
3. Align evaluation with frameworks early
Map tools to:
NIST AI RMF
ISO 42001
EU AI Act
If a tool can’t map to controls, it won’t survive audit.
4. Prioritize AI asset inventory (non-negotiable)
If you don’t know:
Where AI is used
What models exist
What data flows through them
You don’t have security—you have assumptions.
5. Test tools in real-world scenarios (not demos)
Run:
Red team exercises
Abuse cases
Failure simulations
Because AI breaks in production, not in slide decks.
6. Avoid tool sprawl early
Pick platforms that:
Integrate into SDLC
Provide governance + security
Support runtime controls
Otherwise, you’ll recreate the same AppSec mess.
Final Thought
AI security evaluation is evolving into AI governance maturity assessment.
The winners won’t be the companies with the most tools. They’ll be the ones who can prove control, enforce policy, and demonstrate trust.
DISC InfoSec is an active ISO 42001 implementer and PECB Authorized Training Partner specializing in AI governance for B2B SaaS and financial services organizations.
Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.
An effective CISO-grade scorecard that puts your AI security tool through the questions an assessor will actually ask — and maps every gap to NIST AI RMF and ISO 42001.
Walk into any AI security vendor demo and the choreography is the same. A prompt injection lights up red on a dashboard. A jailbreak attempt gets blocked in real time. A leaderboard shows their detection rates beating the competition. Heads nod. Procurement opens a folder. Six weeks later the tool is in production, the budget line item is closed, and everyone moves on. Then the auditor shows up and asks one question: “Show me where this control is mapped to your AI management system.” Silence. The dashboard is impressive. The control evidence does not exist. This is not a vendor problem. It’s a buying problem — and it’s everywhere right now.
The reason this happens is what I’ve been calling the capability-governance gap. Vendors are sprinting to ship features because that’s what gets them into POCs. Buyers are sprinting to check the “we have AI security” box because that’s what gets them into board decks. Nobody in either direction is doing the boring, unglamorous work of mapping detections to NIST AI RMF subcategories, or to the 47 controls in ISO 42001 Annex A — the actual things assessors will reference during a certification audit. The result is a market full of capable detection layers being sold (and bought) as if they were controls. They are not the same thing. A control produces evidence. A detection layer produces alerts. An auditor needs the first.
That gap is exactly why we built the AI Security Tool Evaluation Scorecard — CISO Edition. It’s a practical, self-contained tool with twenty questions across five domains: Threat Coverage, Detection Quality, Integration & Scope, Governance & Audit, and Vendor & Risk Reduction. Each question is weighted by audit impact rather than by how well it demos. Governance & Audit carries the heaviest weight in the scoring — twenty-five points out of a hundred — because that’s where every certification audit and every regulator inquiry actually lives. You answer Yes, Partial, No, or Don’t Know. The tool scores in real time. At the end you get a maturity band, a domain-by-domain risk exposure read, and a ranked list of gaps.
Three design choices make this different from the generic “AI security checklist” PDFs floating around. First, every single gap is tagged with the specific NIST AI RMF subcategories and ISO 42001 Annex A controls it maps to — so when you take it to your auditor, you’re speaking their language from the first sentence. Second, “Don’t Know” counts as a gap, not a neutral answer. Assessors don’t accept “we’d have to ask the vendor” as evidence; neither does this tool. Third, the questions were built from the inside of an active ISO 42001 implementation at a financial-services data room — meaning these are questions we’ve actually had to answer for assessors, not questions we imagined a CISO might one day care about.
DISC InfoSec is an active ISO 42001 implementer and PECB Authorized Training Partner specializing in AI governance for B2B SaaS and financial services organizations.
Most AI Security Tools Won’t Pass an Audit. Here’s a 15-Minute Way to Find Out.
A free CISO-grade scorecard that puts your AI security tool through the questions an assessor will actually ask — and maps every gap to NIST AI RMF and ISO 42001.
Walk into any AI security vendor demo and the choreography is the same. A prompt injection lights up red on a dashboard. A jailbreak attempt gets blocked in real time. A leaderboard shows their detection rates beating the competition. Heads nod. Procurement opens a folder. Six weeks later the tool is in production, the budget line item is closed, and everyone moves on. Then the auditor shows up and asks one question: “Show me where this control is mapped to your AI management system.” Silence. The dashboard is impressive. The control evidence does not exist. This is not a vendor problem. It’s a buying problem — and it’s everywhere right now.
The reason this happens is what I’ve been calling the capability-governance gap. Vendors are sprinting to ship features because that’s what gets them into POCs. Buyers are sprinting to check the “we have AI security” box because that’s what gets them into board decks. Nobody in either direction is doing the boring, unglamorous work of mapping detections to NIST AI RMF subcategories, or to the 47 controls in ISO 42001 Annex A — the actual things assessors will reference during a certification audit. The result is a market full of capable detection layers being sold (and bought) as if they were controls. They are not the same thing. A control produces evidence. A detection layer produces alerts. An auditor needs the first.
That gap is exactly why we built the AI Security Tool Evaluation Scorecard — CISO Edition. It’s a free, self-contained tool with twenty questions across five domains: Threat Coverage, Detection Quality, Integration & Scope, Governance & Audit, and Vendor & Risk Reduction. Each question is weighted by audit impact rather than by how well it demos. Governance & Audit carries the heaviest weight in the scoring — twenty-five points out of a hundred — because that’s where every certification audit and every regulator inquiry actually lives. You answer Yes, Partial, No, or Don’t Know. The tool scores in real time. At the end you get a maturity band, a domain-by-domain risk exposure read, and a ranked list of gaps.
Three design choices make this different from the generic “AI security checklist” PDFs floating around. First, every single gap is tagged with the specific NIST AI RMF subcategories and ISO 42001 Annex A controls it maps to — so when you take it to your auditor, you’re speaking their language from the first sentence. Second, “Don’t Know” counts as a gap, not a neutral answer. Assessors don’t accept “we’d have to ask the vendor” as evidence; neither does this tool. Third, the questions were built from the inside of an active ISO 42001 implementation at a financial-services data room — meaning these are questions we’ve actually had to answer for assessors, not questions we imagined a CISO might one day care about.
Use it before purchase, before contract renewal, before audit prep, and before any board update where someone is going to ask “are we covered on AI risk?” If you’re a CISO weighing two competing tools, run both through the scorecard and compare the gap maps — not the vendor scorecards. If you’re a GRC lead building an audit binder, the output gives you a defensible, mapped baseline you can drop straight into your control narrative. If you’re an AI governance lead doing vendor due diligence, the gap list becomes your negotiation leverage: “here are the seven things we need from you in writing before we sign.” It is meant to be useful at the moments where the budget and the calendar are still flexible.
The mechanics are simple. Fifteen minutes from start to finish, including the setup. You enter the tool you’re evaluating, your use case, and your compliance scope. You answer twenty questions with a live score updating in the sidebar. At the end you provide five details — name, business email, company, role, and company size — and the platform generates an instant maturity score in PDF format, makes a detailed text report available for download with remediation guidance and your top five priority gaps, and emails the full report to DISC InfoSec so we can follow up with a 30-minute walkthrough if you want one. There is no upsell wall, no “premium tier” to unlock the gaps, and no demo theater. You get the verdict, the evidence, and the remediation path.
My perspective, after eighteen months inside ISO 42001 implementation work: the honest read on the AI security tools market right now is that most of these products are very good at detecting things and very bad at producing the kind of evidence that makes audits go smoothly. That’s not a moral failing on the vendors’ part — it’s where the market is in its lifecycle. The capability layer always ships before the governance layer; that’s been true of every security category in the last twenty years. But it does mean that if you bought an AI security tool in the last twelve months and you have an ISO 42001 certification on the calendar, or an EU AI Act deadline approaching, or a SOC 2 attestation that’s about to grow an AI scope — you are almost certainly carrying more residual risk than the vendor’s dashboard suggests. The scorecard won’t fix that. What it will do is give you a precise, mapped, defensible read on exactly where the gap is — so you can decide whether to address it through vendor pressure, compensating controls, or honest scope reduction. Whatever the score comes back as, the gap list is the more useful artifact. That’s the part you take to the audit.
DISC InfoSec is an active ISO 42001 implementer and PECB Authorized Training Partner specializing in AI governance for B2B SaaS and financial services organizations.
AI Governance That Actually Works: Why Real-Time Enforcement Is the Missing Layer
AI governance is everywhere right now—frameworks, policies, and documentation are rapidly evolving. But there’s a hard truth most organizations are starting to realize:
Governance without enforcement is just intent.
What separates mature AI security programs from the rest is the ability to enforce policies in real time, exactly where AI systems operate—at the API layer.
AI Security Is Fundamentally an API Security Problem
Modern AI systems—LLMs, agents, copilots—don’t operate in isolation. They interact through APIs:
Prompts are API inputs
Model inferences are API calls
Actions are executed via downstream APIs
Agents orchestrate workflows across multiple services
This means every AI risk—data leakage, prompt injection, unauthorized actions—manifests at runtime through APIs.
If you’re not enforcing controls at this layer, you’re not securing AI—you’re observing it.
Real-Time Enforcement at the Core
The most effective approach to AI governance is inline, real-time enforcement, and this is where modern platforms are stepping up.
A strong example is a three-layer enforcement engine that evaluates every interaction before it executes:
These decisions happen in real time on every API call, ensuring that governance is not delayed or bypassed.
Full-Lifecycle Policy Enforcement
AI risk doesn’t exist in just one place—it spans the entire interaction lifecycle. That’s why enforcement must cover:
Prompts → Prevent injection, leakage, and unsafe inputs
Data → Apply field-level conditions and protect sensitive information
Actions → Control what agents and systems are allowed to execute
With session-aware tracking, enforcement can follow agents across workflows, maintaining context and ensuring policies are applied consistently from start to finish.
Controlling What Agents Can Do
As AI agents become more autonomous, the question is no longer just what they say—it’s what they do.
Policy-driven enforcement allows organizations to:
Define allowed vs. restricted actions
Control API-level execution permissions
Enforce guardrails on agent behavior in real time
This shifts AI governance from passive oversight to active control.
Built for the API Economy
By integrating directly with APIs and modern orchestration layers, enforcement platforms can:
This architecture aligns perfectly with how AI is actually deployed today—distributed, API-driven, and dynamic.
Perspective: Enforcement Is the Foundation of Scalable AI Governance
Most organizations are still focused on documenting policies and mapping controls. That’s necessary—but not sufficient.
The real shift happening now is this:
👉 AI governance is moving from documentation to enforcement. 👉 From static controls to runtime decisions. 👉 From visibility to action.
If AI operates at API speed, then governance must operate at the same speed.
Real-time enforcement is not just a feature—it’s the foundation for making AI governance work at scale.
Perspective: Why AI Governance Enforcement Is Critical
Most organizations are focusing on AI governance frameworks, but frameworks alone don’t reduce risk—enforcement does.
This is where many AI governance strategies fall apart.
AI systems are dynamic, API-driven, and often autonomous. Without real-time enforcement:
Policies remain static documents
Controls are inconsistently applied
Risks emerge during actual execution—not design
AI governance enforcement bridges that gap. It ensures that:
Prompts, responses, and agent actions are monitored in real time
Policy violations are detected and blocked instantly
Data exposure and misuse are prevented before impact
In short, enforcement turns governance from intent into control.
Bottom line: If your AI governance strategy cannot demonstrate continuous monitoring, control, and enforcement, it is unlikely to stand up to audit—or real-world threats.
That’s why AI governance enforcement is not just a feature—it’s the foundation for making AI governance actually work at scale.
Ready to Operationalize AI Governance?
If you’re serious about moving from **AI governance theory → real enforcement**, DISC InfoSec can help you build the control layer your AI systems need.
Most organizations have AI governance documents — but auditors now want proof of enforcement.
Policies alone don’t reduce AI risk. Real‑time monitoring, control, and enforcement do.
If your AI governance strategy can’t demonstrate continuous oversight, it won’t stand up to audit or real‑world threats.
DISC InfoSec helps organizations operationalize AI governance with integrated frameworks, runtime controls, and proven certification success.
Move from AI governance theory to enforcement.
Read the full post below: Is Your AI Governance Strategy Audit‑Ready — or Just Documented?
Schedule a free consultation or drop a comment below: info@deurainfosec.com
DISC InfoSec — Your partner for AI governance that actually works.
AI governance is no longer optional. Frameworks like ISO/IEC 42001 AI Management System Standard and regulations such as the EU AI Act are rapidly reshaping compliance expectations for organizations using AI.
DISC InfoSec brings deep expertise across AI, cybersecurity, and regulatory compliance to help you build trust, reduce risk, and stay ahead of evolving mandates—with a proven track record of success.
Ready to lead with confidence? Let’s start the conversation.
At DISC InfoSec, we help organizations navigate this landscape by aligning AI risk management, governance, security, and compliance into a single, practical roadmap. Whether you are experimenting with AI or deploying it at scale, we help you choose and operationalize the right frameworks to reduce risk and build trust. Learn more at DISC InfoSec.
1. Defining Risk in AI-Native Systems AI-native systems introduce a new class of risk driven by autonomy, scale, and complexity. Unlike traditional applications, these systems rely on dynamic decision-making, continuous learning, and interconnected services. As a result, risks are no longer confined to static vulnerabilities—they emerge from unpredictable behaviors, opaque logic, and rapidly evolving interactions across systems.
2. Why AI Security Is Still an API Security Problem At its core, AI security remains an API security challenge. Modern AI systems—especially those powered by large language models (LLMs) and autonomous agents—operate through API-driven architectures. Every prompt, response, and action is mediated through APIs, making them the primary attack surface. The difference is that AI introduces non-deterministic behavior, increasing the difficulty of predicting and controlling how these APIs are used.
3. Expansion of the Attack Surface The shift to AI-native design significantly expands the enterprise attack surface. AI workflows often involve chained APIs, third-party integrations, and cloud-based services operating at high speed. This creates complex execution paths that are harder to monitor and secure, exposing organizations to a broader range of potential entry points and attack vectors.
4. Emerging AI-Specific Threats AI-native environments face unique threats that go beyond traditional API risks. Prompt injection can manipulate model behavior, model misuse can lead to unintended outputs, shadow AI introduces ungoverned tools, and supply-chain poisoning compromises upstream data or models. These threats exploit both the AI logic and the APIs that deliver it, creating layered security challenges.
5. Visibility and Control Gaps A major risk factor is the lack of visibility and control across AI and API ecosystems. Security teams often struggle to track how data flows between models, agents, and services. Without clear insight into these interactions, it becomes difficult to enforce policies, detect anomalies, or prevent sensitive data exposure.
6. Applying API Security Best Practices Organizations can reduce AI risk by extending proven API security practices into AI environments. This includes strong authentication, rate limiting, schema validation, and continuous monitoring. However, these controls must be adapted to account for AI-specific behaviors such as context handling, prompt variability, and dynamic execution paths.
7. Strengthening AI Discovery, Testing, and Protection To secure AI-native systems effectively, organizations must improve discovery, testing, and runtime protection. This involves identifying all AI assets, continuously testing for adversarial inputs, and deploying real-time safeguards against misuse and anomalies. A layered approach—combining API security fundamentals with AI-aware controls—is essential to building resilient and trustworthy AI systems.
This post lands on the right core insight: AI security isn’t a brand-new discipline—it’s an evolution of API security under far more dynamic and unpredictable conditions. That framing is powerful because it grounds the conversation in something security teams already understand, while still acknowledging the real shift in risk introduced by AI-native architectures.
Where I strongly agree is the emphasis on API-chained workflows and non-deterministic behavior. In practice, this is exactly where most organizations underestimate risk. Traditional API security assumes predictable inputs and outputs, but LLM-driven systems break that assumption. The same API can behave differently based on subtle prompt variations, context memory, or agent decision paths. That unpredictability is the real multiplier of risk—not just the APIs themselves.
I also think the callout on identity and agent behavior is critical and often overlooked. In AI systems, identity is no longer just “user or service”—it becomes “agent acting on behalf of a user with partial autonomy.” That creates a blurred accountability model. Who is responsible when an agent chains five APIs and exposes sensitive data? This is where most current security models fall short.
On threats like prompt injection, shadow AI, and supply-chain poisoning, we’re highlighting the right categories, but the deeper issue is that these attacks bypass traditional controls entirely. They don’t exploit code—they exploit logic and trust boundaries. That’s why legacy AppSec tools (SAST, DAST, even WAFs) struggle—they’re not designed to understand intent or context.
The point about visibility gaps is probably the most urgent operational problem. Most teams simply don’t know:
Which AI models are in use
What data is being sent to them
What downstream actions agents are taking
Without that, governance becomes theoretical. You can’t secure what you can’t see—especially when execution paths are being created in real time.
Where I’d push the perspective further is this: AI security is not just API security with “extra controls”—it requires runtime governance. Static controls and pre-deployment testing are not enough. You need continuous AI Governance enforcement at execution time—monitoring prompts, responses, and agent actions as they happen.
Finally, your recommendation to extend API security practices is absolutely right—but success depends on how deeply organizations adapt them. Basic controls like authentication and rate limiting are table stakes. The real maturity comes from:
Context-aware inspection (prompt + response)
Behavioral baselining for agents
Policy enforcement tied to business risk (not just endpoints)
If you’re serious about moving from **AI governance theory → real enforcement**, DISC InfoSec can help you build the control layer your AI systems need.
Schedule a free consultation or drop a comment below: info@deurainfosec.com
How LLM capabilities could rapidly erode the value of traditional cybersecurity models:
The speaker opens by emphasizing the credibility and urgency of the topic, introducing a leading expert working on language model security at Anthropic. The central theme is not theoretical risk, but an immediate and rapidly evolving reality: language models are already capable of performing advanced security tasks that were once limited to elite human researchers.
The core insight is stark—modern LLMs can now autonomously discover and exploit zero-day vulnerabilities in critical software systems. This capability has emerged only within the past few months, marking a sharp inflection point. Previously, such tasks required deep expertise, time, and specialized tooling; now they can be triggered with minimal input and no sophisticated setup.
The simplicity of execution is particularly alarming. By giving a model a basic prompt—essentially asking it to act like a participant in a capture-the-flag (CTF) challenge—researchers observed that it could independently identify serious vulnerabilities. This dramatically lowers the barrier to entry, meaning attackers no longer need advanced skills to launch meaningful cyberattacks.
The speaker highlights that this shift undermines a long-standing equilibrium in cybersecurity. For decades, defenders had a relative advantage due to the effort required to find and exploit vulnerabilities. LLMs disrupt this balance by scaling offensive capabilities, enabling faster and broader exploitation than defenders can realistically match.
A concrete example illustrates this risk: an LLM discovered a critical SQL injection vulnerability in a widely used content management system. More concerning, the model didn’t just identify the flaw—it successfully generated a working exploit capable of extracting sensitive credentials without authentication. This demonstrates a full attack chain, from discovery to exploitation, executed autonomously.
Even more troubling is the model’s ability to handle complex exploitation scenarios. In this case, the vulnerability required a blind SQL injection, which traditionally demands nuanced reasoning and iterative testing. The LLM managed to execute the attack effectively, highlighting that these systems are not just fast—they are increasingly sophisticated.
The second example pushes this even further: the model identified a heap buffer overflow in the Linux kernel, one of the most hardened and scrutinized codebases in existence. This vulnerability required understanding multi-step interactions between clients and server processes—something that typically exceeds the capabilities of automated tools like fuzzers.
What makes this discovery remarkable is not just the vulnerability itself, but the reasoning behind it. The LLM generated a detailed explanation of the exploit, including a step-by-step attack flow. This level of contextual understanding suggests that LLMs are evolving beyond pattern matching into something closer to structured problem-solving.
The rate of progress is another critical factor. Models released just months ago were largely incapable of these tasks, while newer versions can perform them reliably. This rapid improvement follows an exponential trend, meaning today’s cutting-edge capability could become widely accessible within a year, including to low-skilled attackers.
Finally, the speaker warns that the biggest risk lies in the transition period. While long-term solutions like secure programming languages, formal verification, and better system design may eventually favor defenders, the near-term reality is different. During this phase, vulnerabilities will be discovered faster than they can be fixed, creating a dangerous window where attackers gain a significant advantage.
Perspective
This transcript signals a fundamental shift: cybersecurity is moving from a skill-constrained domain to a compute-constrained one. When exploitation becomes automated and scalable, traditional cybersecurity value—manual testing, expertise-driven assessments, and periodic audits—degrades rapidly.
For organizations (especially in GRC and vCISO services), this means the value will shift from finding vulnerabilities to:
Continuous monitoring and validation
Runtime detection and response
Secure-by-design architectures
AI-aware threat modeling
Example: A traditional pentest might take weeks and uncover a handful of issues. An LLM-powered attacker could scan thousands of services in parallel and generate working exploits in hours. If defenders still operate on quarterly or annual cycles, they are already outpaced.
Bottom line: Cybersecurity organizations that rely on scarcity of expertise will lose value. Those that adapt to speed, automation, and AI-native defense models will define the next generation of security.
