Opsin raises $21M to secure the agentic enterprise.
Hear from our founders →
AI-SPM and DSPM solve neighboring problems, and OWASP's new guide gives a practical rule for choosing. If your DSPM already covers your structured data stores well, extend it to AI. If you are starting fresh and your estate is mostly AI, begin with AI-specific posture management. Either way, start with an inventory of what exists. OWASP published Part 1 of its GenAI Data Security Best Practices v2 on November 3, 2026, and I am one of the contributors. This post covers what Part 1 says and how I read it.
Part 1 is the first of a twelve-part series from OWASP. The full guide runs more than 400 pages, and Part 1 covers three key components: scope and conventions, the fundamentals (including 6 core principles), and AI data security posture management (AI-DSPM) as the operating discipline. OWASP recommends reading this content first as the rest of the series anchors to these building blocks. Three terms come up throughout this post. Here is how I use them:
For databases, file shares and cloud storage, DSPM work is established. If your program already does it well, you have a strong base to build on. AI does not remove the need for it. The guide is clear that this is additive. Effective GenAI data security keeps every traditional control, including encryption, IAM, DLP, segmentation and logging, and adds a GenAI-specific layer on top.
AI systems make copies. A document becomes chunks. Chunks become embeddings. Embeddings live in a vector index. Summaries and generated answers add more copies. Each copy carries the sensitivity of the original.
Take an HR document that is locked down inside the HR system. An embedding built from that document is just as sensitive. The vector index that stores it is often governed by infrastructure permissions instead of the HR system's row-level rules. The sensitivity carries over to the copy. The access controls rarely do.
The guide notes that these copies have no schema and no row-level identity, which is why row-level rules do not follow them. The same applies to deletion. A deletion request that clears the source database but leaves the embeddings in a vector index is a non-compliant deletion, according to OWASP.
A posture program has to see these copies, or it is reviewing access to the original while the exposure still sits in the copy.
AI-SPM answers questions DSPM was not built to ask. Which AI systems exist? Which data sources feed them? Which copies did they create? Who and what can query those copies?
Static posture asks what an AI system or agent is configured to do, for example an over-permissioned non-human identity or an exposed vector database. Runtime behavior asks what it is doing right now, such as drift between its authorized intent and the tool calls it makes. Each needs its own owners, tooling and metrics.
The first two options follow the decision heuristic in OWASP’s build-or-buy guidance. The third is my own addition. OWASP also lists questions to answer before you evaluate tools: your regulatory floor, deployment topology, existing security stack and operational capacity, and how well a tool covers AI identities and non-human identities. The right answer depends on what you already have, not on which label is newer.
OWASP is direct about order. Set up governance first, with an AI governance committee, decision rights and a named owner for each capability. Then set the operating model, then choose tooling. The guide warns that teams who buy a platform before they have governance end up with findings nobody owns, alert fatigue sets in, and the program loses momentum.
Deploying all thirteen capabilities at once thins resources and breaks dependencies, for example running DLP before classification exists. And when security and ML platform teams each assume the other owns the program, labels exist but never reach DLP, and vector stores are encrypted but not monitored.
The first 90 days in OWASP’s rollout begin with the inventory below.
You can't assess posture for systems you haven't found. An AI agent and systems inventory should list each AI system, the data sources it reads, the copies it creates (indexes, caches, summaries) and the identities that can query them. Everything else in the program depends on this list. Include non-human identities such as agents, tools and MCP servers.
Data oversharing works the same way as the copy problem. Access that exists upstream shows up in answers downstream. If a user can reach a folder, an AI assistant working for that user can draw on it. So every summary and index entry needs the same access question asked of it.
When an AI system answers a question, it assembles everything it needs into one place called the context window: the instructions, the user’s request, the documents it retrieved and the output of any tools it called. That space has no access control of its own. Once a document is in it, the model can use it in the answer, whatever the source system would have allowed. OWASP’s guidance is to assume that any content reaching the model can influence what it says.
That puts the control point before the context window. Send the model only the data the task needs, and enforce per-document access controls at retrieval time, so a document the user can't open never gets retrieved. The same access question has to be asked of every summary and index entry as well.
DSPM finds and classifies sensitive data in the stores you run and shows who can reach it. AI-SPM covers the AI layer: the systems, connectors, indexes and agents that use that data, and the copies they create. The two overlap, and they answer different questions.
OWASP's guide gives a practical rule. If your DSPM already covers your structured data stores well, extend it to AI. If you are starting fresh and your estate is mostly AI, begin with AI-specific posture management.
Learn more about Opsin's approach to AI posture management here.
Begin with an inventory of AI systems and agents along with the data they read and the copies they create. Tooling choices are easier once you know what exists.
Read more on Opsin's approach to Agent Discovery.
Embedding and vector indexes are copies of sensitive content. The sensitivity carries over to the copy, and the access controls often do not, because the index is usually governed by infrastructure permissions. This allows for potential exposure as agents access those copies.
For more on embedding and vector index insights, read the latest OWASP report.
The OWASP guide is a twelve-part series from the OWASP GenAI Security Project. Part 1, published November 3, 2026, covers scope, fundamentals and an operating program for AI data security posture management. Opsin co-founder and CPO, Oz Wasserman, was a contributing author.
Read OWASP's full report: https://genai.owasp.org/resource/genai-data-security-best-practices-v2-part1/
AI assistants draw on whatever the user can reach. Excess access upstream becomes exposure in answers downstream, so access should be reviewed on every copy and every output path.
Explore Opsin's approach to ongoing oversharing protection.
AI-SPM and DSPM solve neighboring problems, and OWASP's new guide gives a practical rule for choosing. If your DSPM already covers your structured data stores well, extend it to AI. If you are starting fresh and your estate is mostly AI, begin with AI-specific posture management. Either way, start with an inventory of what exists. OWASP published Part 1 of its GenAI Data Security Best Practices v2 on November 3, 2026, and I am one of the contributors. This post covers what Part 1 says and how I read it.
Part 1 is the first of a twelve-part series from OWASP. The full guide runs more than 400 pages, and Part 1 covers three key components: scope and conventions, the fundamentals (including 6 core principles), and AI data security posture management (AI-DSPM) as the operating discipline. OWASP recommends reading this content first as the rest of the series anchors to these building blocks. Three terms come up throughout this post. Here is how I use them:
For databases, file shares and cloud storage, DSPM work is established. If your program already does it well, you have a strong base to build on. AI does not remove the need for it. The guide is clear that this is additive. Effective GenAI data security keeps every traditional control, including encryption, IAM, DLP, segmentation and logging, and adds a GenAI-specific layer on top.
AI systems make copies. A document becomes chunks. Chunks become embeddings. Embeddings live in a vector index. Summaries and generated answers add more copies. Each copy carries the sensitivity of the original.
Take an HR document that is locked down inside the HR system. An embedding built from that document is just as sensitive. The vector index that stores it is often governed by infrastructure permissions instead of the HR system's row-level rules. The sensitivity carries over to the copy. The access controls rarely do.
The guide notes that these copies have no schema and no row-level identity, which is why row-level rules do not follow them. The same applies to deletion. A deletion request that clears the source database but leaves the embeddings in a vector index is a non-compliant deletion, according to OWASP.
A posture program has to see these copies, or it is reviewing access to the original while the exposure still sits in the copy.
AI-SPM answers questions DSPM was not built to ask. Which AI systems exist? Which data sources feed them? Which copies did they create? Who and what can query those copies?
Static posture asks what an AI system or agent is configured to do, for example an over-permissioned non-human identity or an exposed vector database. Runtime behavior asks what it is doing right now, such as drift between its authorized intent and the tool calls it makes. Each needs its own owners, tooling and metrics.
The first two options follow the decision heuristic in OWASP’s build-or-buy guidance. The third is my own addition. OWASP also lists questions to answer before you evaluate tools: your regulatory floor, deployment topology, existing security stack and operational capacity, and how well a tool covers AI identities and non-human identities. The right answer depends on what you already have, not on which label is newer.
OWASP is direct about order. Set up governance first, with an AI governance committee, decision rights and a named owner for each capability. Then set the operating model, then choose tooling. The guide warns that teams who buy a platform before they have governance end up with findings nobody owns, alert fatigue sets in, and the program loses momentum.
Deploying all thirteen capabilities at once thins resources and breaks dependencies, for example running DLP before classification exists. And when security and ML platform teams each assume the other owns the program, labels exist but never reach DLP, and vector stores are encrypted but not monitored.
The first 90 days in OWASP’s rollout begin with the inventory below.
You can't assess posture for systems you haven't found. An AI agent and systems inventory should list each AI system, the data sources it reads, the copies it creates (indexes, caches, summaries) and the identities that can query them. Everything else in the program depends on this list. Include non-human identities such as agents, tools and MCP servers.
Data oversharing works the same way as the copy problem. Access that exists upstream shows up in answers downstream. If a user can reach a folder, an AI assistant working for that user can draw on it. So every summary and index entry needs the same access question asked of it.
When an AI system answers a question, it assembles everything it needs into one place called the context window: the instructions, the user’s request, the documents it retrieved and the output of any tools it called. That space has no access control of its own. Once a document is in it, the model can use it in the answer, whatever the source system would have allowed. OWASP’s guidance is to assume that any content reaching the model can influence what it says.
That puts the control point before the context window. Send the model only the data the task needs, and enforce per-document access controls at retrieval time, so a document the user can't open never gets retrieved. The same access question has to be asked of every summary and index entry as well.
